From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932345AbbCQUmz (ORCPT ); Tue, 17 Mar 2015 16:42:55 -0400 Received: from mail-bl2on0138.outbound.protection.outlook.com ([65.55.169.138]:55680 "EHLO na01-bl2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752741AbbCQUmw (ORCPT ); Tue, 17 Mar 2015 16:42:52 -0400 From: Matthew Garrett To: "simon.mcvittie@collabora.co.uk" CC: "keescook@chromium.org" , "linux-kernel@vger.kernel.org" , "james.l.morris@oracle.com" , "gnomes@lxorguk.ukuu.org.uk" , "serge@hallyn.com" , "linux-security-module@vger.kernel.org" , "hpa@zytor.com" Subject: Re: Trusted kernel patchset Thread-Topic: Trusted kernel patchset Thread-Index: AQHQYDA3AooV4Q4CdEWM7HLx0fA65p0hH7AAgAAFzQA= Date: Tue, 17 Mar 2015 20:42:51 +0000 Message-ID: <1426624970.22371.33.camel@nebula.com> References: <1426282708-21485-1-git-send-email-matthew.garrett@nebula.com> <20150316144504.4e013789@lxorguk.ukuu.org.uk> <1426529700.22371.20.camel@nebula.com> <55088CEC.2010109@collabora.co.uk> In-Reply-To: <55088CEC.2010109@collabora.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.169.119.23] authentication-results: collabora.co.uk; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB423; x-forefront-antispam-report: BMV:1;SFV:NSPM;SFS:(10019020)(6009001)(377424004)(24454002)(66066001)(2900100001)(92566002)(102836002)(2950100001)(86362001)(2656002)(87936001)(77156002)(62966003)(103116003)(106116001)(93886004)(2501003)(2351001)(36756003)(76176999)(54356999)(33646002)(99286002)(46102003)(40100003)(50986999)(110136001)(122556002);DIR:OUT;SFP:1102;SCL:1;SRVR:BN1PR05MB423;H:BN1PR05MB423.namprd05.prod.outlook.com;FPR:;SPF:None;MLV:sfv;LANG:; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(601004)(5002010)(5005006);SRVR:BN1PR05MB423;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB423; x-forefront-prvs: 0518EEFB48 Content-Type: text/plain; charset="utf-8" Content-ID: <30CFFF0688B2DC4CBEF994817DB0CFBB@namprd05.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: nebula.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2015 20:42:51.0709 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d9cc6df8-58db-46f5-bf3e-083732d8ac63 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB423 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id t2HKh4F6005060 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. {.n++%ݶw{.n+{G{ayʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I