Slashdot Mirror

The very same Cisco which fixes a browser injection flaw in its routers by disallowing the curl user agent?

I mean: we might be scared at the perspective of some network infrastructure being bugged by enemy forces, but with this blatant incompetence we don't even need enemies.

This isn't going to end well.

Reminds me of this: accessing user-space data from the kernel is tricky. It's good to see they're working harder to resolve this issue, regardless of the OS.

This article is from 2012. If you want up-to-date stats see LWN's regular reports, e.g. here is a recent one for 4.18:

https://lwn.net/Articles/76069...

(Though Red Hat is indeed still right up near the top.)

Thank you, #3 and #9 now, but wow Intel #1, Linux Foundation #2.

This article is from 2012. If you want up-to-date stats see LWN's regular reports, e.g. here is a recent one for 4.18:

https://lwn.net/Articles/76069...

(Though Red Hat is indeed still right up near the top.)

Surely the OS is providing standard access to every FS

They are trying, and largely succeeding. Nevertheless, all non-trivial (and filesystems are highly nontrivial) abstractions are leaky

fopen() will still work, regardless, surely... no?

A service that offers background sync (i.e. changes are pushed to the cloud in the background) which doesn't just poll (polling is evil) needs an API much more complicated that fopen. Specifically, it needs a notification stream where it can create a 'watched' folder and be notified when:

• A file in the watch was opened for writing was closed
• A new file or directory entry was created
• A file or directory was deleted
• A file or directory was moved, either from outside the watch to inside, inside to outside or inside to inside. Note that this is essential to allow users to rename or reorganize their folders without retransmitting the entire file each time
• Probably more I'm not thinking of . . .

This is a (somewhat) solved problem, in the sense that inotify exists within some limitations described on the wikipedia page (and further in the man page). One really obvious limitation is that the kernel will not do this recursively for you, meaning that the client has to manually add/remove folder watches. The other is that rename events are clunky, coming in two halves with a linking identify. Anyway, if you read the history, you'll note this is the third or so attempt at getting this right, which at least suggests that it's non-trivial enough that we had to can the original (dnotify) interface and start over once.

What was the point of this side-track into filesystem watching? Well, for one, we started with "how hard is fopen/fread" and now ended up with "holy crap, that's highly non-trivial to be async notified of changes within a directory tree (recursively!)". It also raises the question of whether the interface really is an airtight abstraction, or whether filesystem implementation details leak into the caller to be dealt with. Even answering that question for all supported Linux filesystems is non-trivial.

If you take nothing else away, just remember that this is a far more complicated problem than rsync ;-)

Postscript: rsync is 50K LOC

You can validate that secret ballots cast are untampered. Non-secret ballots don't actually solve that problem, as people with buyer's remorse can lie about how they voted and accuse the election authority of tampering.

Peter Gutmann is particularly aware of this in the security industry, although IanG brought it up.

Also it's not strictly true that Linux has no QA and no regression testing, it's just not centralized and the level of testing between kernel components is not standardized.

Linux kernel 4.17.7(!) is broken on 32-bit x86 and even this doesn't stop Greg KH from spitting the usual nonsense, "All users of the 4.17 kernel series must upgrade".

Sigh. Let me explain this in a programmer's way: GPL extends copyright. GPL != copyright

All it does is conditionally grant some rights that by default go to the author. If you violate the terms, you have no permissions to the work under copyright law.

The only way to violate the license is to distribute against the terms, which is illegal because your conditional permissions have been revoked. If you don't distribute, then there is nothing to legally bind you. That is why violating the GPL is necessarily and sufficienty a copyright violation.

The GPL is in essence a license which IS a contract.

No, it is not, although it has been contested. Why? No consideration. You do not commit to actually do ANYTHING by accepting the GPL--but informally you commit to abiding by the terms. Even the "requirement" that you provide source when distributing binaries is not something you agree to do, because distributing binaries with source is permitted and binaries without source is not. You are not obligated to anything, you can simply choose (or not) to do what the license permits.

