Solved Where can I find kernel size figures?

Toolforger

Toolforger

There's that often-quoted claim that FreeBSD is smaller than Linux, kernel-wise.
However, I cannot find any figures for the FreeBSD kernel.

I know that kernel sizes depend on a lot of factors, but I'm after ball-park, just-use-the-vanilla-setup figures, mostly:
* Size of the source code tree (minus the sources included for userland utilities if possible, complete if not possible)
* Size of a plain vanilla kernel with all the standard drivers (I know it can be shrunk, but that's for specialists; I'm interested in what Joe User will get).
 
Something like: du -A -c /boot/kernel
and: du -A -c /usr/src
(after checking out the sources, of course)?

To be compared with the sum of: du --apparent-size -c /boot/vmlinuz-5.4.39_1
and: du --apparent-size -c /lib/modules/5.4.39_1
for the first figure, and: du --apparent-size -c /usr/src/linux-5.4.39
for the second (after installing kernel sources, of course).
 
I'm not sure this kind of comparison will be of any use. I've made a quick test using 'top' and compared the free memory size on 2 VM with each 1792 MB RAM and a fresh install of each OS without any customization:

- 1540 MB free for FreeBSD 12.1
- 1587 MB free for Void Linux (kernel 5.3)

The difference is about 3% - in other words, none of them can claim a clear advantage over the other.

Besides, considering FreeBSD doesn't have the same financial and market support as Linux, this also means that FreeBSD's developers have done a damned good job! ;)
 
Hm, that's unexpected. I hear claims that Linux is "bloated", while FreeBSD is supposed not to be bloated; how come we see roughly identical figures?
I'd like to make the argument that "Linux has more features and hence has a larger attack surface". Well, or I'd like to avoid making such a claim if the assumption is wrong :-)

Source code size is probably the more interesting metric; I'm interested in binary size mostly to double-check that the source size isn't completely off (e.g. due to code style differences and similar).

For Linux 5.6, Wikipedia tells me it's roughly 28 MLoC (and 109 MB kernel size).
Are there similar figures for FreeBSD?

The text I need this for is only about attack surfaces, not about performance characteristics.
 
It depends on whether these claims address the Linux kernel or some Linux distro. There's always this ambiguity with the word 'Linux'.
If you want to use the LoC as a metric, you should compare those pertaining to the same platform, e.g. amd64, and include only the sources of the kernel and modules.
That said, all modern general-purpose OS have to implement the same services, so the attack surface of 2 OS of the Unix family is likely more or less identical.
You're more likely to find significant differences between 2 OS of distinct families, e.g. Windows and Linux.
 
I'm definitely after kernel properties.
It's going to be a box with a fixed software on it, so it's essentially "kernel plus just enough userland to add our scripts".

Hmm... I need to justify going for FreeBSD instead of Linux, and I thought that "bloat" thing of Linux is a bullet point, helpful to convince people who like numbers (for the non-numbers people I have the arguments already, and I find it hard to argue about number of CVEs because you quickly get into a morass of how bad was it really, how many people are trying to find the bugs, and generally too many details, so I hope to stay pretty much at the surface of these arguments).
I believe the most important argument is ZFS (which makes a whole bunch of bullet points for FreeBSD - or, rather, against Linux since disk management in Linux is horrendously complicated).

Windows - that's meh. I'm sure I can find enough numbers and arguments to make it lose the complexity game :-)
 
Code: 
boot > du -h linux.efi
6.4M    linux.efi

Above is an lz4 image with everything built-in and there are no kernel modules or initramfs installed on this system. Is ~6.4M considered too much for a kernel running a modern laptop? If so, what would be a more appropriate size?

Finally, the laptop runs Alpine Linux which is ~ 2.5M compressed so the whole thing (kernel + init + userland) installs in less than 20M.
 
Is this box an internal machine or is it going to be sold?
In the latter case, the BSD license might be a non-technical advantage against which technical arguments can't stand.

Toolforger said:
It's going to be a box with a fixed software on it, so it's essentially "kernel plus just enough userland to add our scripts".
Click to expand...
 
It's going to be a FOSS project so that everybody can set up their own box.
That would work fine with either license :-)

(Full disclosure: https://gitlab.com/toolforger/panicroom - not much to see there yet except concept writeup, next step is documenting the OS setup steps so it becomes repeatable. I started coding but no real results yet.)

The LoC figures are useful, thanks!
 
I personally think LOC is a terrible metric.
There are many modules included with the kernel that simply are not needed for most folks.

The real way to measure FreeBSD kernel size is to build a custom kernel for the particular machine target.
Stripping out anything not needed.
For instance; Who in this day and age needs a floppy disk driver in their kernel?

Building FreeBSD with custom make options I was able to get FreeBSD slimmed down to ~120 megabytes.
That is the entire OS not just the kernel.
FreeBSD defaults to a large number of options that are really not needed.
This is great for compatibility but does make the LOC size larger than necessary. Hence a poor metric for FreeBSD kernel size.

Here is a thread where we discuss slimming down the overall build size of FreeBSD.
This contains no kernel slimming options only build options.
forums.freebsd.org

Share your make.conf and src.conf

Hello :) It would be nice that experienced users shared their make.conf and src.conf to help new users like me :) I know that there are man pages and I read both of them, but real user's configurations are IMHO also helpful!
forums.freebsd.org forums.freebsd.org
 
Ah, but even unused modules can be an attack surface, so they still are relevant.
As for why one would want to have those modules... that's simplicity. Which is a bit of a doubly-edged sword: Less code is a simpler system, but in the case of module and build reductions it also means more complicated setup instructions with more opportunities for mistakes, including security-relevant ones. And if you want to run both on real hardware and in a VM, determining what set of modules you need becomes a bit of a time sink. Trying to support people with a gazillion of different hardware configuration, each making different trimming-down mistakes... a support nightmare, something that's just not doable in an open-source project (but feel free to set up a consultancy for trimming down kernels, while guaranteeing that the old data will always remain accessible - it's certainly doable and not even difficult, it just requires patience and paying customers, so anybody who has that should really do it).
 
You must log in or register to reply here.
Back
Top