From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Bottomley Subject: Re: [PATCH] x86/efi: Map EFI memmap entries in-order at runtime Date: Wed, 16 Sep 2015 13:37:18 +0000 Message-ID: <1442410638.2234.8.camel@Odin.com> References: <1441372447-23439-1-git-send-email-matt@codeblueprint.co.uk> <20150907040752.GW13182@linux-rxt1.site> <20150908204147.GC2854@codeblueprint.co.uk> <20150909003307.GJ2266@linux-rxt1.site> <20150909112123.GB4973@codeblueprint.co.uk> <20150916100820.GA7077@nazgul.tnic> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: Content-Language: en-US Content-ID: Sender: stable-owner@vger.kernel.org To: "ard.biesheuvel@linaro.org" Cc: "matt@codeblueprint.co.uk" , "linux-kernel@vger.kernel.org" , "pjones@redhat.com" , "jlee@suse.com" , "bp@suse.de" , "dyoung@redhat.com" , "stable@vger.kernel.org" , "x86@kernel.org" , "hpa@zytor.com" , "linux-efi@vger.kernel.org" , "leif.lindholm@linaro.org" , "matt.fleming@intel.com" , "LeifLindholm@linux-rxt1.site" , "mjg59@srcf.ucam.org" List-Id: linux-efi@vger.kernel.org T24gV2VkLCAyMDE1LTA5LTE2IGF0IDEzOjI1ICswMjAwLCBBcmQgQmllc2hldXZlbCB3cm90ZToN Cj4gT24gMTYgU2VwdGVtYmVyIDIwMTUgYXQgMTI6MDgsIEJvcmlzbGF2IFBldGtvdiA8YnBAc3Vz ZS5kZT4gd3JvdGU6DQo+ID4gT24gV2VkLCBTZXAgMDksIDIwMTUgYXQgMTI6MjE6MjNQTSArMDEw MCwgTWF0dCBGbGVtaW5nIHdyb3RlOg0KPiA+PiBPbiBXZWQsIDA5IFNlcCwgYXQgMDg6MzM6MDdB TSwgam9leWxpIHdyb3RlOg0KPiA+PiA+DQo+ID4+ID4gWWVzLCB0aGUgbWFjaGluZSBvbiBteSBo YW5kIGhhcyBFRklfUFJPUEVSVElFU19UQUJMRSBlbmFibGVkLCBhbmQgaXQgZG9lc24ndA0KPiA+ PiA+IGJvb3Qgd2l0aG91dCB5b3VyIHBhdGNoLg0KPiA+Pg0KPiA+PiBBd2Vzb21lLiBDb3VsZCB5 b3UgdGVzdCB0aGUgZm9sbG93aW5nIHBhdGNoIGluc3RlYWQ/DQo+ID4+DQo+ID4+IC0tLQ0KPiA+ Pg0KPiA+PiBGcm9tIDI0ZDMyNGI3ODFhM2I2ODhkY2MyNjU5OTU5NDlhOWNmNGU4YWY2ODcgTW9u IFNlcCAxNyAwMDowMDowMCAyMDAxDQo+ID4+IEZyb206IE1hdHQgRmxlbWluZyA8bWF0dC5mbGVt aW5nQGludGVsLmNvbT4NCj4gPj4gRGF0ZTogVGh1LCAzIFNlcCAyMDE1IDE1OjU2OjI1ICswMTAw DQo+ID4+IFN1YmplY3Q6IFtQQVRDSCB2Ml0geDg2L2VmaTogTWFwIEVGSSBtZW1tYXAgZW50cmll cyBpbi1vcmRlciBhdCBydW50aW1lDQo+ID4+DQo+ID4+IEJlZ2lubmluZyB3aXRoIFVFRkkgdjIu NSBFRklfUFJPUEVSVElFU19UQUJMRSB3YXMgaW50cm9kdWNlZCB0aGF0DQo+ID4+IHNpZ25hbHMg dGhhdCB0aGUgZmlybXdhcmUgUEUvQ09GRiBsb2FkZXIgc3VwcG9ydHMgc3BsaXR0aW5nIGNvZGUg YW5kDQo+ID4+IGRhdGEgc2VjdGlvbnMgb2YgUEUvQ09GRiBpbWFnZXMgaW50byBzZXBhcmF0ZSBF RkkgbWVtb3J5IG1hcCBlbnRyaWVzLg0KPiA+PiBUaGlzIGFsbG93cyB0aGUga2VybmVsIHRvIG1h cCB0aG9zZSByZWdpb25zIHdpdGggc3RyaWN0IG1lbW9yeQ0KPiA+PiBwcm90ZWN0aW9ucywgZS5n LiBFRklfTUVNT1JZX1JPIGZvciBjb2RlLCBFRklfTUVNT1JZX1hQIGZvciBkYXRhLCBldGMuDQo+ ID4+DQo+ID4+IFVuZm9ydHVuYXRlbHksIGFuIHVud3JpdHRlbiByZXF1aXJlbWVudCBvZiB0aGlz IG5ldyBmZWF0dXJlIGlzIHRoYXQNCj4gPj4gdGhlIHJlZ2lvbnMgbmVlZCB0byBiZSBtYXBwZWQg d2l0aCB0aGUgc2FtZSBvZmZzZXRzIHJlbGF0aXZlIHRvIGVhY2gNCj4gPj4gb3RoZXIgYXMgb2Jz ZXJ2ZWQgaW4gdGhlIEVGSSBtZW1vcnkgbWFwLiBJZiB0aGlzIGlzIG5vdCBkb25lIGNyYXNoZXMN Cj4gPg0KPiA+IExldCBtZSBnZXQgdGhpcyBzdHJhaWdodDogdGhpcyBsb29rcyBsaWtlIHRoZSBu ZXh0IEVGSSBzY3Jld3VwIHdoaWNoDQo+ID4gcHJhY3RpY2FsbHkgcmVxdWlyZXMgc3BlY2lmaWMg bWFwcGluZyBwbGFjZW1lbnQgaW4gVkEgc3BhY2UganVzdA0KPiA+IGJlY2F1c2UgaXQgdXNlcyBy ZWxhdGl2ZSBhZGRyZXNzZXM/DQo+IA0KPiBCb3RoIHJlbGF0aXZlIGFuZCBhYnNvbHV0ZSByZWZl cmVuY2VzLCBjdXJyZW50bHkuIFRoZSBsYXR0ZXIgYXJlIGFsc28NCj4gYWZmZWN0ZWQgc2luY2Ug dGhlIHJlbG9jYXRpb24gb2Zmc2V0IHRoYXQgaXMgYXBwbGllZCB0byBhbGwgUEUvQ09GRg0KPiBy ZWxvY2F0aW9uIGVudHJpZXMgaXMgYmFzZWQgb24gdGhlIGRpc3BsYWNlbWVudCBvZiBJbWFnZUJh c2UsIGFuZA0KPiBhYnNvbHV0ZSByZWZlcmVuY2VzIHRvIHN5bWJvbHMgaW4gLmRhdGEgbmVlZCB0 byBiZSB0cmVhdGVkIHNwZWNpYWxseQ0KPiAoc2luY2UgaXQgbWF5IGJlIHNoaWZ0ZWQgcmVsYXRp dmUgdG8gdGhlIC50ZXh0IHNlY3Rpb24gY29udGFpbmluZw0KPiBJbWFnZUJhc2UpLiBUaGlzIGNv dWxkIGJlIHdvcmtlZCBhcm91bmQgYnkgY29udmVydGluZyBlYWNoIGFic29sdXRlDQo+IHJlZmVy ZW5jZSBpbmRpdmlkdWFsbHkgdXNpbmcgQ29udmVydFBvaW50ZXIgKCkgW2FuZCBJIGhhdmUgYSBw cm9vZiBvZg0KPiBjb25jZXB0IHRoYXQgYWN0dWFsbHkgbWFrZXMgdGhlIHByb2JsZW0gZ28gYXdh eSBvbiB4ODZdIGJ1dCBpdCB3b3VsZA0KPiBzdGlsbCBiZSBvbmx5IGEgcGFydGlhbCBzb2x1dGlv biwgc2luY2UgcmVsYXRpdmUgcmVmZXJlbmNlcyBhcmUgbm90DQo+IHRyYWNrZWQgaW4gdGhlIFBF L0NPRkYgbWV0YWRhdGEsIHNvIGV2ZW4gaWYgd2Ugd2FudGVkIHRvLCBpdCB3b3VsZCBiZQ0KPiBp bnRyYWN0aWJsZSB0byBmaW5kIGVhY2ggY3Jvc3Mtc2VjdGlvbiByZWxhdGl2ZSByZWZlcmVuY2Ug YW5kIGRvIHRoZQ0KPiBmaXh1cC4NCj4gDQo+ID4gQW5kIHNpbmNlIHlvdSBzYXkgInVud3JpdHRl biIgdGhpcw0KPiA+IHByYWN0aWNhbGx5IGEgcmVxdWlyZW1lbnQgaXMgbm90IGV2ZW4gaW4gdGhl IHNwZWM/DQo+ID4NCj4gDQo+IE5vLCBpdCBzZWVtcyBub2JvZHkgdGhvdWdodCBvZiB0aGlzIHdo ZW4gZGVzaWduaW5nIHRoZSBmZWF0dXJlLg0KDQpUbyBhZGQgY29sb3VyOiBvdXIgcHJvYmxlbSBp cyBzZWN0aW9uIHJlbGF0aXZlIHJlZmVyZW5jZXMgKGVpdGhlciBsb2Fkcw0Kb3IganVtcHMpLiAg VGhlIFBFL0NPRkYgbGlua2VyIGlzIGFsbG93ZWQgbm90IHRvIGVtaXQgcmVsb2NhdGlvbnMgZm9y DQpzZWN0aW9uIHJlbGF0aXZlIHJlZmVyZW5jZXMgYmVjYXVzZSBpdCBleHBlY3RzIHRoYXQgdGhl IHNlY3Rpb25zIHdpbGwNCmFsd2F5cyBiZSBsb2FkZWQgYXQgdGhlIHNhbWUgcmVsYXRpdmUgb2Zm c2V0LiAgSXQgbG9va3MgbGlrZSBpdCBpcw0KcG9zc2libGUgdG8gZm9yY2UgdGhlbSB0byBoYXZl IHJlbG9jYXRpb24gZW50cmllcywgc28gaXQgd291bGQgYmUNCnBvc3NpYmxlIHRvIGFkZCB0byB0 aGUgc3RhbmRhcmQgbGFuZ3VhZ2UgcmVxdWlyaW5nIHRoaXMgZm9yIFVFRkkNCmNvbXBhdGlibGUg YmluYXJpZXMsIGJ1dCB0aGF0IHdvbid0IGhlbHAgd2l0aCBhbnkgb2YgdGhlIGV4aXN0aW5nDQpQ RS9DT0ZGIHN0dWZmIGluIHRoZSBmaWVsZC4NCg0KVGhlIHByb2JsZW0gaXMgdGhhdCB0byBhcHBs eSB0aGUgdmFyaW91cyBwcm90ZWN0aW9ucyBVRUZJIGlzDQppbnRyb2R1Y2luZywgd2UncmUgdHJ5 aW5nIHRvIHJlbG9jYXRlIHRoZSBzZWN0aW9ucyBhbmQgdGhhdCdzIHdoYXQncw0KY2F1c2luZyB0 aGUgaXNzdWUuICBCZWZvcmUgdGhpcywgbm8tb25lIHJlYWxseSB0aG91Z2h0IG9mIG1hcHBpbmcg dGhlDQpzZWN0aW9ucyBhdCBkaWZmZXJlbnQgcmVsYXRpdmUgYWRkcmVzc2VzLiAgSXQncyByZWFs bHkgYW4gdW5leHBlY3RlZA0Kd2Vha25lc3MgaW4gdGhlIFBFL0NPRkYgc3BlYyB0aGF0IHdlIGNh bid0IGZpeCwgc28gd2UgaGF2ZSB0byB3b3JrDQphcm91bmQgaXQuDQoNCkphbWVzDQoNCj4gPiBD YW4gd2Ugc3RhdGUgZXhwbGljaXRseSBpbiB0aGUgc3BlYyBOT1QgdG8gcmVseSBvbiBtYXBwaW5n IFZBIHBsYWNlbWVudD8NCj4gPiBJIG1lYW4sIHRoaXMgInVud3JpdHRlbiIgcmVxdWlyZW1lbnQg aXMgc2VyaW91c2x5IHNjcmV3ZWQgb24gc29vIG1hbnkNCj4gPiBsZXZlbHMuLi4NCj4gPg0KPiAN Cj4gU2V2ZXJhbCBzb2x1dGlvbnMgYW5kL29yIHdvcmsgYXJvdW5kcyBhcmUgY3VycmVudGx5IHVu ZGVyIGRpc2N1c3Npb24NCj4gDQoNCg0K From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753566AbbIPNhf (ORCPT ); Wed, 16 Sep 2015 09:37:35 -0400 Received: from mx2.parallels.com ([199.115.105.18]:43826 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753478AbbIPNhd (ORCPT ); Wed, 16 Sep 2015 09:37:33 -0400 From: James Bottomley To: "ard.biesheuvel@linaro.org" CC: "matt@codeblueprint.co.uk" , "linux-kernel@vger.kernel.org" , "pjones@redhat.com" , "jlee@suse.com" , "bp@suse.de" , "dyoung@redhat.com" , "stable@vger.kernel.org" , "x86@kernel.org" , "hpa@zytor.com" , "linux-efi@vger.kernel.org" , "leif.lindholm@linaro.org" , "matt.fleming@intel.com" , "LeifLindholm@linux-rxt1.site" , "mjg59@srcf.ucam.org" Subject: Re: [PATCH] x86/efi: Map EFI memmap entries in-order at runtime Thread-Topic: [PATCH] x86/efi: Map EFI memmap entries in-order at runtime Thread-Index: AQHQ5xOajVFt4W0HjkyXYwtmZDqlwp4w7LkAgAKoB4CAAECjgIAAtR+AgArr6QCAABVzAIAAJO8A Date: Wed, 16 Sep 2015 13:37:18 +0000 Message-ID: <1442410638.2234.8.camel@Odin.com> References: <1441372447-23439-1-git-send-email-matt@codeblueprint.co.uk> <20150907040752.GW13182@linux-rxt1.site> <20150908204147.GC2854@codeblueprint.co.uk> <20150909003307.GJ2266@linux-rxt1.site> <20150909112123.GB4973@codeblueprint.co.uk> <20150916100820.GA7077@nazgul.tnic> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.12.11 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [184.11.141.41] Content-Type: text/plain; charset="utf-8" Content-ID: MIME-Version: 1.0 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 t8GDbfMs002159 On Wed, 2015-09-16 at 13:25 +0200, Ard Biesheuvel wrote: > On 16 September 2015 at 12:08, Borislav Petkov wrote: > > On Wed, Sep 09, 2015 at 12:21:23PM +0100, Matt Fleming wrote: > >> On Wed, 09 Sep, at 08:33:07AM, joeyli wrote: > >> > > >> > Yes, the machine on my hand has EFI_PROPERTIES_TABLE enabled, and it doesn't > >> > boot without your patch. > >> > >> Awesome. Could you test the following patch instead? > >> > >> --- > >> > >> From 24d324b781a3b688dcc265995949a9cf4e8af687 Mon Sep 17 00:00:00 2001 > >> From: Matt Fleming > >> Date: Thu, 3 Sep 2015 15:56:25 +0100 > >> Subject: [PATCH v2] x86/efi: Map EFI memmap entries in-order at runtime > >> > >> Beginning with UEFI v2.5 EFI_PROPERTIES_TABLE was introduced that > >> signals that the firmware PE/COFF loader supports splitting code and > >> data sections of PE/COFF images into separate EFI memory map entries. > >> This allows the kernel to map those regions with strict memory > >> protections, e.g. EFI_MEMORY_RO for code, EFI_MEMORY_XP for data, etc. > >> > >> Unfortunately, an unwritten requirement of this new feature is that > >> the regions need to be mapped with the same offsets relative to each > >> other as observed in the EFI memory map. If this is not done crashes > > > > Let me get this straight: this looks like the next EFI screwup which > > practically requires specific mapping placement in VA space just > > because it uses relative addresses? > > Both relative and absolute references, currently. The latter are also > affected since the relocation offset that is applied to all PE/COFF > relocation entries is based on the displacement of ImageBase, and > absolute references to symbols in .data need to be treated specially > (since it may be shifted relative to the .text section containing > ImageBase). This could be worked around by converting each absolute > reference individually using ConvertPointer () [and I have a proof of > concept that actually makes the problem go away on x86] but it would > still be only a partial solution, since relative references are not > tracked in the PE/COFF metadata, so even if we wanted to, it would be > intractible to find each cross-section relative reference and do the > fixup. > > > And since you say "unwritten" this > > practically a requirement is not even in the spec? > > > > No, it seems nobody thought of this when designing the feature. To add colour: our problem is section relative references (either loads or jumps). The PE/COFF linker is allowed not to emit relocations for section relative references because it expects that the sections will always be loaded at the same relative offset. It looks like it is possible to force them to have relocation entries, so it would be possible to add to the standard language requiring this for UEFI compatible binaries, but that won't help with any of the existing PE/COFF stuff in the field. The problem is that to apply the various protections UEFI is introducing, we're trying to relocate the sections and that's what's causing the issue. Before this, no-one really thought of mapping the sections at different relative addresses. It's really an unexpected weakness in the PE/COFF spec that we can't fix, so we have to work around it. James > > Can we state explicitly in the spec NOT to rely on mapping VA placement? > > I mean, this "unwritten" requirement is seriously screwed on soo many > > levels... > > > > Several solutions and/or work arounds are currently under discussion > {.n++%ݶw{.n+{G{ayʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I