Removal of Loadable Kernel Modules and Custom Kernels

[shep]

Loadable Kernel Modules were removed and I can see the rationale for not having bits of code randomly insert into the stack. Conversely, that would mean more unused devices are in the kernel itself including some that may be a security risk. I'm thinking specifically of Intel and Via random number generators which I understand are not used.

Given the paranoia revolving around what is really in a device chip, would there be a stronger argument for stripping a kernel of unneeded devices?

[jggimi]

I can recall only a single LKM ever made available publicly - emulators/kqemu, which was removed nearly four years ago. I'd been a user of it, and I recall it was removed after it was dropped upstream. Without kqemu, I didn't perceive any need to keep LKM services -- in my opinion, these were vestigial from Unix or early BSD systems and now rendered unnecessary, as the OpenBSD kernel had been effectively monolithic its entire life.

My opinion of history, of course, is incompletely informed, and probably biased. But whether or not I got it exactly right, we no longer have LKM capability.

---

Fact: OpenBSD has a monolithic kernel.

Fact: Kernel stripping is unsupported.

Fact: Stripped kernels are never tested by the developers.

Fact: Some kernel components, such as peripheral device drivers, can be removed independently without obvious problems, such as failure to compile or boot.

Fact: You can remove any kernel components you want, but you become fully responsible for your own OS support.

Fact: a large group of security focused OS developers don't see unused drivers as a significant security risk.

Conjecture: successfully removing some components might have unintended consequences, such as introducing new race conditions through shorter code paths that would not be taken when using a GENERIC kernel.

[jggimi]

In further support of the monolithic history, except kqemu, whenever we added kernel drivers above and beyond GENERIC we built custom kernels, these were never written as kernel modules. The two that come to mind were RAIDframe and NTFS. The former was replaced by softraid(4), the latter became part of GENERIC on applicable architectures.

[thirdm]

Originally Posted by shep

Given the paranoia revolving around what is really in a device chip, would there be a stronger argument for stripping a kernel of unneeded devices?

How does the driver code get executed if you don't have the device? I'm not a kernel programmer but I'd think if someone could get the kernel's PC pointed into weird places like that the game's already over. In favour of a simple kernel image with all supported drivers in it, as I think has been pointed out by developers, there's a testing advantage to having a common image many people use. It helps control combinatorial explosion.

[shep]

How does the driver code get executed if you don't have the device?

I have 2 Via motherboards that do have the hardware. I did look at the /usr/src/sys/arch/amd64/conf/GENERIC and did not see any drivers for Intel or Via Random number generators

[jggimi]

Any hardware random number generator will only be one of many entropy sources for this OS. Start at page 19 of Theo De Raadt's 2014 arc4random presentation. There's a video of the presentation available.