linux-kernel - Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

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:   Tue, 4 Apr 2017 14:53:12 -0400 (EDT)
From:   Nicolas Pitre <nicolas.pitre@...aro.org>
To:     Tom Zanussi <tom.zanussi@...ux.intel.com>
cc:     Andy Shevchenko <andy.shevchenko@...il.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Stuart Longland <stuartl@...glandclan.id.au>,
        Andi Kleen <andi@...stfloor.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>,
        "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for
 embedded systems

On Tue, 4 Apr 2017, Tom Zanussi wrote:

> Yes, in a previous project, I had been working toward getting a < 1M
> system to boot on Galileo hardware (which it did, but using more than
> that - the Galileo2 has 256MB, but it was the target hardware at the
> time, and I was hoping eventually to be able to boot out of the 512k
> on-chip SRAM).
> 
> I was focused at that point mainly on the kernel static size, and using
> a combination of Josh Triplett's tinification tree, Andi Kleen's LTO and
> net-diet patches, and my own miscellaneous patches that I was planning
> on eventually upstreaming, I ended up with a system that I could boot to
> shell with a 455k text size:
> 
> Memory: 235636K/245176K available (455K kernel code, 61K rwdata,
> 64K rodata, 132K init, 56K bss, 3056K reserved, 0K cma-reserved)
> 
> virtual kernel memory layout:
>     fixmap  : 0xfffe5000 - 0xfffff000   ( 104 kB)
>     vmalloc : 0xd05f0000 - 0xfffe3000   ( 761 MB)
>     lowmem  : 0xc0000000 - 0xcfdf0000   ( 253 MB)
>       .init : 0xc1094000 - 0xc10b5000   ( 132 kB)
>       .data : 0xc1071fac - 0xc1092760   ( 129 kB)
>       .text : 0xc1000000 - 0xc1071fac   ( 455 kB)
> 
> That was without networking.  Enabling networking added about 250k, and
> at that point I could ssh in and run a webserver, still less than 1M as
> far as kernel static size, which of course completely ignores the kernel
> dynamic size and userspace.
> 
> My goal was to get rid of shell access and dropbear altogether and have
> all access be via webserver, which I did by using nostromo, mainly for
> convenience, until I could get some 'cgi' added to Alan Cox's µWeb
> (about 20k).
> 
> Anyway, that work, as I left it a couple years ago, is here, in case
> anyone's interested (it's a yocto layer and yocto-based kernel
> containing many topic branches, but building it according to the
> directions in the README will yield a standard kernel and .config in the
> working directory and allow you to ignore all the yocto stuff): 
> 
> https://github.com/tzanussi/linux-yocto-micro-4.1  
> https://github.com/tzanussi/meta-microlinux/tree/jethro

Thanks for sharing I'll certainly have a look.

> It's nice to see tinification work being done again - at the time I
> stopped working on it it seemed there was no desire from maintainers in
> general to merge anything that would create new options designed only
> for the purpose of tinification.

I successfully provided an option to disable POSIX timers lately. A 
round trip into the Kconfig parser was required to achieve that though.

Many maintainers are resistant to change as their role is to preserve 
stability of their code. Adding special cases in existing code makes it 
much harder to maintain and validate. Sometimes it is way better to have 
a parallel implementation rather that destabilizing the one version 
available... as long as the interface is the same and that the big and 
tiny versions can be used interchangeably.

> In fact, as a kind of backup plan for that, I also played around with
> the idea of auto-generating a kernel that would contain only the
> functions that were demonstrated to be used by the (single-purpose)
> workload.  It was similar to the idea of making every system call
> configurable and then including only the ones used by the workload, but
> taking it a step further and doing that for every function in the
> kernel, not just system calls.

I thought about that too... and dismissed the idea as being too 
frightening!

> I had a script that would take the output of the function_hist histogram
> taken while exhaustively running the workload:
> 
>   https://lkml.org/lkml/2015/5/20/994
> 
> And with a kernel compiled using -ffunction-sections removing all
> functions that were never referenced.  I never got a bootable kernel out
> of it, but mainly just because I ran out of time and had to move onto
> other things.  I may dust it off and try again, just for fun... ;-)

That would be great.

I really wish to stir up interest from more people and have Linux gain 
momentum in the tiny system space.


Nicolas