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 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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