Live data from Hacker News

A Higgs-Bugson in the Linux Kernel

blog.janestreet.com

51–58 of 58 posts

Re: A Higgs-Bugson in the Linux Kernel

#51
post #49
post #47

Earlier quoted context omitted.

>You can get the exact same bug in a microkernel Absolutely. And yet, it is that much easier to keep a tiny codebase bug-free. And only that tiny codebase has to run with supervisor privileges.

Of course a tiny microkernel code base won't have NFS bugs. It doesn't implement NFS. The bug will instead be in the NFS process/daemon/service/… which considering it's an fs service won't exactly be unprivileged either, even if only by returning maliciously corrupted contents. (e.g. a SUID root file that should not exist.) And, sure, a microkernel could have better security properties. However, (1) this has no conne…

Not only is the damage contained, but it is also much easier to protect an isolated NFS server.

For instance, instead of being able to read/write/jump literally anywhere in memory, it would only have capabilities to the resources it needs.

And these capabilities would be enforced strictly, by the bug-free microkernel. The likes of seL4 even have formal proof of correctness.

Re: A Higgs-Bugson in the Linux Kernel

#52
post #51
post #49

Earlier quoted context omitted.

Of course a tiny microkernel code base won't have NFS bugs. It doesn't implement NFS. The bug will instead be in the NFS process/daemon/service/… which considering it's an fs service won't exactly be unprivileged either, even if only by returning maliciously corrupted contents. (e.g. a SUID root file that should not exist.) And, sure, a microkernel could have better security properties. However, (1) this has no conne…

Not only is the damage contained, but it is also much easier to protect an isolated NFS server. For instance, instead of being able to read/write/jump literally anywhere in memory, it would only have capabilities to the resources it needs. And these capabilities would be enforced strictly, by the bug-free microkernel. The likes of seL4 even have formal proof of correctness.

And you are still making these arguments on the discussion of a bug that they have absolutely no bearing on. If Linux were written with the same exact development history, but as a microkernel, the exact same bug could (and likely would) exist in the NFS client component. The impact is spurious unavailability of service, and would be the same on a microkernel; it is not exploitable for memory corruption. And any file system service, by its function, will be in a position of relative privilege, even if less so on a microkernel.

Your arguments are likely valid, with other bugs. Please take them there. Wedging this discussion in here just makes you look like a proselytizing zealot.

Re: A Higgs-Bugson in the Linux Kernel

#53
post #3

https://lists.openwall.net/linux-kernel/2025/03/19/1374

I wish developers--new and old alike--pay attention to the commit messages that goes into the kernel. Granted, it takes a subject matter expert to really understand what's being said, but the general format and layout of commit messages is instructive. Commit messages helps the reader/reviewer get their bearings; they also help to build the case from the bottom up. The fact that the development team is globally distr…

The kernel repository has pretty extensive documentation on how to describe the code changes in the commit messages:

- https://docs.kernel.org/process/submitting-patches.html#desc...

- https://github.com/torvalds/linux/blob/master/Documentation/...

- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Git's own guidelines also have a nice description on how to write a better commit message:

- https://git-scm.com/docs/SubmittingPatches

- https://github.com/git/git/blob/master/Documentation/Submitt...

- https://git.kernel.org/pub/scm/git/git.git/tree/Documentatio...

Re: A Higgs-Bugson in the Linux Kernel

#56
post #31

anyone else feel like the linux kernel release quality has come down a bit here in the 2020s? i feel like it hasn't been this bad since the mid 90s. anecdotally in the past couple years, i've experienced a data corruption bug in xfs, wonky wifi firmware/kernel regressions, graphics artifacts and hard crashes in amdgpu. my experience with mainline releases before 2020 has been that they're rock solid. i'd doubt myself…

My experience is the opposite. I run mainline starting with -rc1 on my gaming pc, its been literally flawless for me since I switched to an AMD RX 7900 XT about two years ago. Ten years ago there was a 50/50 chance -rc1 would fail to boot on at least one of my machines, I can't remember the last time that happened.

Look at all the syzbot automation on the kernel mailing list, as an example of how the process continues to improve.

IMHO the best Linux experience really is to run bleeding edge versions of everything. I wasted a great deal more time backporting patches before I started doing that, than I have spent chasing new bugs since.

Re: A Higgs-Bugson in the Linux Kernel

#57
post #35

Calling this a "Higgs-Bugson" doesn't make a lot of sense. There's nothing uncertain or difficult to reproduce about the Higgs. The reason that it took so long to find was that the cross-section of production is very low, the decay signatures are hard to separate from the background, the specific energy scale it existed at was not well-defined, and building the LHC was (to put it mildly) difficult and expensive. Roug…

A bug that shows up in production but goes away when you try to debug it is usually called a Heisenbug.

Yes - happened to me once. I could reproduce it consistently until I turned tcpdump on , at which point it would go away. I resorted to ebpf as well.

Re: A Higgs-Bugson in the Linux Kernel

#58
post #38

NFS is usually only used in mixed linux/windows environments. The easiest fix is to avoid NFS and esp. Windows. NFS alone is nightmare enough, Windows is just insanity.

I think most of the places I've seen NFS used are all UNIX/Linux shops. Why do you think Windows is commonly involved?
Post reply on HN