https://lwn.net/Articles/61292/

For what it's worth, Python can be used in a bootloader. OK, the bootloader's not actually written in Python (it's just GRUB), but looks like a cool project anyway :)

Things like Unicore, Hexagon, S+core, OpenRISC, M32R, Cris i.e. stuff most people didn't even heard about.
The long version at (as always) excellent LWN:
https://lwn.net/Articles/74807... and
https://lwn.net/Articles/74929...

Things like Unicore, Hexagon, S+core, OpenRISC, M32R, Cris i.e. stuff most people didn't even heard about.
The long version at (as always) excellent LWN:
https://lwn.net/Articles/74807... and
https://lwn.net/Articles/74929...

I've been working for a couple of years on Fedora and Linux on RISC-V and the "Seeking alpha" article is the strangest thing. The RISC-V Foundation offers BSD-licensed specs and multiple CPU designs (and a lot more besides). WD, Google, and many more are members. But they are not in any real sense "joining forces to develop a new open-source chip design". The design and chips are already out there, you can make your own FPGA or (if you're very rich) ASIC and have been able to for years. WD are going to switch all their hard drives to RISC-V soon. Google are likely interested because it could be used for their TPUs of their own design. "Joining forces" just means the companies subscribed to the Foundation for a very nominal fee, back-of-the-sofa loose change for these companies.

I'd recommend watching this talk:

    https://www.youtube.com/watch?...

or if you prefer, the excellent-as-usual LWN summary:

    https://lwn.net/Articles/71231...

I don't like the language-specific package manager situation either, but the way these languages split things up does not lend itself well to the distro packaging model either unfortunately.

The Linux Weekly News usually has some pretty good information about kernel changes.

The most recent release requires a subscription, however all others are free to read.

Yep Tucows bought LWN in 2000 and gave it back to the original owners in 2002 https://lwn.net/Articles/26581... , strange though that you paid a lot of attention to Linux and completely missed LWN, your loss I guess.

Looking at the "Software announcements" section on that first edition, I notice they list Webalizer. Made me realize how long that has been around. Another nice piece of open source software.

The AMD scheme does AES-128 on the fly when reading anything from DRAM (!)

https://lwn.net/Articles/69982...

There are two separate features-Secure Memory Encryption (SME) and Secure Encrypted Virtualization (SEV)-that both use the same hardware support that will be provided in upcoming processors. That support includes an AES-128 hardware engine inline with the RAM and memory controller so that memory can be encrypted and decrypted on the way in and out of the processor with "minimal performance impact". The data inside the processor (e.g. registers, caches) will be in the clear; there will just be a "little extra latency" when RAM is involved.

It seems like the ASIC (the AMD equivalent of Intel PCIDs which actually predates PCIDs) - is part of the AES key.

