Linux 6.1 Feature Would Have Caught All memcpy Based Buffer Overflows Of Recent Years

[kylew77]

Sure they could. Nothing stops you from disabling Bluetooth in firmware settings. But there happens to be a reason why OpenBSD isn't as common an OS as Linux: "My way or the highway" ultimatums just piss most people off who will in turn tell you to shove it. Security beyond a certain point becomes tyranny. Where that point is differs between individuals, but generally speaking, just ignoring a feature because you don't like it (like Theo did with WIFI for years) is bound to not win you any converts. In the end he got overruled by other developers that wanted the convenience of WIFI networking with reasonable security protocols.

That comes from someone that does use OpenBSD as a secondary system. I continually get irritated by their "principled stands" that amount more to posturing than any practical or proven security measures or vulnerabilities.

Yeah Theo's way or the highway gets old. OpenBSD could have wine and that would be nice but changes won't be accepted to make wine compile on it. Same with ZFS. It sucks.

[sinepgib]

Sure they could. Nothing stops you from disabling Bluetooth in firmware settings. But there happens to be a reason why OpenBSD isn't as common an OS as Linux: "My way or the highway" ultimatums just piss most people off who will in turn tell you to shove it. Security beyond a certain point becomes tyranny. Where that point is differs between individuals, but generally speaking, just ignoring a feature because you don't like it (like Theo did with WIFI for years) is bound to not win you any converts. In the end he got overruled by other developers that wanted the convenience of WIFI networking with reasonable security protocols.

That comes from someone that does use OpenBSD as a secondary system. I continually get irritated by their "principled stands" that amount more to posturing than any practical or proven security measures or vulnerabilities.

I think there was a joke there

[willmore]

I think there was a joke there

Other than Theo?

[ll1025]

Cheri is example of building something with valgrind like checks into the CPU instruction set and the silicon.

The reality these problems have been going on for decades. The overhead to fix the issue correctly people have not been willing to put up with. Yes silicon or software runtime checking.

This seems like one of those academically interesting game theory situations, a sunk cost fallacy.

There are a wide range of historical secure fixes for known issues that have been deemed too expensive-- see for instance the retbleed mitigations that had been known for years. And so often the secure fix is avoided for some hackish band-aid, and bolstered by a huge range of security products: L7 firewalls, IDS, SIEMs, EDR, etc. And when you consider the overall resource usage by increasingly intrusive EDR, and the cost of growing cybersecurity threats, one wonders how sound the math is that concludes that the secure fixes are not worth the cost.

I honestly wish the Linux kernel devs would pay a lot more attention to security and treat it seriously. It's mind-boggling-- especially after Microsoft's disastrous 2015-2020 years in security-- to see increasingly architectural bugs affect Linux far more than Windows because Microsoft has actually put in some effort while Linux tries to hold on to every bit of performance out of some theory that security bugs aren't special.

[oiaohm]

This seems like one of those academically interesting game theory situations, a sunk cost fallacy.

It is more complex than that.

one wonders how sound the math is that concludes that the secure fixes are not worth the cost.

We have the same problem over and over again with different classes of faults. Remember when CPU did not have NX bits there were different patches for the Linux kernel to attempt to make up for that lack of hardware. Result was horrible performance cost again. Remember Exec Shield and PAX NX never got merged into the Linux kernel back in the day. Yes the software work around to NX bit functionality not being in hardware.

Linux kernel developer have moved to the point that they will now merge security fault fixing faults that have some performance cost.

I honestly wish the Linux kernel devs would pay a lot more attention to security and treat it seriously. It's mind-boggling-- especially after Microsoft's disastrous 2015-2020 years in security-- to see increasingly architectural bugs affect Linux far more than Windows because Microsoft has actually put in some effort while Linux tries to hold on to every bit of performance out of some theory that security bugs aren't special.

Like it or not Linux developers are right that security bugs are not special. Remember anything that can cause a denial of service issue can be a security bug. The reality is its like 99.99% of kernel bugs under closer examination if not fixed could end up with CVE number. It turns out a bug that could not be classified as security bug is truly a rare beast.

