linux-kernel - Re: Kernel-only deployments?

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: <d47f1f4b828e6099c7db2ca4a4728536b3ad2723.camel@petrovitsch.priv.at>
Date:   Thu, 23 Aug 2018 21:52:17 +0200
From:   Bernd Petrovitsch <bernd@...rovitsch.priv.at>
To:     paulmck@...ux.vnet.ibm.com, nicolas.pitre@...aro.org,
        josh@...htriplett.org
Cc:     linux-kernel@...r.kernel.org
Subject: Re: Kernel-only deployments?

Hi all!

On Thu, 2018-08-23 at 10:43 -0700, Paul E. McKenney wrote:
> [...]
> Does anyone do kernel-only deployments, for example, setting up an
> embedded device having a Linux kernel and absolutely no userspace
> whatsoever?
[...]
> You see, rcutorture runs entirely out of initrd, never mounting a real
> root partition.  The user has been required to supply the initrd, but

IMHO running programs from the initrd is in user-space, but anyways:

Ages ago at some former employer, we built an embedded Linux device on
an MPC-860 board (but that shouldn't make a significant difference to
other architectures) based on the (at that time) brand new 2.4 kernel
which ran completely out of the initrd (which obviously contained the
whole root filesystem).

[...]
> by throwing out everything not absolutely needed by the dash and sleep
> binaries, which got me down to about 2.5MB, 1.8MB of which was libc.

We had a working glibc binary (which as the largest binary on the
filesystem) and just used it (and never got time and/or necessity to
use something else like ulibc, newlibc or build glibc ourselves to
leave all unneeded stuff out).

We basically built the filesystem - the distribution as such;-) - from
scratch (only self-crafted `configure` calls around[0]) and - thus -
used busybox and ash (IIRC) - so throw dash, core-utils etc. away and
just use busybox (or something similar) for further space savings.

The whole startup and daemon management was done with busybox' "init"
via a simple /etc/inittab (that were the good old times;-) and it was
enough as one can start one-time programs at boot time (e.g. to load
kernel modules (and remove the file in the filesystem from the
filesystem[0]) or configure stuff via sysctl) and restart daemons. We
didn't need run-levels ...

> This situation of course prompted me to create an initrd containing
> a statically linked binary named "init" and absolutely nothing else
> (not even /dev or /tmp directories), which weighs in at not quite 800KB.

That is probably the smallest solution - if it's enough. If it's all
GPL, just link it statically against dietlibc ....

We had all of the usual directories and a somewhat filled /dev
(completely static in the initrd IIRC, no udev or similar dynamic stuff
was needed) as we had dropbear as ssh-server, a small webserver+CGI-
script for a web interface and a SNMP agent (hacked net-smtp as we had
our own configuration daemon and needed SNMP only as a transport
protocol).

[...]

MfG,
	Bernd

[0]: Every byte counts and size does matter;-)
-- 
Bernd Petrovitsch                  Email : bernd@...rovitsch.priv.at
                     LUGA : http://www.luga.at