[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <550962C5.5050400@collabora.co.uk>
Date: Wed, 18 Mar 2015 11:34:29 +0000
From: Simon McVittie <simon.mcvittie@...labora.co.uk>
To: Matthew Garrett <matthew.garrett@...ula.com>
CC: "keescook@...omium.org" <keescook@...omium.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"james.l.morris@...cle.com" <james.l.morris@...cle.com>,
"gnomes@...rguk.ukuu.org.uk" <gnomes@...rguk.ukuu.org.uk>,
"serge@...lyn.com" <serge@...lyn.com>,
"linux-security-module@...r.kernel.org"
<linux-security-module@...r.kernel.org>,
"hpa@...or.com" <hpa@...or.com>
Subject: Re: Trusted kernel patchset
On 17/03/15 20:42, Matthew Garrett wrote:
> On Tue, 2015-03-17 at 20:22 +0000, Simon McVittie wrote:
>> Is the intention instead that it will make privileged bits of userland
>> more careful to avoid breaking the trust chain in ways that would "fail
>> safe" by refusing to boot?
>
> Not really. It's intended to avoid the situation where privileged
> userspace is able to modify the running kernel to an extent that's
> broadly equivalent to booting an arbitrary kernel.
Sorry, I was imprecise about what I meant by "it". I understand that the
intention of the patchset as a whole is to prevent privileged userspace
from subverting the kernel; I was asking about the intention of the
ability to read from /sys/kernel/security/trusted_kernel.
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
--
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