linux-kernel - Re: RFC: Tainting the kernel on raw I/O access

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:	Wed, 03 Sep 2014 15:25:32 -0700
From:	"H. Peter Anvin" <h.peter.anvin@...el.com>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Matthew Garrett <mjg59@...f.ucam.org>
Subject: Re: RFC: Tainting the kernel on raw I/O access

On 09/03/2014 03:20 PM, One Thousand Gnomes wrote:
> 
> If you just want some "detector bits" for bug report filtering them its
> quite a different need to fixing "secure" boot mode. Even in the detector
> bits case there should be an overall plan and some defined properties
> that provide the security and which you can show should always be true.
> 

As far as I'm concerning this is just a set of "detector bits".  My
observation was simply that this is a *subset* of what "secure boot"
will eventually need.

Secure boot will need the error path no matter what... tainting
obviously doesn't.

(As far as I'm concerned, I'd be happy tainting the kernel for any
operation that requires CAP_RAWIO, but maybe that is too extreme.)

	-hpa


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