[HN Gopher] Linux Kernel Defence Map - Security Hardening Concepts
___________________________________________________________________
Linux Kernel Defence Map - Security Hardening Concepts
Author : transpute
Score : 139 points
Date : 2025-04-05 22:16 UTC (4 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| nine_k wrote:
| The number of defenses is pretty impressive. The number of out-
| of-tree and commercial defenses is also impressive. The amount
| dedicated to specifics of C (UB, bounds checks, use-after-free)
| is relatively small.
|
| It would be interesting to compare to, say, OpenBSD, with its
| apparently numerous security and defense-in-depth features.
| zie wrote:
| > It would be interesting to compare to, say, OpenBSD, with its
| apparently numerous security and defense-in-depth features.
|
| I'm not sure that would be a very fair comparison. A lot of
| OpenBSD security comes from just skipping giant swaths of
| stuff. Advanced filesystems are non-existent, Bluetooth is non-
| existent, etc.
|
| I haven't done a count lately, but I would guess the Linux
| Kernel alone is larger than the OpenBSD base system. It's
| simplicity is a huge security feature. Provided you don't need
| some of those features.
|
| I'm not saying this as an OpenBSD hater or anything, I run
| OpenBSD on at least one machine.
| acje wrote:
| I find it inspiring that we are getting to where we are dealing
| with models that classify vulnerabilities at a systems level.
| However I also think we are kind of barking up the wrong three.
| There is IMHO something wrong with the current strategy of
| scaling up the von Neumann architecture. It leads to fragile
| software partitioning, noisy neighbors and both slow and
| sometimes unintended communication through shared memory. I've
| tried to lay this out in detail here https://lnkd.in/dRNSYPWC
| simonask wrote:
| I think your take is interesting, but your article does not go
| into details with ideas about how to address these problems at
| the architectural level. Would you like to elaborate?
| acje wrote:
| There is some elaboration in part four of the series. A fifth
| part on actor model, gaps and surfaces is in the works. Part
| four https://lnkd.in/dEVabpkN
| transpute wrote:
| Have you looked at _Barrelfish_ (2011) from Microsoft Research
| and ETH Zurich?
|
| https://www.microsoft.com/en-us/research/blog/barrelfish-exp...
|
| _> "In the next five to 10 years," Barham predicts, "there are
| going to be many varieties of multicore machines. There are
| going to be a small number of each type of machine, and you
| won't be able to afford to spend two years rewriting an
| operating system to work on each new machine that comes out.
| Trying to write the OS so it can be installed on a completely
| new computer it's never seen before, measure things, and think
| about the best way to optimize itself on this computer--that's
| quite a different approach to making an operating system for a
| single, specific multiprocessor." The problem, the researchers
| say, stems from the use of a shared-memory kernel with data
| structures protected by locks. The Barrelfish project opts
| instead for a distributed system in which each unit
| communicates explicitly._
|
| Public development stopped in March 2020,
| https://github.com/BarrelfishOS/barrelfish &
| https://barrelfish.org
| nand_gate wrote:
| Vapourware, what they post (microkernels) is nothing new.
|
| As far as a barrel CPUs to replace SMT... _crickets_
| _huayra_ wrote:
| Mothy Roscoe, the Barrelfish PI, gave a really great talk at
| ATC 2021 [0]. A lot of OS research is basically "here's a
| clever way we bypassed Linux to touch hardware directly", but
| his argument is that the "VAX model" of hardware that Linux
| still uses has ossified, and CPU manufacturers have to build
| complexity to support that.
|
| Concretely, there are a lot of things that are getting more
| "NOC-y" (network-on-chip). I'm not an OS expert, but deal
| with a lot of forthcoming features from hardware vendors at
| my current role. Most are abstracted as some sorta PCI device
| that does a little "mailbox protocol" to get some values
| (perhaps directly, perhaps read out of memory upon success).
| Examples are HSMP from AMD and OOBMSM from Intel. In both,
| the OS doesn't directly configure a setting, but asks some
| other chunk of code (provided by the CPU vendor) to configure
| the setting. Mothy's argument is that that is an
| architectural failure, and we should create OSes that can
| deal with this NOC-y heterogeneous architecture.
|
| Even if one disagrees with Mothy's premise, this is a banger
| of a talk, well worth watching and easy to understand.
|
| [0] https://www.usenix.org/conference/atc21/presentation/fri-
| key...
| chenhoey1211 wrote:
| Really solid conceptual map -- not just for kernel devs, but also
| useful if you're working in Rust, Zig, or any low-level system
| code.
|
| Has anyone come across a similar visual breakdown for Wasm
| runtimes, especially around sandboxing and isolation models?
| anthonyryan1 wrote:
| This is by the author of the very helpful kernel-hardening-
| checker: https://github.com/a13xp0p0v/kernel-hardening-checker
|
| An interesting tool for analyzing your personal kernel config
| file and pointing out areas for security improvement. It's more
| comprehensive than KSPP (https://kspp.github.io/) but sometimes
| goes a little too far, suggesting disabling kernel features you
| may actively use.
|
| Definitely worth trying!
| Sponge5 wrote:
| > This map describes kernel security hardening. It doesn't cover
| cutting attack surface.
|
| For those wondering why SECCOMP is ommited.
| hart_russell wrote:
| Do these settings persist if I update the kernel on my ubuntu
| server?
___________________________________________________________________
(page generated 2025-04-09 23:02 UTC)