linux-kernel - Re: [PATCH 07/11] kexec: Disable in a secure boot environment

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: <20120904214015.GA31325@srcf.ucam.org>
Date:	Tue, 4 Sep 2012 22:40:16 +0100
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, linux-efi@...r.kernel.org
Subject: Re: [PATCH 07/11] kexec: Disable in a secure boot environment

On Tue, Sep 04, 2012 at 10:39:57PM +0100, Alan Cox wrote:
> > > Well, given that approximately everyone will be booting under EFI within 
> > > 18 months, treating it as a niche case seems a little short sighted.
> 
> Actually the majority of Linux devices are not PCs 8)

ARM's going UEFI as well...

> I think it needs to be defined in terms of what the capability is
> supposed to guarantee. I have a feeling Matthew has a pretty clear idea
> about that in his head so can nail it fairly precisely ?

In the absence of this capability, all users (including root) should be 
unable to cause untrusted code to be executed in ring 0. This requires 
some straightforward and obvious conditions like "The user must not be 
able to load untrusted modules", but also conditions like "The user must 
not be able to cause devices to DMA over the kernel". "The user must not 
be able to kexec into an untrusted kernel" is at the more obvious end of 
the scale. This is obviously dependent upon there being some mechanism 
for ensuring that the initial kernel is trusted in the first place, 
which is where the firmware security comes in.

-- 
Matthew Garrett | mjg59@...f.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/