linux-kernel - Re: [RFCv2 0/9] UEFI emulator for kexec

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]

Message-ID: <Zt_7UEdDfTAQKp4I@gardel-login>
Date: Tue, 10 Sep 2024 09:54:56 +0200
From: Lennart Poettering <mzxreary@...inter.de>
To: Jan Hendrik Farr <kernel@...rr.cc>
Cc: Philipp Rudo <prudo@...hat.com>, Ard Biesheuvel <ardb@...nel.org>,
	Pingfan Liu <piliu@...hat.com>, Jarkko Sakkinen <jarkko@...nel.org>,
	Eric Biederman <ebiederm@...ssion.com>, Baoquan He <bhe@...hat.com>,
	Dave Young <dyoung@...hat.com>, Mark Rutland <mark.rutland@....com>,
	Will Deacon <will@...nel.org>,
	Catalin Marinas <catalin.marinas@....com>,
	kexec@...ts.infradead.org, linux-efi@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFCv2 0/9] UEFI emulator for kexec

On Mo, 09.09.24 12:42, Jan Hendrik Farr (kernel@...rr.cc) wrote:

> On 09 11:48:30, Lennart Poettering wrote:
> > On Fr, 06.09.24 12:54, Philipp Rudo (prudo@...hat.com) wrote:
> >
> > > I mostly agree on what you have wrote. But I see a big problem in
> > > running the EFI emulator in user space when it comes to secure boot.
> > > The chain of trust ends in the kernel. So it's the kernel that needs to
> > > verify that the image to be loaded can be trusted. But when the EFI
> > > runtime is in user space the kernel simply cannot do that. Which means,
> > > if we want to go this way, we would need to extend the chain of trust
> > > to user space. Which will be a whole bucket of worms, not just a
> > > can.
> >
> > May it would be nice to have a way to "zap" userspace away, i.e. allow
> > the kernel to get rid of all processes in some way, reliable. And then
> > simply start a new userspace, from a trusted definition. Or in other
> > words: if you don't want to trust the usual userspace, then let's
> > maybe just terminate it, and create it anew, with a clean, pristine
> > definition the old userspace cannot get access to.
>
> Well, this is an interesting idea!
>
> However, I'm sceptical if this could be done in a secure way. How do we
> ensure that nothing the old userspace did with the various interfaces to
> the kernel has no impact on the new userspace? Maybe others can chime in
> on this? Does kernel_lockdown give more guarantees related to this?

Yeah, it's not a trivial thing. I.e. I guess things like sysfs and
procfs will retain ownership/access mode. sysctls and sysfs attrs are
going to retain their most recently written contents and things like
that. Synthetic network interfaces, DM devices, loopback devices all
would survive this.

So, no idea how realistic this is, but I would *love* it, not only for
this purpose here, but also for the "soft-reboot" logic we have in
system these days, which shuts down userspace and starts it up again,
as a form of super-fast reboot that doesn't replace the kernel. If we
could reliably reset sysfs/sysctl/procfs/… during this, this would be
really lovely.

Lennart

--
Lennart Poettering, Berlin