From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1fcxft-00089o-MU for kexec@lists.infradead.org; Tue, 10 Jul 2018 18:47:47 +0000 Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6AIi6FV117621 for ; Tue, 10 Jul 2018 14:47:32 -0400 Received: from e06smtp04.uk.ibm.com (e06smtp04.uk.ibm.com [195.75.94.100]) by mx0a-001b2d01.pphosted.com with ESMTP id 2k4xnepde6-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 10 Jul 2018 14:47:31 -0400 Received: from localhost by e06smtp04.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 10 Jul 2018 19:47:29 +0100 Subject: Re: [PATCH v5 7/8] ima: based on policy warn about loading firmware (pre-allocated buffer) From: Mimi Zohar Date: Tue, 10 Jul 2018 14:47:21 -0400 In-Reply-To: References: <1530542283-26145-1-git-send-email-zohar@linux.vnet.ibm.com> <1530542283-26145-8-git-send-email-zohar@linux.vnet.ibm.com> <1531165294.3332.40.camel@linux.ibm.com> Mime-Version: 1.0 Message-Id: <1531248441.3332.142.camel@linux.ibm.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Ard Biesheuvel Cc: Kees Cook , Stephen Boyd , Greg Kroah-Hartman , "Luis R . Rodriguez" , Kexec Mailing List , linux-security-module , Linux Kernel Mailing List , David Howells , "Luis R . Rodriguez" , Bjorn Andersson , Eric Biederman , linux-integrity , "Serge E . Hallyn" , Mimi Zohar , Andres Rodriguez T24gVHVlLCAyMDE4LTA3LTEwIGF0IDA4OjU2ICswMjAwLCBBcmQgQmllc2hldXZlbCB3cm90ZToK PiBPbiAxMCBKdWx5IDIwMTggYXQgMDg6NTEsIEFyZCBCaWVzaGV1dmVsIDxhcmQuYmllc2hldXZl bEBsaW5hcm8ub3JnPiB3cm90ZToKPiA+IE9uIDkgSnVseSAyMDE4IGF0IDIxOjQxLCBNaW1pIFpv aGFyIDx6b2hhckBsaW51eC5pYm0uY29tPiB3cm90ZToKPiA+PiBPbiBNb24sIDIwMTgtMDctMDIg YXQgMTc6MzAgKzAyMDAsIEFyZCBCaWVzaGV1dmVsIHdyb3RlOgo+ID4+PiBPbiAyIEp1bHkgMjAx OCBhdCAxNjozOCwgTWltaSBab2hhciA8em9oYXJAbGludXgudm5ldC5pYm0uY29tPiB3cm90ZToK PiA+Pj4gPiBTb21lIHN5c3RlbXMgYXJlIG1lbW9yeSBjb25zdHJhaW5lZCBidXQgdGhleSBuZWVk IHRvIGxvYWQgdmVyeSBsYXJnZQo+ID4+PiA+IGZpcm13YXJlcy4gIFRoZSBmaXJtd2FyZSBzdWJz eXN0ZW0gYWxsb3dzIGRyaXZlcnMgdG8gcmVxdWVzdCB0aGlzCj4gPj4+ID4gZmlybXdhcmUgYmUg bG9hZGVkIGZyb20gdGhlIGZpbGVzeXN0ZW0sIGJ1dCB0aGlzIHJlcXVpcmVzIHRoYXQgdGhlCj4g Pj4+ID4gZW50aXJlIGZpcm13YXJlIGJlIGxvYWRlZCBpbnRvIGtlcm5lbCBtZW1vcnkgZmlyc3Qg YmVmb3JlIGl0J3MgcHJvdmlkZWQKPiA+Pj4gPiB0byB0aGUgZHJpdmVyLiAgVGhpcyBjYW4gbGVh ZCB0byBhIHNpdHVhdGlvbiB3aGVyZSB3ZSBtYXAgdGhlIGZpcm13YXJlCj4gPj4+ID4gdHdpY2Us IG9uY2UgdG8gbG9hZCB0aGUgZmlybXdhcmUgaW50byBrZXJuZWwgbWVtb3J5IGFuZCBvbmNlIHRv IGNvcHkgdGhlCj4gPj4+ID4gZmlybXdhcmUgaW50byB0aGUgZmluYWwgcmVzdGluZyBwbGFjZS4K PiA+Pj4gPgo+ID4+PiA+IFRvIHJlc29sdmUgdGhpcyBwcm9ibGVtLCBjb21taXQgYTA5OGVjZDJm YTdkICgiZmlybXdhcmU6IHN1cHBvcnQgbG9hZGluZwo+ID4+PiA+IGludG8gYSBwcmUtYWxsb2Nh dGVkIGJ1ZmZlciIpIGludHJvZHVjZWQgcmVxdWVzdF9maXJtd2FyZV9pbnRvX2J1ZigpIEFQSQo+ ID4+PiA+IHRoYXQgYWxsb3dzIGRyaXZlcnMgdG8gcmVxdWVzdCBmaXJtd2FyZSBiZSBsb2FkZWQg ZGlyZWN0bHkgaW50byBhCj4gPj4+ID4gcHJlLWFsbG9jYXRlZCBidWZmZXIuIChCYXNlZCBvbiB0 aGUgbWFpbGluZyBsaXN0IGRpc2N1c3Npb25zLCBjYWxsaW5nCj4gPj4+ID4gZG1hX2FsbG9jX2Nv aGVyZW50KCkgaXMgdW5uZWNlc3NhcnkgYW5kIGNvbmZ1c2luZy4pCj4gPj4+ID4KPiA+Pj4gPiAo VmVyeSBicm9rZW4vYnVnZ3kpIGRldmljZXMgdXNpbmcgcHJlLWFsbG9jYXRlZCBtZW1vcnkgcnVu IHRoZSByaXNrIG9mCj4gPj4+ID4gdGhlIGZpcm13YXJlIGJlaW5nIGFjY2Vzc2libGUgdG8gdGhl IGRldmljZSBwcmlvciB0byB0aGUgY29tcGxldGlvbiBvZgo+ID4+PiA+IElNQSdzIHNpZ25hdHVy ZSB2ZXJpZmljYXRpb24uICBGb3IgdGhlIHRpbWUgYmVpbmcsIHRoaXMgcGF0Y2ggZW1pdHMgYQo+ ID4+PiA+IHdhcm5pbmcsIGJ1dCBkb2VzIG5vdCBwcmV2ZW50IHRoZSBsb2FkaW5nIG9mIHRoZSBm aXJtd2FyZS4KPiA+Pj4gPgo+ID4+Pgo+ID4+PiBBcyBJIGF0dGVtcHRlZCB0byBleHBsYWluIGlu IHRoZSBleGNoYW5nZSB3aXRoIEx1aXMsIHRoaXMgaGFzIG5vdGhpbmcKPiA+Pj4gdG8gZG8gd2l0 aCBicm9rZW4gb3IgYnVnZ3kgZGV2aWNlcywgYnV0IGlzIHNpbXBseSB0aGUgcmVhbGl0eSB3ZSBo YXZlCj4gPj4+IHRvIGRlYWwgd2l0aCBvbiBwbGF0Zm9ybXMgdGhhdCBsYWNrIElPTU1Vcy4KPiA+ Pgo+ID4+PiBFdmVuIGlmIHlvdSBsb2FkIGludG8gb25lIGJ1ZmZlciwgY2Fycnkgb3V0IHRoZSBz aWduYXR1cmUgdmVyaWZpY2F0aW9uCj4gPj4+IGFuZCAqb25seSB0aGVuKiBjb3B5IGl0IHRvIGFu b3RoZXIgYnVmZmVyLCBhIGJ1cyBtYXN0ZXIgY291bGQKPiA+Pj4gcG90ZW50aWFsbHkgcmVhZCBp dCBmcm9tIHRoZSBmaXJzdCBidWZmZXIgYXMgd2VsbC4gTWFwcGluZyBmb3IgRE1BCj4gPj4+IGRv ZXMgKm5vdCogbWVhbiAnbWFraW5nIHRoZSBtZW1vcnkgcmVhZGFibGUgYnkgdGhlIGRldmljZScg dW5sZXNzCj4gPj4+IElPTU1VcyBhcmUgYmVpbmcgdXNlZC4gT3RoZXJ3aXNlLCBhIGJ1cyBtYXN0 ZXIgY2FuIHJlYWQgaXQgZnJvbSB0aGUKPiA+Pj4gZmlyc3QgYnVmZmVyLCBvciBldmVuIHBhdGNo IHRoZSBjb2RlIHRoYXQgcGVyZm9ybXMgdGhlIHNlY3VyaXR5IGNoZWNrCj4gPj4+IGluIHRoZSBm aXJzdCBwbGFjZS4gRm9yIHN1Y2ggcGxhdGZvcm1zLCBjb3B5aW5nIHRoZSBkYXRhIGFyb3VuZCB0 bwo+ID4+PiBwcmV2ZW50IHRoZSBkZXZpY2UgZnJvbSByZWFkaW5nIGl0IGlzIHNpbXBseSBwb2lu dGxlc3MsIGFzIHdlbGwgYXMgYW55Cj4gPj4+IG90aGVyIG1pdGlnYXRpb24gaW4gc29mdHdhcmUg dG8gcHJvdGVjdCB5b3Vyc2VsZiBmcm9tIG1pc2JlaGF2aW5nIGJ1cwo+ID4+PiBtYXN0ZXJzLgo+ ID4+Cj4gPj4gVGhhbmsgeW91IGZvciB0YWtpbmcgdGhlIHRpbWUgdG8gZXhwbGFpbiB0aGlzIGFn YWluLgo+ID4+Cj4gPj4+IFNvIGlzc3VpbmcgYSB3YXJuaW5nIGluIHRoaXMgcGFydGljdWxhciBj YXNlIGlzIHJhdGhlciBhcmJpdHJhcnkuIE9uCj4gPj4+IHRoZXNlIHBsYXRmb3JtcywgYWxsIGJ1 cyBtYXN0ZXJzIGNhbiByZWFkIChhbmQgbW9kaWZ5KSBhbGwgb2YgeW91cgo+ID4+PiBtZW1vcnkg YWxsIG9mIHRoZSB0aW1lLCBhbmQgYXMgbG9uZyBhcyB0aGUgZmlybXdhcmUgbG9hZGVyIGNvZGUg dGFrZXMKPiA+Pj4gY2FyZSBub3QgdG8gcHJvdmlkZSB0aGUgRE1BIGFkZHJlc3MgdG8gdGhlIGRl dmljZSB1bnRpbCBhZnRlciB0aGUKPiA+Pj4gdmVyaWZpY2F0aW9uIGlzIGNvbXBsZXRlLCBpdCBy ZWFsbHkgaGFzIGRvbmUgYWxsIGl0IHJlYXNvbmFibHkgY2FuIGluCj4gPj4+IHRoZSBlbnZpcm9u bWVudCB0aGF0IGl0IGlzIGV4cGVjdGVkIHRvIG9wZXJhdGUgaW4uCj4gPj4KPiA+PiBTbyBmb3Ig dGhlIG5vbi1JT01NVSBzeXN0ZW0gY2FzZSwgZGlmZmVyZW50aWF0aW5nIGJldHdlZW4gcHJlLQo+ ID4+IGFsbG9jYXRlZCBidWZmZXJzIHZzLiB1c2luZyB0d28gYnVmZmVycyBkb2Vzbid0IG1ha2Ug c2Vuc2UuCj4gPj4KPiA+Pj4KPiA+Pj4gKFRoZSB1c2Ugb2YgZG1hX2FsbG9jX2NvaGVyZW50KCkg aXMgYSBiaXQgb2YgYSByZWQgaGVycmluZyBoZXJlLCBhcyBpdAo+ID4+PiBpbmNvcnBvcmF0ZXMg dGhlIERNQSBtYXAgb3BlcmF0aW9uLiBIb3dldmVyLCBETUEgbWFwIGlzIGEgbm8tb3Agb24KPiA+ Pj4gc3lzdGVtcyB3aXRoIGNhY2hlIGNvaGVyZW50IDE6MSBETUEgW2lvdywgYWxsIFBDcyBhbmQg bW9zdCBhcm02NAo+ID4+PiBwbGF0Zm9ybXMgdW5sZXNzIHRoZXkgaGF2ZSBJT01NVXNdLCBhbmQg c28gdGhlcmUgaXMgbm90IG11Y2gKPiA+Pj4gZGlmZmVyZW5jZSBiZXR3ZWVuIG1lbW9yeSBhbGxv Y2F0ZWQgd2l0aCBrbWFsbG9jKCkgb3Igd2l0aAo+ID4+PiBkbWFfYWxsb2NfY29oZXJlbnQoKSBp biB0ZXJtcyBvZiB3aGV0aGVyIHRoZSBkZXZpY2UgY2FuIGFjY2VzcyBpdAo+ID4+PiBmcmVlbHkp Cj4gPj4KPiA+PiBXaGF0IGFib3V0IHN5c3RlbXMgd2l0aCBhbiBJT01NVT8KPiA+Pgo+ID4KPiA+ IE9uIHN5c3RlbXMgd2l0aCBhbiBJT01NVSwgcGVyZm9ybWluZyB0aGUgRE1BIG1hcCB3aWxsIGNy ZWF0ZSBhbiBlbnRyeQo+ID4gaW4gdGhlIElPTU1VIHBhZ2UgdGFibGVzIGZvciB0aGUgcGh5c2lj YWwgcmVnaW9uIGFzc29jaWF0ZWQgd2l0aCB0aGUKPiA+IGJ1ZmZlciwgbWFraW5nIHRoZSByZWdp b24gYWNjZXNzaWJsZSB0byB0aGUgZGV2aWNlLiBGb3IgcGxhdGZvcm1zIGluCj4gPiB0aGlzIGNh dGVnb3J5LCB1c2luZyBkbWFfYWxsb2NfY29oZXJlbnQoKSBmb3IgYWxsb2NhdGluZyBhIGJ1ZmZl ciB0bwo+ID4gcGFzcyBmaXJtd2FyZSB0byB0aGUgZGV2aWNlIGRvZXMgb3BlbiBhIHdpbmRvdyB3 aGVyZSB0aGUgZGV2aWNlIGNvdWxkCj4gPiB0aGVvcmV0aWNhbGx5IGFjY2VzcyB0aGlzIGRhdGEg d2hpbGUgdGhlIHZhbGlkYXRpb24gaXMgc3RpbGwgaW4KPiA+IHByb2dyZXNzLgo+ID4KPiA+IE5v dGUgdGhhdCB0aGUgZGV2aWNlIHN0aWxsIG5lZWRzIHRvIGJlIGluZm9ybWVkIGFib3V0IHRoZSBh ZGRyZXNzIG9mCj4gPiB0aGUgYnVmZmVyOiBqdXN0IGNhbGxpbmcgZG1hX2FsbG9jX2NvaGVyZW50 KCkgd2lsbCBub3QgYWxsb3cgdGhlCj4gPiBkZXZpY2UgdG8gZmluZCB0aGUgZmlybXdhcmUgaW1h Z2UgaW4gaXRzIG1lbW9yeSBzcGFjZSwgYW5kIGFyYml0cmFyeQo+ID4gRE1BIGFjY2Vzc2VzIHBl cmZvcm1lZCBieSB0aGUgZGV2aWNlIHdpbGwgdHJpZ2dlciBmYXVsdHMgdGhhdCBhcmUKPiA+IHJl cG9ydGVkIHRvIHRoZSBPUy4gU28gdGhlIHdpbmRvdyBiZXR3ZWVuIERNQSBtYXAgKG9yCj4gPiBk bWFfYWxsb2NfY29oZXJlbnQoKSkgYW5kIHRoZSBkZXZpY2Ugc3BlY2lmaWMgY29tbWFuZCB0byBw YXNzIHRoZSBETUEKPiA+IGJ1ZmZlciBhZGRyZXNzIHRvIHRoZSBkZXZpY2UgaXMgbm90IGluaGVy ZW50bHkgdW5zYWZlIElNTywgYnV0IEkgZG8KPiA+IHVuZGVyc3RhbmQgdGhlIG5lZWQgdG8gY292 ZXIgdGhpcyBzY2VuYXJpby4KPiA+Cj4gPiBBcyBJIHBvaW50ZWQgb3V0IGJlZm9yZSwgdXNpbmcg Y29oZXJlbnQgRE1BIGJ1ZmZlcnMgdG8gcGVyZm9ybQo+ID4gc3RyZWFtaW5nIERNQSBpcyBnZW5l cmFsbHkgYSBiYWQgaWRlYSwgc2luY2UgdGhleSBtYXkgYmUgYWxsb2NhdGVkCj4gPiBmcm9tIGEg ZmluaXRlIHBvb2wsIGFuZCBtYXkgdXNlIHVuY2FjaGVkIG1hcHBpbmdzLCBtYWtpbmcgdGhlIGFj Y2Vzcwo+ID4gc2xvd2VyIHRoYW4gbmVjZXNzYXJ5ICh3aGlsZSBzdHJlYW1pbmcgRE1BIGNhbiB1 c2UgYW55IGttYWxsb2MnZWQKPiA+IGJ1ZmZlciBhbmQgd2lsbCBqdXN0IGZsdXNoIHRoZSBjb250 ZW50cyBvZiB0aGUgY2FjaGVzIHRvIG1haW4gbWVtb3J5Cj4gPiB3aGVuIHRoZSBETUEgbWFwIGlz IHBlcmZvcm1lZCkuCj4gPgo+ID4gU28gdG8gc3VtbWFyaXplIGFnYWluOiBpbiBteSBvcGluaW9u LCB1c2luZyBhIHNpbmdsZSBidWZmZXIgaXMgbm90IGEKPiA+IHByb2JsZW0gYXMgbG9uZyBhcyB0 aGUgdmFsaWRhdGlvbiBjb21wbGV0ZXMgYmVmb3JlIHRoZSBETUEgbWFwIGlzCj4gPiBwZXJmb3Jt ZWQuIFRoaXMgd2lsbCBwcm92aWRlIHRoZSBleHBlY3RlZCBndWFyYW50ZWVzIG9uIHN5c3RlbXMg d2l0aAo+ID4gSU9NTVVzLCBhbmQgd2lsbCBub3QgY29tcGxpY2F0ZSBtYXR0ZXJzIG9uIHN5c3Rl bXMgd2hlcmUgdGhlcmUgaXMgbm8KPiA+IHBvaW50IGluIG9ic2Vzc2luZyBhYm91dCB0aGlzIGFu eXdheSBnaXZlbiB0aGF0IGRldmljZXMgY2FuIGFjY2VzcyBhbGwKPiA+IG9mIG1lbW9yeSB3aGVu ZXZlciB0aGV5IHdhbnQgdG8uCgpJdCBzb3VuZCBsaWtlIGFzIGxvbmcgYXMgdGhlIHByZS1hbGxv Y2F0ZWQgYnVmZmVyIGlzIG5vdCBiZWluZyByZS0KdXNlZCwgZWl0aGVyIGJ5IGJlaW5nIG1hcHBl ZCB0byBtdWx0aXBsZSBkZXZpY2VzIG9yIHVzZWQgdG8gbG9hZAptdWx0aXBsZSBmaXJtd2FyZSBi bG9icywgaXQgaXMgc2FmZS4KCj4gPgo+ID4gQXMgZm9yIHRoZSBRdWFsY29tbSBjYXNlOiBkbWFf YWxsb2NfY29oZXJlbnQoKSBpcyBub3QgbmVlZGVkIGhlcmUgYnV0Cj4gPiBzaW1wbHkgZW5kcyB1 cCBiZWluZyB1c2VkIGJlY2F1c2UgaXQgd2FzIGFscmVhZHkgd2lyZWQgdXAgaW4gdGhlCj4gPiBx dWFsY29tbSBzcGVjaWZpYyBzZWN1cmUgd29ybGQgQVBJLCB3aGljaCBhbW91bnRzIHRvIGRvaW5n IHN5c2NhbGxzCj4gPiBpbnRvIGEgaGlnaGVyIHByaXZpbGVnZSBsZXZlbCB0aGFuIHRoZSBvbmUg dGhlIGtlcm5lbCBpdHNlbGYgcnVucyBhdC4KPiA+IFNvIGFnYWluLCByZWFzb25pbmcgYWJvdXQg d2hldGhlciB0aGUgc2VjdXJlIHdvcmxkIHdpbGwgbG9vayBhdCB5b3VyCj4gPiBkYXRhIGJlZm9y ZSB5b3UgY2hlY2tlZCB0aGUgc2lnIGlzIHJhdGhlciBwb2ludGxlc3MsIGFuZCBhZGRpbmcKPiA+ IHNwZWNpYWwgY2FzZXMgdG8gdGhlIElNQSBhcGkgdG8gY2F0ZXIgZm9yIHRoaXMgdXNlIGNhc2Ug c2VlbXMgbGlrZSBhCj4gPiB3YXN0ZSBvZiBlbmdpbmVlcmluZyBhbmQgcmV2aWV3IGVmZm9ydCB0 byBtZS4gSWYgd2UgaGF2ZSB0byBkbwo+ID4gc29tZXRoaW5nIHRvIHRpZSB1cCB0aGlzIGxvb3Nl IGVuZCwgbGV0J3MgdHJ5IHN3aXRjaGluZyBpdCB0byB0aGUKPiA+IHN0cmVhbWluZyBETUEgYXBp IGluc3RlYWQuCj4gPgo+IAo+IEZvcmdvdCB0byBtZW50aW9uOiB0aGUgUXVhbGNvbW0gY2FzZSBp cyBhYm91dCBwYXNzaW5nIGRhdGEgdG8gdGhlIENQVQo+IHJ1bm5pbmcgYXQgYW5vdGhlciBwcml2 aWxlZ2UgbGV2ZWwsIHNvIElPTU1VIHZzICFJT01NVSBpcyBub3QgYSBmYWN0b3IKPiBoZXJlLgoK QWdyZWVkLiDCoEl0IHNvdW5kcyBsaWtlIHRoZSBkZXBlbmRlbmN5IHdvdWxkIGJlIG9uIHdoZXRo ZXIgdGhlIGJ1ZmZlcgpoYXMgYmVlbiBETUEgbWFwcGVkLgoKTWltaQoKCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmtleGVjIG1haWxpbmcgbGlzdAprZXhl Y0BsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4v bGlzdGluZm8va2V4ZWMK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:41652 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732621AbeGJSrt (ORCPT ); Tue, 10 Jul 2018 14:47:49 -0400 Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6AIi4VC085613 for ; Tue, 10 Jul 2018 14:47:32 -0400 Received: from e06smtp04.uk.ibm.com (e06smtp04.uk.ibm.com [195.75.94.100]) by mx0a-001b2d01.pphosted.com with ESMTP id 2k501vf2jn-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 10 Jul 2018 14:47:31 -0400 Received: from localhost by e06smtp04.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 10 Jul 2018 19:47:29 +0100 Subject: Re: [PATCH v5 7/8] ima: based on policy warn about loading firmware (pre-allocated buffer) From: Mimi Zohar To: Ard Biesheuvel Cc: Mimi Zohar , linux-integrity , linux-security-module , Linux Kernel Mailing List , David Howells , "Luis R . Rodriguez" , Eric Biederman , Kexec Mailing List , Andres Rodriguez , Greg Kroah-Hartman , "Luis R . Rodriguez" , Kees Cook , "Serge E . Hallyn" , Stephen Boyd , Bjorn Andersson Date: Tue, 10 Jul 2018 14:47:21 -0400 In-Reply-To: References: <1530542283-26145-1-git-send-email-zohar@linux.vnet.ibm.com> <1530542283-26145-8-git-send-email-zohar@linux.vnet.ibm.com> <1531165294.3332.40.camel@linux.ibm.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Message-Id: <1531248441.3332.142.camel@linux.ibm.com> Sender: linux-integrity-owner@vger.kernel.org List-ID: On Tue, 2018-07-10 at 08:56 +0200, Ard Biesheuvel wrote: > On 10 July 2018 at 08:51, Ard Biesheuvel wrote: > > On 9 July 2018 at 21:41, Mimi Zohar wrote: > >> On Mon, 2018-07-02 at 17:30 +0200, Ard Biesheuvel wrote: > >>> On 2 July 2018 at 16:38, Mimi Zohar wrote: > >>> > Some systems are memory constrained but they need to load very large > >>> > firmwares. The firmware subsystem allows drivers to request this > >>> > firmware be loaded from the filesystem, but this requires that the > >>> > entire firmware be loaded into kernel memory first before it's provided > >>> > to the driver. This can lead to a situation where we map the firmware > >>> > twice, once to load the firmware into kernel memory and once to copy the > >>> > firmware into the final resting place. > >>> > > >>> > To resolve this problem, commit a098ecd2fa7d ("firmware: support loading > >>> > into a pre-allocated buffer") introduced request_firmware_into_buf() API > >>> > that allows drivers to request firmware be loaded directly into a > >>> > pre-allocated buffer. (Based on the mailing list discussions, calling > >>> > dma_alloc_coherent() is unnecessary and confusing.) > >>> > > >>> > (Very broken/buggy) devices using pre-allocated memory run the risk of > >>> > the firmware being accessible to the device prior to the completion of > >>> > IMA's signature verification. For the time being, this patch emits a > >>> > warning, but does not prevent the loading of the firmware. > >>> > > >>> > >>> As I attempted to explain in the exchange with Luis, this has nothing > >>> to do with broken or buggy devices, but is simply the reality we have > >>> to deal with on platforms that lack IOMMUs. > >> > >>> Even if you load into one buffer, carry out the signature verification > >>> and *only then* copy it to another buffer, a bus master could > >>> potentially read it from the first buffer as well. Mapping for DMA > >>> does *not* mean 'making the memory readable by the device' unless > >>> IOMMUs are being used. Otherwise, a bus master can read it from the > >>> first buffer, or even patch the code that performs the security check > >>> in the first place. For such platforms, copying the data around to > >>> prevent the device from reading it is simply pointless, as well as any > >>> other mitigation in software to protect yourself from misbehaving bus > >>> masters. > >> > >> Thank you for taking the time to explain this again. > >> > >>> So issuing a warning in this particular case is rather arbitrary. On > >>> these platforms, all bus masters can read (and modify) all of your > >>> memory all of the time, and as long as the firmware loader code takes > >>> care not to provide the DMA address to the device until after the > >>> verification is complete, it really has done all it reasonably can in > >>> the environment that it is expected to operate in. > >> > >> So for the non-IOMMU system case, differentiating between pre- > >> allocated buffers vs. using two buffers doesn't make sense. > >> > >>> > >>> (The use of dma_alloc_coherent() is a bit of a red herring here, as it > >>> incorporates the DMA map operation. However, DMA map is a no-op on > >>> systems with cache coherent 1:1 DMA [iow, all PCs and most arm64 > >>> platforms unless they have IOMMUs], and so there is not much > >>> difference between memory allocated with kmalloc() or with > >>> dma_alloc_coherent() in terms of whether the device can access it > >>> freely) > >> > >> What about systems with an IOMMU? > >> > > > > On systems with an IOMMU, performing the DMA map will create an entry > > in the IOMMU page tables for the physical region associated with the > > buffer, making the region accessible to the device. For platforms in > > this category, using dma_alloc_coherent() for allocating a buffer to > > pass firmware to the device does open a window where the device could > > theoretically access this data while the validation is still in > > progress. > > > > Note that the device still needs to be informed about the address of > > the buffer: just calling dma_alloc_coherent() will not allow the > > device to find the firmware image in its memory space, and arbitrary > > DMA accesses performed by the device will trigger faults that are > > reported to the OS. So the window between DMA map (or > > dma_alloc_coherent()) and the device specific command to pass the DMA > > buffer address to the device is not inherently unsafe IMO, but I do > > understand the need to cover this scenario. > > > > As I pointed out before, using coherent DMA buffers to perform > > streaming DMA is generally a bad idea, since they may be allocated > > from a finite pool, and may use uncached mappings, making the access > > slower than necessary (while streaming DMA can use any kmalloc'ed > > buffer and will just flush the contents of the caches to main memory > > when the DMA map is performed). > > > > So to summarize again: in my opinion, using a single buffer is not a > > problem as long as the validation completes before the DMA map is > > performed. This will provide the expected guarantees on systems with > > IOMMUs, and will not complicate matters on systems where there is no > > point in obsessing about this anyway given that devices can access all > > of memory whenever they want to. It sound like as long as the pre-allocated buffer is not being re- used, either by being mapped to multiple devices or used to load multiple firmware blobs, it is safe. > > > > As for the Qualcomm case: dma_alloc_coherent() is not needed here but > > simply ends up being used because it was already wired up in the > > qualcomm specific secure world API, which amounts to doing syscalls > > into a higher privilege level than the one the kernel itself runs at. > > So again, reasoning about whether the secure world will look at your > > data before you checked the sig is rather pointless, and adding > > special cases to the IMA api to cater for this use case seems like a > > waste of engineering and review effort to me. If we have to do > > something to tie up this loose end, let's try switching it to the > > streaming DMA api instead. > > > > Forgot to mention: the Qualcomm case is about passing data to the CPU > running at another privilege level, so IOMMU vs !IOMMU is not a factor > here. Agreed. It sounds like the dependency would be on whether the buffer has been DMA mapped. Mimi From mboxrd@z Thu Jan 1 00:00:00 1970 From: zohar@linux.ibm.com (Mimi Zohar) Date: Tue, 10 Jul 2018 14:47:21 -0400 Subject: [PATCH v5 7/8] ima: based on policy warn about loading firmware (pre-allocated buffer) In-Reply-To: References: <1530542283-26145-1-git-send-email-zohar@linux.vnet.ibm.com> <1530542283-26145-8-git-send-email-zohar@linux.vnet.ibm.com> <1531165294.3332.40.camel@linux.ibm.com> Message-ID: <1531248441.3332.142.camel@linux.ibm.com> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Tue, 2018-07-10 at 08:56 +0200, Ard Biesheuvel wrote: > On 10 July 2018 at 08:51, Ard Biesheuvel wrote: > > On 9 July 2018 at 21:41, Mimi Zohar wrote: > >> On Mon, 2018-07-02 at 17:30 +0200, Ard Biesheuvel wrote: > >>> On 2 July 2018 at 16:38, Mimi Zohar wrote: > >>> > Some systems are memory constrained but they need to load very large > >>> > firmwares. The firmware subsystem allows drivers to request this > >>> > firmware be loaded from the filesystem, but this requires that the > >>> > entire firmware be loaded into kernel memory first before it's provided > >>> > to the driver. This can lead to a situation where we map the firmware > >>> > twice, once to load the firmware into kernel memory and once to copy the > >>> > firmware into the final resting place. > >>> > > >>> > To resolve this problem, commit a098ecd2fa7d ("firmware: support loading > >>> > into a pre-allocated buffer") introduced request_firmware_into_buf() API > >>> > that allows drivers to request firmware be loaded directly into a > >>> > pre-allocated buffer. (Based on the mailing list discussions, calling > >>> > dma_alloc_coherent() is unnecessary and confusing.) > >>> > > >>> > (Very broken/buggy) devices using pre-allocated memory run the risk of > >>> > the firmware being accessible to the device prior to the completion of > >>> > IMA's signature verification. For the time being, this patch emits a > >>> > warning, but does not prevent the loading of the firmware. > >>> > > >>> > >>> As I attempted to explain in the exchange with Luis, this has nothing > >>> to do with broken or buggy devices, but is simply the reality we have > >>> to deal with on platforms that lack IOMMUs. > >> > >>> Even if you load into one buffer, carry out the signature verification > >>> and *only then* copy it to another buffer, a bus master could > >>> potentially read it from the first buffer as well. Mapping for DMA > >>> does *not* mean 'making the memory readable by the device' unless > >>> IOMMUs are being used. Otherwise, a bus master can read it from the > >>> first buffer, or even patch the code that performs the security check > >>> in the first place. For such platforms, copying the data around to > >>> prevent the device from reading it is simply pointless, as well as any > >>> other mitigation in software to protect yourself from misbehaving bus > >>> masters. > >> > >> Thank you for taking the time to explain this again. > >> > >>> So issuing a warning in this particular case is rather arbitrary. On > >>> these platforms, all bus masters can read (and modify) all of your > >>> memory all of the time, and as long as the firmware loader code takes > >>> care not to provide the DMA address to the device until after the > >>> verification is complete, it really has done all it reasonably can in > >>> the environment that it is expected to operate in. > >> > >> So for the non-IOMMU system case, differentiating between pre- > >> allocated buffers vs. using two buffers doesn't make sense. > >> > >>> > >>> (The use of dma_alloc_coherent() is a bit of a red herring here, as it > >>> incorporates the DMA map operation. However, DMA map is a no-op on > >>> systems with cache coherent 1:1 DMA [iow, all PCs and most arm64 > >>> platforms unless they have IOMMUs], and so there is not much > >>> difference between memory allocated with kmalloc() or with > >>> dma_alloc_coherent() in terms of whether the device can access it > >>> freely) > >> > >> What about systems with an IOMMU? > >> > > > > On systems with an IOMMU, performing the DMA map will create an entry > > in the IOMMU page tables for the physical region associated with the > > buffer, making the region accessible to the device. For platforms in > > this category, using dma_alloc_coherent() for allocating a buffer to > > pass firmware to the device does open a window where the device could > > theoretically access this data while the validation is still in > > progress. > > > > Note that the device still needs to be informed about the address of > > the buffer: just calling dma_alloc_coherent() will not allow the > > device to find the firmware image in its memory space, and arbitrary > > DMA accesses performed by the device will trigger faults that are > > reported to the OS. So the window between DMA map (or > > dma_alloc_coherent()) and the device specific command to pass the DMA > > buffer address to the device is not inherently unsafe IMO, but I do > > understand the need to cover this scenario. > > > > As I pointed out before, using coherent DMA buffers to perform > > streaming DMA is generally a bad idea, since they may be allocated > > from a finite pool, and may use uncached mappings, making the access > > slower than necessary (while streaming DMA can use any kmalloc'ed > > buffer and will just flush the contents of the caches to main memory > > when the DMA map is performed). > > > > So to summarize again: in my opinion, using a single buffer is not a > > problem as long as the validation completes before the DMA map is > > performed. This will provide the expected guarantees on systems with > > IOMMUs, and will not complicate matters on systems where there is no > > point in obsessing about this anyway given that devices can access all > > of memory whenever they want to. It sound like as long as the pre-allocated buffer is not being re- used, either by being mapped to multiple devices or used to load multiple firmware blobs, it is safe. > > > > As for the Qualcomm case: dma_alloc_coherent() is not needed here but > > simply ends up being used because it was already wired up in the > > qualcomm specific secure world API, which amounts to doing syscalls > > into a higher privilege level than the one the kernel itself runs at. > > So again, reasoning about whether the secure world will look at your > > data before you checked the sig is rather pointless, and adding > > special cases to the IMA api to cater for this use case seems like a > > waste of engineering and review effort to me. If we have to do > > something to tie up this loose end, let's try switching it to the > > streaming DMA api instead. > > > > Forgot to mention: the Qualcomm case is about passing data to the CPU > running at another privilege level, so IOMMU vs !IOMMU is not a factor > here. Agreed. ?It sounds like the dependency would be on whether the buffer has been DMA mapped. Mimi -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 86C1CC3279B for ; Tue, 10 Jul 2018 18:47:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4003C20B6F for ; Tue, 10 Jul 2018 18:47:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4003C20B6F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.ibm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388777AbeGJSrt (ORCPT ); Tue, 10 Jul 2018 14:47:49 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:52604 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1732358AbeGJSrs (ORCPT ); Tue, 10 Jul 2018 14:47:48 -0400 Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6AIi5eV130184 for ; Tue, 10 Jul 2018 14:47:31 -0400 Received: from e06smtp04.uk.ibm.com (e06smtp04.uk.ibm.com [195.75.94.100]) by mx0b-001b2d01.pphosted.com with ESMTP id 2k51araut6-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 10 Jul 2018 14:47:31 -0400 Received: from localhost by e06smtp04.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 10 Jul 2018 19:47:29 +0100 Received: from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195) by e06smtp04.uk.ibm.com (192.168.101.134) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Tue, 10 Jul 2018 19:47:24 +0100 Received: from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com [9.149.105.62]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w6AIlNhW21430418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 10 Jul 2018 18:47:23 GMT Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DDD8FAE053; Tue, 10 Jul 2018 21:47:18 +0100 (BST) Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 373E8AE045; Tue, 10 Jul 2018 21:47:17 +0100 (BST) Received: from dhcp-9-31-103-18.watson.ibm.com (unknown [9.31.103.18]) by d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTP; Tue, 10 Jul 2018 21:47:17 +0100 (BST) Subject: Re: [PATCH v5 7/8] ima: based on policy warn about loading firmware (pre-allocated buffer) From: Mimi Zohar To: Ard Biesheuvel Cc: Mimi Zohar , linux-integrity , linux-security-module , Linux Kernel Mailing List , David Howells , "Luis R . Rodriguez" , Eric Biederman , Kexec Mailing List , Andres Rodriguez , Greg Kroah-Hartman , "Luis R . Rodriguez" , Kees Cook , "Serge E . Hallyn" , Stephen Boyd , Bjorn Andersson Date: Tue, 10 Jul 2018 14:47:21 -0400 In-Reply-To: References: <1530542283-26145-1-git-send-email-zohar@linux.vnet.ibm.com> <1530542283-26145-8-git-send-email-zohar@linux.vnet.ibm.com> <1531165294.3332.40.camel@linux.ibm.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 x-cbid: 18071018-0016-0000-0000-000001E55A55 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18071018-0017-0000-0000-00003239E1ED Message-Id: <1531248441.3332.142.camel@linux.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-10_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=3 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807100199 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2018-07-10 at 08:56 +0200, Ard Biesheuvel wrote: > On 10 July 2018 at 08:51, Ard Biesheuvel wrote: > > On 9 July 2018 at 21:41, Mimi Zohar wrote: > >> On Mon, 2018-07-02 at 17:30 +0200, Ard Biesheuvel wrote: > >>> On 2 July 2018 at 16:38, Mimi Zohar wrote: > >>> > Some systems are memory constrained but they need to load very large > >>> > firmwares. The firmware subsystem allows drivers to request this > >>> > firmware be loaded from the filesystem, but this requires that the > >>> > entire firmware be loaded into kernel memory first before it's provided > >>> > to the driver. This can lead to a situation where we map the firmware > >>> > twice, once to load the firmware into kernel memory and once to copy the > >>> > firmware into the final resting place. > >>> > > >>> > To resolve this problem, commit a098ecd2fa7d ("firmware: support loading > >>> > into a pre-allocated buffer") introduced request_firmware_into_buf() API > >>> > that allows drivers to request firmware be loaded directly into a > >>> > pre-allocated buffer. (Based on the mailing list discussions, calling > >>> > dma_alloc_coherent() is unnecessary and confusing.) > >>> > > >>> > (Very broken/buggy) devices using pre-allocated memory run the risk of > >>> > the firmware being accessible to the device prior to the completion of > >>> > IMA's signature verification. For the time being, this patch emits a > >>> > warning, but does not prevent the loading of the firmware. > >>> > > >>> > >>> As I attempted to explain in the exchange with Luis, this has nothing > >>> to do with broken or buggy devices, but is simply the reality we have > >>> to deal with on platforms that lack IOMMUs. > >> > >>> Even if you load into one buffer, carry out the signature verification > >>> and *only then* copy it to another buffer, a bus master could > >>> potentially read it from the first buffer as well. Mapping for DMA > >>> does *not* mean 'making the memory readable by the device' unless > >>> IOMMUs are being used. Otherwise, a bus master can read it from the > >>> first buffer, or even patch the code that performs the security check > >>> in the first place. For such platforms, copying the data around to > >>> prevent the device from reading it is simply pointless, as well as any > >>> other mitigation in software to protect yourself from misbehaving bus > >>> masters. > >> > >> Thank you for taking the time to explain this again. > >> > >>> So issuing a warning in this particular case is rather arbitrary. On > >>> these platforms, all bus masters can read (and modify) all of your > >>> memory all of the time, and as long as the firmware loader code takes > >>> care not to provide the DMA address to the device until after the > >>> verification is complete, it really has done all it reasonably can in > >>> the environment that it is expected to operate in. > >> > >> So for the non-IOMMU system case, differentiating between pre- > >> allocated buffers vs. using two buffers doesn't make sense. > >> > >>> > >>> (The use of dma_alloc_coherent() is a bit of a red herring here, as it > >>> incorporates the DMA map operation. However, DMA map is a no-op on > >>> systems with cache coherent 1:1 DMA [iow, all PCs and most arm64 > >>> platforms unless they have IOMMUs], and so there is not much > >>> difference between memory allocated with kmalloc() or with > >>> dma_alloc_coherent() in terms of whether the device can access it > >>> freely) > >> > >> What about systems with an IOMMU? > >> > > > > On systems with an IOMMU, performing the DMA map will create an entry > > in the IOMMU page tables for the physical region associated with the > > buffer, making the region accessible to the device. For platforms in > > this category, using dma_alloc_coherent() for allocating a buffer to > > pass firmware to the device does open a window where the device could > > theoretically access this data while the validation is still in > > progress. > > > > Note that the device still needs to be informed about the address of > > the buffer: just calling dma_alloc_coherent() will not allow the > > device to find the firmware image in its memory space, and arbitrary > > DMA accesses performed by the device will trigger faults that are > > reported to the OS. So the window between DMA map (or > > dma_alloc_coherent()) and the device specific command to pass the DMA > > buffer address to the device is not inherently unsafe IMO, but I do > > understand the need to cover this scenario. > > > > As I pointed out before, using coherent DMA buffers to perform > > streaming DMA is generally a bad idea, since they may be allocated > > from a finite pool, and may use uncached mappings, making the access > > slower than necessary (while streaming DMA can use any kmalloc'ed > > buffer and will just flush the contents of the caches to main memory > > when the DMA map is performed). > > > > So to summarize again: in my opinion, using a single buffer is not a > > problem as long as the validation completes before the DMA map is > > performed. This will provide the expected guarantees on systems with > > IOMMUs, and will not complicate matters on systems where there is no > > point in obsessing about this anyway given that devices can access all > > of memory whenever they want to. It sound like as long as the pre-allocated buffer is not being re- used, either by being mapped to multiple devices or used to load multiple firmware blobs, it is safe. > > > > As for the Qualcomm case: dma_alloc_coherent() is not needed here but > > simply ends up being used because it was already wired up in the > > qualcomm specific secure world API, which amounts to doing syscalls > > into a higher privilege level than the one the kernel itself runs at. > > So again, reasoning about whether the secure world will look at your > > data before you checked the sig is rather pointless, and adding > > special cases to the IMA api to cater for this use case seems like a > > waste of engineering and review effort to me. If we have to do > > something to tie up this loose end, let's try switching it to the > > streaming DMA api instead. > > > > Forgot to mention: the Qualcomm case is about passing data to the CPU > running at another privilege level, so IOMMU vs !IOMMU is not a factor > here. Agreed.  It sounds like the dependency would be on whether the buffer has been DMA mapped. Mimi