From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753971AbbCQUVV (ORCPT ); Tue, 17 Mar 2015 16:21:21 -0400 Received: from bhuna.collabora.co.uk ([93.93.135.160]:53928 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752669AbbCQUVS (ORCPT ); Tue, 17 Mar 2015 16:21:18 -0400 Message-ID: <55088CEC.2010109@collabora.co.uk> Date: Tue, 17 Mar 2015 20:22:04 +0000 From: Simon McVittie Organization: Collabora Ltd. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: Kees Cook , Matthew Garrett CC: "gnomes@lxorguk.ukuu.org.uk" , "linux-kernel@vger.kernel.org" , "james.l.morris@oracle.com" , "serge@hallyn.com" , "linux-security-module@vger.kernel.org" , "hpa@zytor.com" Subject: Re: Trusted kernel patchset References: <1426282708-21485-1-git-send-email-matthew.garrett@nebula.com> <20150316144504.4e013789@lxorguk.ukuu.org.uk> <1426529700.22371.20.camel@nebula.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 16/03/15 21:29, Kees Cook wrote: > I really think "trusted" is the right term here. It's about as > accurate as possible for what this flag means. A subtlety that might make this clearer: there isn't really such a thing as "trusted" in isolation, only "trusted by..." a specific other party; and in this case, as far as I can see, the intended meaning is that lower layers (firmware and/or bootloader) have been configured to trust this particular kernel. It doesn't mean "user-space can trust me not to do bad things", because any kernel, malicious or otherwise, could indeed easily claim that; and if it is lying, what is user-space going to do about it anyway? Rather, it means "the firmware is trusting me not to do things it would consider bad". I assume the intention isn't that it will make privileged bits of userland be more careful to avoid breaking this trust assumption, because the point of this patchset seems to be to make it impossible (modulo bugs) for userland to do that. 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? -- Simon McVittie Collabora Ltd.