The hypervisor then allocates an "address space identifier" (ASID), which is what identifies the guest (and the key for that guest's memory). That ASID is provided to the secure processor with a request to generate or load a key into the AES engine and to encrypt the BIOS/OS image using that key. The hypervisor then sets up and runs the guest using the ASID assigned; the memory controller, AES engine, and secure processor will work together to ensure that the memory is encrypted and decrypted appropriately.

On the other hand it's aimed at hiding hypervisor data from guest OSs and vice versa. It's not designed to hide process or kernel data from other processes on the same OS. Then again AMD isn't vulnerable to the KPTI hole as far as I can tell - that's to do with Intel's implementation of speculative execution.

Of course AMD might be vulnerable to other bugs like this. Like you say, Spectre seems to affect "Intel, AMD and ARM".

https://www.exploit-db.com/doc...

Spectre attacks involve inducing a victim to speculatively perform operations that would not occur during correct program execution and which leak the victim's confidential information via a side channel to the adversary. This paper describes practical attacks that combine methodology from side channel attacks, fault attacks, and return-oriented programming that can read arbitrary memory from the victim's process. More broadly, the paper shows that speculative execution implementations violate the security assumptions underpinning numerous software security mechanisms, including operating system process separation, static analysis, containerization, just-in-time (JIT) compilation, and countermeasures to cache timing/side-channel attacks. These attacks represent a serious threat to actual systems, since vulnerable speculative execution capabilities are found in microprocessors from Intel, AMD, and ARM that are used in billions of devices

If AMD are confident enough in their AES engine to put in in inline with the RAM and memory controller, they could probably work out how to make it do process isolation by encryption. E.g. if you could set it up so kernel memory was AES 128 encrypted with a random key then it would matter less if a user process was able to read it.

But what happens when you have virtualization? AMD's scheme protects guests from hosts. I'm not sure how you could additionally protect kernels in a guest OS from processes in that same guest OS.

LWN published articles indicating a problem back in November, and followed up on it a number of times.

That the Kernel devs would prioritize a fairly invasive patch set, reducing performance up to 30% was a sign that something was amiss.

The fact the LKML had practically no discussion for why so much effort was being expended on it was a sign that something was very, very wrong.

Funny thing is that this bug is almost an example of Intel throttling old hardware. The KPTI fix is apparently less of a performance hit if you have a new Intel CPU with PCIDs

https://www.theregister.co.uk/...

Crucially, these updates to both Linux and Windows will incur a performance hit on Intel products. The effects are still being benchmarked, however we're looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. More recent Intel chips have features - such as PCID - to reduce the performance hit. Your mileage may vary.

PCID - Process Context ID - means you can tag the TLB entries with a 11 bit process ID.

http://forum.osdev.org/viewtop...

Also, the Intel manual says bit 0-11 of CR3 is used as the PCID. Does it somehow related to the usual process id user mode code see? If yes, does it mean it imposes a limit on the # of user processes (4096) allowed ?

Which means you don't need to flush the whole TLB - you just invalidate the ones which belong to a process you're switching away from

http://linuxeco.com/?p=488

A PCID is a 12-bit identifier, and may be thought of as a "Process-ID" for TLBs. If CR4.PCIDE = 0 (but 17 of CR4), the current PCID is always 000H; otherwise, the current PCID is the value of bits 11:0 of CR3. Non-zero PCIDs are enabled by setting the PCIDE flag (bit 17 of CR4).

When a logical processor creates entries in the TLBs (Section 4.10.2 of the x86 prog reference manual) and paging structure caches (Section 4.10.3), it associates those entries with the current PCID (Oh ... such a loose association of PCID with PID). Note that this means that where the PGD is located is somehow being interpreted in the PID "process context". When using entries in the TLBs and paging-structure caches to translate a linear address, a logical processor uses only those entries associated with the current PCID, and hence flushes of the TLB are avoided.

Presumably you could have on PCID value for the kernel and the other 4095 for tasks and not need to go a TLB flush when switching until the PCID value wrapped.

Of course that means you need a sufficiently recent Intel CPU.

https://software.intel.com/sit...

FMA, AVX2, BMI1, BMI2, INVPCID, LZCNT, TSX - Haswell and later

I.e. you need a Haswell 4xxx processor or later

https://en.wikipedia.org/wiki/...

At least for the Linux KPTI fix it seems like it does support PCID

https://lwn.net/Articles/74060...

- Integrated all fixes and Peters rewrite of the PCID/TLB flush code.

So does the macOS fix

https://www.macrumors.com/2018...

Ionescu also says that performance drop on a system with PCID (Process-Context Identifiers), available on most modern Macs, is "minimal," so most users may not see an impact on day-to-day Mac usage.

Of course if you have an 2012 Macbook Pro you've got an i5-3210M so you don't have PCID so you'll either have an insecure machine or a performance hit.

Interesting thing is if there was a class action lawsuit, I wonder if you could get Intel to give you a new CPU with PCID to minimise the impact of the bug fix.

Yeah, notice the part where they tried to spread the blame to other CPU manufacturers.

Yeah, and? There's plenty of blame to go around. Just because AMD isn't affected doesn't make their statement about other CPU manufacturers any less true.

Spoiler alert: This isn't even limited to x86.

arm64: Unmap the kernel whilst running in userspace (KAISER)

ARM engineers are supplying the patches for ARM64.

KAISER is the original name of the patch set.

arm64: Unmap the kernel whilst running in userspace (KAISER)

ARM engineers are supplying the patches for ARM64.

KAISER is the original name of the patch set.

What are you smoking?

ARM engineers (not Intel's) are supplying the patches for ARM64.

Some ARM64 chips are affected as well actually. Citation: https://lwn.net/Articles/74039...

I don't see why they would name AMD since it's unaffected however. https://lkml.org/lkml/2017/12/...

really sorry to bust your ARM bubble. https://lwn.net/Articles/74039...

If you read one of the original articles about the KAISER patch set: a commenter asked about microkernels, and the reply is that since it's a hardware issue, both microkernels & monolithic kernels have to pay the same price.

The workaround that is deployed has the effect of making context switches a lot more expensive.
Many microkernels depend on context switches being fast since they use more frequent context switches than a monolitic kernel does.
(you write a block to a file in linux, this is ONE context switch into the kernel. you write a block to a file in minix, you first context switch to the filesystem service, then you context switch to the disk service ...)

It is not unreasonable that some workloads may hurt a microkernel much more than it hurts a monolithic kernel.

An older link, about the KAISER patch set

If you read one of the original articles about the KAISER patch set: a commenter asked about microkernels, and the reply is that since it's a hardware issue, both microkernels & monolithic kernels have to pay the same price.

It's not unique to Intel CPU's. It affects the entire x86 architecture family, including AMD64.

It's not unique to x86 either: ARM64 has patches for the same vulerability.

Linux Weekly News has been covering this for quite a while.

5% slowdown on average, with up to 30% for some particularly bad network operations.

ARM64 is also affected, so it's not just intel

Linux Weekly News has been covering this for quite a while.

5% slowdown on average, with up to 30% for some particularly bad network operations.

ARM64 is also affected, so it's not just intel

That leaves, what?

If online is acceptable to you, lwn.net has been my goto site for many,many years now.

I remember reading Linux Journal while flirting with the cute cashier at a local Tower Records. Today, Linux Journal is gone, Tower Records is gone, and that cute cashier is my friend on Facebook. At least the best element of that part of my life is still around...

I think a lot of what Linux Journal stood for is alive and well with Linux Weekly News. Yes, it's paywalled, but quality content costs real money to make, and the paywalled articles are made free to read after about a month.

Of course some one is being paid. The fact that Microsoft moved their German HQ to Munich have of course absolutely nothing to do with the current administrations decision... That and (quoting from https://lwn.net/Articles/73781... which is paywalled):

by 2013, 15,000 computers had been migrated. In addition, 18,000 LibreOffice templates had been created for documents. Previously, each office had its own templates, but the new ones were shared across the city administration. The mayor who had started the project was "always supporting it", Kirschner said. He continuously backed the team behind Limux.

That all ended in 2014. The old mayor did not run for reelection, so a new mayor, Dieter Reiter, from the same party was elected. Reiter did not like Limux and was quoted in some articles as being a Microsoft fan. He ran partly on the idea of switching away from Limux.

From then on, Kirschner said, "Limux was the cause of all evil in Munich". For example, iPhones did not work with the city's infrastructure, which was blamed on Limux though it had nothing to do with the desktop client. A mail server outage was also unfairly blamed on Limux.

So the switch back to Microsoft is also a political one. It also appears that when performing the switch to Limux the city of Munich also rearranged their entire IT with centralized support etc so how many of the "complaints" that actually comes from Limux or how many that comes from the reorganization is a question.

> How is that C's fault?

This is like saying that there's nothing wrong with a car that has dodgy brakes and no seatbelts or mirrors. After all, it's still possible to drive safely if you try hard enough.

Properly training developers and using tools like Valgrind/ASAN etc does not prevent the critical security bugs that are prevented by safe languages. I've worked with elite C/C++ developers at Mozilla and Google, who use those tools and a lot more, yet such bugs are regularly discovered in shipping code. Here's another take on this: https://lwn.net/Articles/73545...

OWASP is about vulnerabilities in Web applications, practically none of which are written in C or C++. If they were, then OWASP would include bugs like use-after-free and buffer overflow.

A lot of issues with Web application security are because of the dynamically typed languages used, which are a whole different issue. It's certainly not the case that every language other than C is great for security.

If the bridge can be built for about the same cost as the 4x4, why not build the bridge? As a user I'd certainly rather have the bridge.

> Static code analysis and runtime checking (valgrind) pretty makes C's little issues a non-event now.

Just not true, even if you add in manual security audits as well. For example:
https://lwn.net/Articles/73545...

With a dongle : http://hexus.net/tech/news/per...
With some Linux 'firewalls' : USBGuard, https://github.com/dkopecek/us... , USBauth, https://github.com/kochstefan/...
Nice paper on LWV, that's still paying this week but will become free after 8 days as usual : https://lwn.net/Articles/73830...
HTH,
Hervé

BTW : anyone in region 06 in France wishing to share shipping costs for the dongle?

Moglen, chairman for the SFLC, has resigned as a FSF councel last year. Perens has stated that he was in fact fired over conflict on regarding GPL enforcement. The source of the split seems to be this talk at a Linux Foundation event, where he criticised some of his own former compliance efforts, and aligned on the point of view of many members of the kernel community.

Well except for the fact that no mainstream distribution support x32, you have a good point.

I understand some of the Stallman's ideas but they're just an ideology and zero practice. The software should be Free as in Freedom, not Free in Charge. But we have seen is that GPL makes the software Free as in Beer. Selling a GPLed software to consumers is like selling sand in a desert. That's the reason why there'll newer be "The Year of the Linux Desktop", nobody will write a clean consistent GUI and do a proper QA and regression testing if doesn't bring an income. The same goes for other FOSS projects. With the advent of the GPL3 bullshit the commercial world shunt away from "Free Software" and began to switch to "Open Source". One good example is GCC vs Clang. Years ago people were saying that Clang would never reach the maturity of GCC. But now many large companies like Google have switched to Clang because it has much better static analysis, PGO and better integration with an IDE which GCC refuses cause of fear of proprietary plugins. Even Linux kernel developers are considering switching to Clang. https://lwn.net/SubscriberLink... Like it or not but GCC's era will end sooner or later. Another example is Google's Fuchsia. When ideology and practice collide, practice always wins.

According to Gnome developers, removing of the system tray is so insignificant, that it is not even worth mentioning in the short list of changes. It is mentioned at the end of the long list, outside of the bullet points.

GNOME 3.26 no longer shows status icons in the bottom-left of the screen. This prevents the status icon tray from getting in the way and is expected to provide a better overall experience. The lack of status icons is not expected to cause serious issues for users. However, if you do find that you need to access them, they can be restored using the TopIcons extension. More information about this change can be found in a blog post on the subject.

This means that if you don't have the latest TopIcons extension already installed, a lot of programs that minimize to Status Bar will become inaccessible. That's mainly non-Gnome programs.

Gnome developers are trying to force application developers to not use the "pretty old" standard that "predated Gnome 2.0" and instead to use Gnome specific API's like their notification.

The big problem is that they do not seem to understand what is the purpose of the Status Bar, how people use it and why it exists in all Desktop platforms - Linux, Windows and Mac.
The Status Bar is for checking the status of an application, with single glance, without need for any actions from the user, like moving mouse to specific position on the screen, having to click, switch desktops or open the program window.
In comparison, notification are for signaling change or event. Their use is not only different, they also could be quite annoying and actively ignored.

Here are few more links to read:
https://blogs.gnome.org/aday/2017/08/31/status-icons-and-gnome/
https://lwn.net/Articles/732622/

All of this whining is coming from the same open-source community leader (Torvalds) that has publicly shunned GRSecurity

Do you mean this grsecurity? Anyway, your characterization is total bullshit. Torvalds is willing to accept grsecurity features piecemeal, but not willing to accept grsecurity as a monolithic patch. The grsecurity team cries about how that's not feasible because they've been developing grsecurity in their free time, but the real problem is that they were developing it in a vacuum. They failed to take the linux kernel project seriously, and now they want people to take grsecurity seriously. They're arrogant, hypocritical fucks who, by the way, are also shit at documentation. If they wanted to enhance Linux security, what they should have done was write decent tools for selinux. That's what it's missing.

The biggest problem with Android in particular and SoC platforms like ARM or MIPS is that all the hardware stuff is closed off and there are no standards

The ARM subsystem was refactored a few years back in view of this. There are perfectly good reasons why SoC can benefit by doing its own thing, but the general trend is in the direction of commonality, which lowers engineering costs for everyone in the long run.

Falcon 9 runs on Linux kernal. Not sure if it's Ubuntu or Red Hat tho.l

Microsoft managed to change time_t to 64-bit due to time_t not being widely used in Windows and because shared libraries on Windows rarely exchange time_t values (since that would break if you linked with an old dll that used the 32-bit time_t as you might imagine).

Stance in Linux land regarding the issue is not to go 64-bit or be abandoned, there are plans in motion, it's just that there are a lot of code to go over and change since time_t is a central piece in Unix vs Windows where it's practically not used anywhere.

GNU libc has this plan: https://sourceware.org/glibc/w...

And the plans for the Linux kernel: https://lwn.net/Articles/64323... . Latest update: https://lwn.net/Articles/71707...

Microsoft managed to change time_t to 64-bit due to time_t not being widely used in Windows and because shared libraries on Windows rarely exchange time_t values (since that would break if you linked with an old dll that used the 32-bit time_t as you might imagine).

Stance in Linux land regarding the issue is not to go 64-bit or be abandoned, there are plans in motion, it's just that there are a lot of code to go over and change since time_t is a central piece in Unix vs Windows where it's practically not used anywhere.

GNU libc has this plan: https://sourceware.org/glibc/w...

And the plans for the Linux kernel: https://lwn.net/Articles/64323... . Latest update: https://lwn.net/Articles/71707...

Since the world is adopting the American National Operating System (Win 10)

Isn't Linux developed by an American?

Both MD5 and SHA-1 are perfectly good hashing algorithms for non-cyptographic purposes. Removing them make me think that the Alpine folks don't know exactly what they are doing.

Based on how the summary is worded,

And in addition, "MD5 and SHA-1 hashes have been removed from APKBUILDs, being obsoleted by SHA-512.

I'm guessing they replaced MD5 and SHA1 hashes for validating their repositories. Since both MD5 has collision vulnerabilities and SHA1 is starting to have attacks as well, it is probably wise to obsolete these hashes in favor of a new hash. Even Git developers are starting to make plans to move away from SHA1.

An example of real-world problem: crappy init scripts. With sysv-init a shutdown sequence can hang forever, for example. It's not a theory, it happened to me personally: https://lwn.net/Articles/61679...

Team effort to a fault at times :/

Here's Fedora trying to come up with a release name for Fedora 20:
https://fedoraproject.org/wiki...

Which, whatever, ok...

Eventually they decided they could never come up with release names any more, it was just too hard:
https://lists.fedoraproject.or...

Which is why you'll see stuff like 'Fedora Core 25 ("Twenty Five")' - the part in quotes was supposed to be a fun name. But every name is offensive.

https://lwn.net/Articles/48890...

You can't name things after astronomical objects, because those are offensive, because Mars is offensive (apparently lol). Anything named after something religious or mythological offends an atheist. Coffee can't be used because some religions are offended by coffee. Scientist names are sexist because most of them are men, and they even tried that card to claim numbers are offensive, but that one apparently didn't fly.

So when everyone gets together to name something, they eventually just decide that Things are simply not nameable, lest someone be offended. If instead, some asshole was in charge of naming, it would just be named GloryPork and anyone who wanted to bitch about it would have their complaints circular filed. There are benefits to just some asshole in charge.