Other thing to remember poor performing security fixes will make systems do less processing so a data centre has to consume more power and generated more heat to do the same amount of work. Yes this can lead to other failures.

Architectural bugs are being more of a headache. Remember those start with a silicon design flaw that was missed. Buffer overflow issue turns out to be the same as the NX bit issue of old where it can be simply fixed by the MMU if the MMU is upgraded to do the checks for it.

The sunk cost here is to fix silicon fault you need people to replace their hardware. Then you need the production to be able to make the hardware to replace the broken stuff. This leaded to taking the point of view of creating work around.

The maths on this stuff is not simple. Reality is that fixing lot of these issues will require a lot of parties to agree. Yes Intel and AMD agreeing to add something like cheri to x86 would be good. Then people would have to agree to replace their hardware to get the more secure hardware.

NX bit coming part of platforms has almost made a complete class of bugs disappear. Cheri like stuff for memory management moving from a page based memory system to a object based memory system will also make a huge stack of bugs disappear once we have migrated to the new hardware.

The reality here there are problems that we are still trying to solve with software that should be solved in the ISA of the CPUs.

Also its not that Linux kernel developers are not putting in the effort on security faults. Sometimes putting in more effort does not result in better outcomes. Lot of security defect stuff Microsoft puts in quite limited effort as in enough to solve the problem but does not chance after how to improve the result. Microsoft does get caught out by this from time to time. Both the Microsoft and Linux responses to security bugs both have their downsides.

[sinepgib]

Other than Theo?

I didn't expect that burn. I'll go and buy platsul, see you later.

[willmore]

I didn't expect that burn. I'll go and buy platsul, see you later.

The least important thing to come out of the OpenBSD project is OpenBSD itself.

[kylew77]

The least important thing to come out of the OpenBSD project is OpenBSD itself.

Why do you say that? Sure it is slower, lacks a linuxemulator, wine, a bluetooth stack, but it is rock solid stable, has some of the best man pages, and when it works on your hardware it works well. I think OpenBSD is just about 5 to 10 years behind where Linux is is general use in all areas but security in which case it is leaps and bounds ahead.

[oiaohm]

Why do you say that? Sure it is slower, lacks a linuxemulator, wine, a bluetooth stack, but it is rock solid stable, has some of the best man pages, and when it works on your hardware it works well. I think OpenBSD is just about 5 to 10 years behind where Linux is is general use in all areas but security in which case it is leaps and bounds ahead.

https://www.infoworld.com/article/3099038/openbsd-60-tightens-security-by-losing-linux-compatibility.html

OpenBSD values security ahead of general usability.

Do note OpenBSD does not count security bugs as special either. OpenBSD advantage over Linux is that its a complete stack. Now if you need to use something outside the OpenBSD stack you are screwed and this is why Linux compatibility and wine equals no go.

Freebsd is middle ground in BSD between security and usability.

Also Openbsd is not always leaps and bounds ahead of Linux kernel in security. The conservative side of OpenBSD at times has made to slow at times to take up new security technologies.

Its not that black and white.

[kylew77]

https://www.infoworld.com/article/3099038/openbsd-60-tightens-security-by-losing-linux-compatibility.html

OpenBSD values security ahead of general usability.

Do note OpenBSD does not count security bugs as special either. OpenBSD advantage over Linux is that its a complete stack. Now if you need to use something outside the OpenBSD stack you are screwed and this is why Linux compatibility and wine equals no go.

Freebsd is middle ground in BSD between security and usability.

Also Openbsd is not always leaps and bounds ahead of Linux kernel in security. The conservative side of OpenBSD at times has made to slow at times to take up new security technologies.

Its not that black and white.

Sorry for the delayed response. I agree with you about the "OpenBSD values security ahead of general usability." I've never ran OpenBSD as a daily driver just more as a hobby project. With 7.2 I am gonna try to run it as a daily driver and see what it shortcomings are and if it is death by a thousand paper cuts.

I don't know if I agree about FreeBSD being a middle ground what irks me about FreeBSD is all the patching and package updates is done by root over the Internet, even with https that is dangerous to have root connect to the Internet.

Thanks for the civil discussion, Phoronix isn't always know for being civil.