linux-kernel - Re: Linux 3.10.108 (EOL)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171118073134.GA18973@1wt.eu>
Date:   Sat, 18 Nov 2017 08:31:34 +0100
From:   Willy Tarreau <w@....eu>
To:     Alan Cox <gnomes@...rguk.ukuu.org.uk>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        Sebastian Gottschall <s.gottschall@...wrt.com>,
        Harsh Shandilya <msfjarvis@...il.com>,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: Linux 3.10.108 (EOL)

On Fri, Nov 17, 2017 at 11:46:20PM +0000, Alan Cox wrote:
> > > i just wanted to throw some stones on the bloated kernel problem which is
> > > increasing  
> > 
> > People used to be working on that, but then it seemed like the "size"
> > got to a point that people were comfortable with it.  Are you sure that
> 
> There's also a lot of pushback to things that add a ton of ifdefs.
> 
> > just changing some build options would not make your image smaller?
> > Letting people know sometime in the past few years that the kernel was
> > getting "too big" for you would have been good to do :)
> 
> It's also an increasingly hard problem to deal with because the scale of
> big machines means the algorithms themselves in a modern Linux OS just
> don't make sense for a tiddly embedded router.

It's true but it's also true that a lot of these algorithm can be tuned
at build time. We have various memory allocators, tiny RCU, the ability
to disable SMP, we can even tune certain filesystems to use more or less
buffers, etc. It's not that bad at all and I'm not sure that many other
OSes have this level of flexibility.

> I know lots of people build them that way but if you compare it with one
> of the more conservative *BSD builds you have to wonder why not use BSD
> instead - especially with nanoBSD ?

Well, I maintain a kernel image that I use as a bootloader / recovery image
to (re-)install some machines. The kernel+rootfs image fits in 1.7 MB, and
in that size it supports a few network drivers, SATA, serial console, kexec,
EXT2+VFAT and a few other stuff. Obviously it's a bit limited, but it serves
this purpose well as it needs to fit into a 2 MB partition where GRUB is
already installed. It started with 2.6.16 about 12 years ago, then 2.6.35,
now 3.10.104. The image has increased a bit over time, but it also required
a lot less patches to shrink it.

If that can be useful, I can try to port these patches to modern kernels
to get them merged. However some of them add new options (eg: enable
diag/stats in igb driver, etc) and would probably need to be inverted to
disable certain features based on a central option to make the kernel much
smaller.

> (and BSD has the reverse problem - most BSD does not scale to a modern
> bigger machine of course).
> 
> Alan
> "1.2.13 was the last true Linux"  ;-)

I've been using this one for a while and have even deployed it a few times
as LAN->PPP gateways by reconverting old 2 MB RAM 386's (1.6 MB in fact since
384kB were lost and not remappable by then). It was unbeatable for this
purpose, though I'm not aiming at making this possible nowadays, most
machines have at least a bit more RAM :-)

Willy