From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Garrett Subject: Re: Trusted kernel patchset for Secure Boot lockdown Date: Fri, 14 Mar 2014 22:15:45 +0000 Message-ID: <1394835345.1286.22.camel@x230> References: <1393445473-15068-1-git-send-email-matthew.garrett@nebula.com> <1394686919.25122.2.camel@x230> <1394726363.25122.16.camel@x230> <20140313212450.67f1de8e@alan.etchedpixels.co.uk> <1394746248.27846.3.camel@x230> <20140313232140.03bdaac3@alan.etchedpixels.co.uk> <1394762250.6416.24.camel@x230.lan> <20140314122231.17b9ca8a@alan.etchedpixels.co.uk> <1394801518.6416.38.camel@x230.lan> <20140314170655.0ce398a3@alan.etchedpixels.co.uk> <1394820664.26846.18.camel@x230.mview.int.nebula.com> <20140314214806.54a3d031@alan.etchedpixels.co.uk> <1394834193.1286.11.camel@x230> <20140314220840.29a12171@alan.etchedpixels.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20140314220840.29a12171-mUKnrFFms3BCCTY1wZZT65JpZx93mCW/@public.gmane.org> Content-Language: en-US Content-ID: <4F2DB0170EF3AA4C810108E9EE2D1B2C-HX+pjaQZbrqcE4WynfumptQqCkab/8FMAL8bYrjMMd8@public.gmane.org> Sender: linux-efi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: "gnomes-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org" Cc: "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "jmorris-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org" , "keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org" , "linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org" , "hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org" , "jwboyer-rxtnV0ftBwyoClj4AeEUq9i2O/JbrIOy@public.gmane.org" , "linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org" List-Id: linux-efi@vger.kernel.org T24gRnJpLCAyMDE0LTAzLTE0IGF0IDIyOjA4ICswMDAwLCBPbmUgVGhvdXNhbmQgR25vbWVzIHdy b3RlOg0KPiBPbiBGcmksIDE0IE1hciAyMDE0IDIxOjU2OjMzICswMDAwDQo+IE1hdHRoZXcgR2Fy cmV0dCA8bWF0dGhldy5nYXJyZXR0QG5lYnVsYS5jb20+IHdyb3RlOg0KPiA+IFNpZ25lZCB1c2Vy c3BhY2UgaXMgbm90IGEgcmVxdWlyZW1lbnQsIGFuZCB0aGVyZWZvcmUgYW55IHNvbHV0aW9uIHRo YXQNCj4gPiByZWxpZXMgb24gYSBzaWduZWQgaW5pdHJkIGlzIGluYWRlcXVhdGUuIFRoZXJlIGFy ZSB1c2UgY2FzZXMgdGhhdA0KPiA+IHJlcXVpcmUgdmVyaWZpY2F0aW9uIG9mIHRoZSBpbml0cmQg YW5kIG90aGVyIGxldmVscy4gVGhpcyBpc24ndCBvbmUgb2YNCj4gPiB0aGVtLg0KPiANCj4gVGhl IGpvYiBvZiB0aGUga2VybmVsIGlzIHRvIHNvbHZlIHRoZSBnZW5lcmFsIHByb2JsZW0uIFRoZXJl IGFyZSBsb3RzIG9mDQo+IHBlb3BsZSB3aG8gaGFwcGVuIHRvIGNhcmUgYWJvdXQgdmVyaWZpY2F0 aW9uIGJleW9uZCB0aGUga2VybmVsIHNvIGl0DQo+IHNob3VsZG4ndCBiZSBpZ25vcmVkLiBBbmQg dGhleSBjYW4gZG8gZG8gdGhpbmdzIGxpa2UgbG9hZCB0cnVzdGVkIFNFTGludXgNCj4gcnVsZXNl dHMgZXZlbiBpZiB5b3UgY2FuJ3Qgc3VwcG9ydCBpdCBpbiB5b3VyIGVudmlyb25tZW50Lg0KDQpU aGUgZ2VuZXJhbCBwcm9ibGVtIGluY2x1ZGVzIGhhdmluZyB0byBzdXBwb3J0IHRoaXMgZXZlbiB3 aXRob3V0IGFuDQpzZWxpbnV4IHBvbGljeS4NCg0KPiA+ID4gRXZlbiBpbiBFRkkgeW91IGNhbiBt YWtlIHlvdXIga2VybmVsIG9yIGxvYWRlciBjaGVjayB0aGUgaW5pdHJkIHNpZ25hdHVyZQ0KPiA+ ID4gYW5kIHRoZSByb290ZnMgc2lnbmF0dXJlIGlmIHlvdSB3YW50Lg0KPiA+IA0KPiA+IEV4Y2Vw dCB0aGUgaW5pdHJhbWZzIGdldHMgYnVpbHQgYXQga2VybmVsIGluc3RhbGwgdGltZS4NCj4gDQo+ IEltcGxlbWVudGF0aW9uIGRldGFpbCBmb3IgeW91ciB1c2UgY2FzZS4NCg0KQW5kIG9uZSB0aGF0 J3Mgbm90IGdvaW5nIHRvIGNoYW5nZSwgc28gdGhlIGdlbmVyYWwgcHJvYmxlbSBpbmNsdWRlcyBu b3QNCnJlbHlpbmcgb24gYSBzaWduZWQgaW5pdHJhbWZzLg0KDQo+ID4gPiBDb3JyZWN0IG1lIGlm IEkgYW0gd3JvbmcgYnV0IHlvdXIgc3RhcnRpbmcgcG9pbnQgaXMgIkkgaGF2ZSBhIGNoYWluIG9m DQo+ID4gPiBtZWFzdXJlbWVudCBhcyBmYXIgYXMgdGhlIGtlcm5lbCBJIGxvYWQiLiBXaXRob3V0 IHRoYXQgSSBjYW4ganVzdCBnbyBpbnRvDQo+ID4gPiBncnViIGFuZCAwd24geW91Lg0KPiA+IA0K PiA+IEluIG15IHVzZSBjYXNlLiBCdXQgbm90IGFsbCBpbXBsZW1lbnRhdGlvbnMgd2lsbCBiZSBt ZWFzdXJpbmcgdGhpbmdzIC0NCj4gPiB0aGV5IGNhbiBhc3NlcnQgdGhhdCB0aGUga2VybmVsIGlz IHRydXN0d29ydGh5IHRocm91Z2ggc29tZSBvdGhlcg0KPiA+IG1lY2hhbmlzbS4gVGhpcyBnZW51 aW5lbHkgaXMgYWJvdXQgdHJ1c3QsIG5vdCBtZWFzdXJlbWVudC4NCj4gDQo+IFRoZSBhc3NlcnRp b24geW91IGF0dGVtcHQgdG8gYWNoaWV2ZSBpcyBJIGJlbGlldmUNCj4gDQo+ICJObyByaW5nIDAg Y29kZSBpcyBleGVjdXRlZCBkaXJlY3RseSBvciBpbmRpcmVjdGx5IHRoYXQgaXMgbm90IG1lYXN1 cmVkIg0KDQpOby4gQXMgSSBrZWVwIHBvaW50aW5nIG91dCwgbm90IGFsbCBjb2RlIGlzIG1lYXN1 cmVkLiBUaGUgZmlybXdhcmUgaXMNCm5vdCByZXF1aXJlZCB0byBtZWFzdXJlIGl0c2VsZi4gQSBw YXJ0aWN1bGFyIGltcGxlbWVudGF0aW9uIG1heSBza2lwDQptZWFzdXJpbmcgdGhlIGtlcm5lbCBi ZWNhdXNlIGl0IGNhbiBhdHRlc3QgdG8gaXRzIHRydXN0d29ydGh5bmVzcyBpbg0Kc29tZSBvdGhl ciB3YXkuIENocm9tZU9TIHdpbGwgbG9hZCB1bm1lYXN1cmVkIGtlcm5lbCBtb2R1bGVzIHByb3Zp ZGVkIGl0DQpjYW4gYXR0ZXN0IHRvIHRoZSB0cnVzdHdvcnRoeW5lc3Mgb2YgdGhlIGZpbGVzeXN0 ZW0gY29udGFpbmluZyB0aGVtLg0KDQotLSANCk1hdHRoZXcgR2FycmV0dCA8bWF0dGhldy5nYXJy ZXR0QG5lYnVsYS5jb20+DQo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756096AbaCNWPu (ORCPT ); Fri, 14 Mar 2014 18:15:50 -0400 Received: from mail-by2lp0244.outbound.protection.outlook.com ([207.46.163.244]:24519 "EHLO na01-by2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753952AbaCNWPs (ORCPT ); Fri, 14 Mar 2014 18:15:48 -0400 From: Matthew Garrett To: "gnomes@lxorguk.ukuu.org.uk" CC: "linux-kernel@vger.kernel.org" , "jmorris@namei.org" , "keescook@chromium.org" , "linux-security-module@vger.kernel.org" , "akpm@linux-foundation.org" , "hpa@zytor.com" , "jwboyer@fedoraproject.org" , "linux-efi@vger.kernel.org" , "gregkh@linuxfoundation.org" Subject: Re: Trusted kernel patchset for Secure Boot lockdown Thread-Topic: Trusted kernel patchset for Secure Boot lockdown Thread-Index: AQHPP9H0gdFEpLbAD0ahQ2OJgthmsZrhJj+A Date: Fri, 14 Mar 2014 22:15:45 +0000 Message-ID: <1394835345.1286.22.camel@x230> References: <1393445473-15068-1-git-send-email-matthew.garrett@nebula.com> <1394686919.25122.2.camel@x230> <1394726363.25122.16.camel@x230> <20140313212450.67f1de8e@alan.etchedpixels.co.uk> <1394746248.27846.3.camel@x230> <20140313232140.03bdaac3@alan.etchedpixels.co.uk> <1394762250.6416.24.camel@x230.lan> <20140314122231.17b9ca8a@alan.etchedpixels.co.uk> <1394801518.6416.38.camel@x230.lan> <20140314170655.0ce398a3@alan.etchedpixels.co.uk> <1394820664.26846.18.camel@x230.mview.int.nebula.com> <20140314214806.54a3d031@alan.etchedpixels.co.uk> <1394834193.1286.11.camel@x230> <20140314220840.29a12171@alan.etchedpixels.co.uk> In-Reply-To: <20140314220840.29a12171@alan.etchedpixels.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:470:1f07:1371:6267:20ff:fec3:2318] x-forefront-prvs: 0150F3F97D x-forefront-antispam-report: SFV:NSPM;SFS:(10009001)(6009001)(428001)(377424004)(24454002)(51704005)(199002)(189002)(94316002)(47976001)(47736001)(33646001)(49866001)(81542001)(77096001)(33716001)(74706001)(74366001)(93516002)(74876001)(86362001)(94946001)(54316002)(20776003)(81342001)(59766001)(63696002)(54356001)(53806001)(46102001)(51856001)(79102001)(76482001)(56776001)(69226001)(85852003)(95416001)(76796001)(90146001)(65816001)(47446002)(56816005)(97186001)(87266001)(74502001)(74662001)(31966008)(2656002)(85306002)(87936001)(76786001)(80022001)(50986001)(81686001)(83072002)(92726001)(83322001)(95666003)(19580405001)(19580395003)(81816001)(92566001)(80976001)(3826001);DIR:OUT;SFP:1101;SCL:1;SRVR:BN1PR05MB122;H:BN1PR05MB423.namprd05.prod.outlook.com;FPR:FE87F3C6.A73A57C1.C3F0DD6B.86F7F961.202EF;MLV:sfv;PTR:InfoNoRecords;A:1;MX:1;LANG:en; Content-Type: text/plain; charset="utf-8" Content-ID: <4F2DB0170EF3AA4C810108E9EE2D1B2C@namprd05.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: nebula.com 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 mail.home.local id s2EMFttv019963 On Fri, 2014-03-14 at 22:08 +0000, One Thousand Gnomes wrote: > On Fri, 14 Mar 2014 21:56:33 +0000 > Matthew Garrett wrote: > > Signed userspace is not a requirement, and therefore any solution that > > relies on a signed initrd is inadequate. There are use cases that > > require verification of the initrd and other levels. This isn't one of > > them. > > The job of the kernel is to solve the general problem. There are lots of > people who happen to care about verification beyond the kernel so it > shouldn't be ignored. And they can do do things like load trusted SELinux > rulesets even if you can't support it in your environment. The general problem includes having to support this even without an selinux policy. > > > Even in EFI you can make your kernel or loader check the initrd signature > > > and the rootfs signature if you want. > > > > Except the initramfs gets built at kernel install time. > > Implementation detail for your use case. And one that's not going to change, so the general problem includes not relying on a signed initramfs. > > > Correct me if I am wrong but your starting point is "I have a chain of > > > measurement as far as the kernel I load". Without that I can just go into > > > grub and 0wn you. > > > > In my use case. But not all implementations will be measuring things - > > they can assert that the kernel is trustworthy through some other > > mechanism. This genuinely is about trust, not measurement. > > The assertion you attempt to achieve is I believe > > "No ring 0 code is executed directly or indirectly that is not measured" No. As I keep pointing out, not all code is measured. The firmware is not required to measure itself. A particular implementation may skip measuring the kernel because it can attest to its trustworthyness in some other way. ChromeOS will load unmeasured kernel modules provided it can attest to the trustworthyness of the filesystem containing them. -- Matthew Garrett {.n++%ݶw{.n+{G{ayʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I