linux-kernel - Re: [PATCH v2 0/8] scheduler tinification

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]

Date:   Sun, 11 Jun 2017 11:42:06 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Nicolas Pitre <nicolas.pitre@...aro.org>
Cc:     Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        linux-kernel@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v2 0/8] scheduler tinification

* Nicolas Pitre <nicolas.pitre@...aro.org> wrote:

> > With the stroke of a pen from the CFO: "yes, we can spend more on our next 
> > hardware design!" the problem goes away, overnight, and nobody will look back at 
> > the hardware hack that had only 1MB of RAM.
> 
> Of course hobbyists can already get a Raspberry Pi Zero and run a full 
> featured Linux distro on it... for a mere 5 bucks. That comes with 512MB 
> of RAM so my patches certainly don't make a difference there.

Note that those mere 5 bucks are probably 50 cents or less in bulk. Perfectly fine 
economics for many types of 'throw away IoT hardware' products.

> But that's not that simple.  First there is a fundamental constraint 
> which is power consumption. If you want your device to run for months 
> (some will hope years) from the same tiny battery then you just cannot 
> afford SDRAM. So we're talking static RAM here. And to keep costs down 
> because you want to give away your thingies by the millions for free it 
> usually means single-chip designs with on-chip sub-megabyte static RAM.  
> And in that field the 256KB mark is located towards the high end of the 
> spectrum.  Many IPv6-capable chips available today have less than that.
> 
> And the thing is: people already manage to do a awful lot of stuff in 
> such a constrained device. Some probably did a good job of it, but most 
> of them likely suck and we don't know about their bugs because we have 
> no idea what's running inside.

Ok, let me put it this way: there's no way in hell I see a viable Linux kernel 
running (no matter how stripped down) in 32K or even 64K of RAM. 256K is a stretch 
as well - but that RAM size you claim to be already 'high end', so it probably 
wouldn't be used as a standardized solution anyway...

Today a Linux 'allnoconfig' kernel, i.e. a kernel with no device drivers and no 
filesystems whatsoever and with everything optional turned off (including all 
networking!), is over 2MB large text+data (on x86, which has a compressed 
instruction set - it would possibly be larger on simpler CPUs):

 triton:~/tip> size vmlinux
    text    data     bss     dec  filename
  926056  208624 1215904 2350584  vmlinux

A series that shrinks the .text size of the allnoconfig core Linux kernel from 1MB 
to 9.9MB in isolation is not proof.

There will literally have to be two orders of magnitude more patches than that to 
reach the 32K size envelope, if I (very) optimistically assume that the difficulty 
to shrink code is constant (which it most certainly is not).

I.e. the whole stated premise of the series is wildly not realistic AFAICS, the 
series does not make Linux more usable at all on that category of devices (Linux 
is totally inadequate because it's way too large), it only increases its 
complexity.

But you can prove me wrong: show me a Linux kernel for a real device that fits 
into 32KB of RAM (or even 256 KB) and _then_ I'll consider the cost/benefit 
equation.

Until that happens I consider most forms of additional complexity on the 
non-hardware dependent side of the kernel a net negative.

Thanks,

	Ingo