linux-kernel - Re: [PATCH 12/12] Add option to automatically set trusted

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 26 Feb 2014 22:48:38 +0000
From:	Matthew Garrett <matthew.garrett@...ula.com>
To:	"gnomes@...rguk.ukuu.org.uk" <gnomes@...rguk.ukuu.org.uk>
CC:	"keescook@...omium.org" <keescook@...omium.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"jmorris@...ei.org" <jmorris@...ei.org>,
	"hpa@...or.com" <hpa@...or.com>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"linux-security-module@...r.kernel.org" 
	<linux-security-module@...r.kernel.org>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>
Subject: Re: [PATCH 12/12] Add option to automatically set trusted_kernel
 when in Secure Boot mode

On Wed, 2014-02-26 at 22:41 +0000, One Thousand Gnomes wrote:

> I think you have a load more cases to attempt to paper over before you
> even pretend to achieve that goal. Firewire for example. Also it only
> remotely begins to work if you also force CAP_SYS_RAWIO off globally as
> you need to force off things like raw command issuing to various
> controllers (especially as some of that code is written on the basis that
> 'its RAWIO, screw making it secure and doing all the checks we could
> bother with'.

Physical presence is required to do anything meaningful with firewire,
and UEFI secure boot isn't intended to protect against that. Which
controllers will trigger arbitrary DMA in response to raw commands?

> RAWIO also disables things like CPU msr access - which is also quite
> adequate for subverting a kernel.

Patch 7.

> Another issue that needs addressing is firmware. Quite a few of our
> request_firmware cases load device firmware which is not signed into DMA
> capable hardware. Probably also worth checking what the
> architectural guarantees on bogus microcode updates is. Maybe we need
> firmware signing for such cases to match the mod signing ?

Vendors keep telling me that they're validating firmware for new
hardware, and I keep tending not to believe them. Meh. The big problem
with firmware signatures is that we don't necessarily have the right to
distribute modified versions of the firmware, so we'd need detached
signature support. I'm certainly not against this.

> I'm trying to think what else. Possibly disabling it on Pentium-M with
> the rep movs erratum (Y19) as it's quite possible to set up suitable
> adjacent page sets in user space via the graphics.

Quirking this out when the hardware makes it impossible to provide any
guarantees seems reasonable.

-- 
Matthew Garrett <matthew.garrett@...ula.com>