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] [day] [month] [year] [list]
Date:   Sat, 13 Feb 2021 08:44:18 -0800
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Willy Tarreau <w@....eu>
Cc:     linux-kernel@...r.kernel.org, rcu@...r.kernel.org,
        kernel-team@...com
Subject: "Single user mode" initrd [ Was: [GIT PULL tip/core/rcu] RCU, LKMM,
 and KCSAN commits for v5.12 ]

[ Dropping non-list CCs. ]

On Sat, Feb 13, 2021 at 01:36:58PM +0100, Willy Tarreau wrote:
> Hi Paul,
> 
> On Fri, Feb 12, 2021 at 07:07:05AM -0800, Paul E. McKenney wrote:
> > Thank you, Ingo!  In the future, I will group nolibc with RCU.  But there
> > has to be something other than RCU that needs it.  I will take a look. ;-)
> 
> All my kernels boot using a "preinit" that is built with nolibc and
> integrated into the initramfs. Historically it used to just create /dev
> entries and mount the rootfs, nowadays it's used to untar modules and
> finish the boot so that I can have a clean separation between a kernel
> image and a rootfs. It even allows to perform some minimal debugging as
> it includes a minimalistic shell. Do you think something like this could
> be of any use in your development sessions ? If so I can discuss this
> with you in a separate thread so as not to annoy everyone. Just let me
> know :-)

I currently use virtme when I need to poke around in userspace, which
has been working well so far.

I suspect that your preinit could be used to make a boot-loader that
automatically knows the needed Linux-kernel filesystems, thus avoiding
the long series of bugs due to filesystem mismatches between the Linux
kernel and the boot loader.  In the old days, the larger size of the
Linux kernel would have been a problem, but given the size of firmware
these days, this should no longer be a problem.

But my guess is that this has already been tried.  Plus there would have
to be someone quite excited about doing a large body of boot-loader work.

Thoughts?

							Thanx, Paul

Powered by blists - more mailing lists