From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jcglh-0003pk-UE for kexec@lists.infradead.org; Sun, 24 May 2020 02:53:43 +0000 Message-ID: <1590288736.5111.431.camel@linux.ibm.com> Subject: Re: [PATCH 0/3] fs: reduce export usage of kerne_read*() calls From: Mimi Zohar Date: Sat, 23 May 2020 22:52:16 -0400 In-Reply-To: References: <20200513152108.25669-1-mcgrof@kernel.org> <20200513181736.GA24342@infradead.org> <20200515212933.GD11244@42.do-not-panic.com> <20200518062255.GB15641@infradead.org> <1589805462.5111.107.camel@linux.ibm.com> <7525ca03-def7-dfe2-80a9-25270cb0ae05@broadcom.com> <202005221551.5CA1372@keescook> Mime-Version: 1.0 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: Scott Branden , Kees Cook Cc: rafael@kernel.org, dhowells@redhat.com, linux-security-module@vger.kernel.org, paul@paul-moore.com, nayna@linux.ibm.com, jmorris@namei.org, Christoph Hellwig , geert@linux-m68k.org, dan.carpenter@oracle.com, selinux@vger.kernel.org, viro@zeniv.linux.org.uk, skhan@linuxfoundation.org, eparis@parisplace.org, tglx@linutronix.de, gregkh@linuxfoundation.org, stephen.smalley.work@gmail.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, Luis Chamberlain , ebiederm@xmission.com, jeyu@kernel.org, linux-fsdevel@vger.kernel.org, linux-integrity@vger.kernel.org, bauerman@linux.ibm.com T24gRnJpLCAyMDIwLTA1LTIyIGF0IDE2OjI1IC0wNzAwLCBTY290dCBCcmFuZGVuIHdyb3RlOgo+ IEhpIEtlZXMsCj4gCj4gT24gMjAyMC0wNS0yMiA0OjA0IHAubS4sIEtlZXMgQ29vayB3cm90ZToK PiA+IE9uIEZyaSwgTWF5IDIyLCAyMDIwIGF0IDAzOjI0OjMyUE0gLTA3MDAsIFNjb3R0IEJyYW5k ZW4gd3JvdGU6Cj4gPj4gT24gMjAyMC0wNS0xOCA1OjM3IGEubS4sIE1pbWkgWm9oYXIgd3JvdGU6 Cj4gPj4+IE9uIFN1biwgMjAyMC0wNS0xNyBhdCAyMzoyMiAtMDcwMCwgQ2hyaXN0b3BoIEhlbGx3 aWcgd3JvdGU6Cj4gPj4+PiBPbiBGcmksIE1heSAxNSwgMjAyMCBhdCAwOToyOTozM1BNICswMDAw LCBMdWlzIENoYW1iZXJsYWluIHdyb3RlOgo+ID4+Pj4+IE9uIFdlZCwgTWF5IDEzLCAyMDIwIGF0 IDExOjE3OjM2QU0gLTA3MDAsIENocmlzdG9waCBIZWxsd2lnIHdyb3RlOgo+ID4+Pj4+PiBDYW4g eW91IGFsc28gbW92ZSBrZXJuZWxfcmVhZF8qIG91dCBvZiBmcy5oPyAgVGhhdCBoZWFkZXIgZ2V0 cyBwdWxsZWQKPiA+Pj4+Pj4gaW4ganVzdCBhYm91dCBldmVyeXdoZXJlIGFuZCBkb2Vzbid0IHJl YWxseSBuZWVkIGZ1bmN0aW9uIG5vdCByZWxhdGVkCj4gPj4+Pj4+IHRvIHRoZSBnZW5lcmFsIGZz IGludGVyZmFjZS4KPiA+Pj4+PiBTdXJlLCB3aGVyZSBzaG91bGQgSSBkdW1wIHRoZXNlPwo+ID4+ Pj4gTWF5YmUgYSBuZXcgbGludXgva2VybmVsX3JlYWRfZmlsZS5oPyAgQm9udXMgcG9pbnRzIGZv ciBhIHNtYWxsIHRvcAo+ID4+Pj4gb2YgdGhlIGZpbGUgY29tbWVudCBleHBsYWluaW5nIHRoZSBw b2ludCBvZiB0aGUgaW50ZXJmYWNlLCB3aGljaCBJCj4gPj4+PiBzdGlsbCBkb24ndCBnZXQgOikK PiA+Pj4gSW5zdGVhZCBvZiByb2xsaW5nIHlvdXIgb3duIG1ldGhvZCBvZiBoYXZpbmcgdGhlIGtl cm5lbCByZWFkIGEgZmlsZSwKPiA+Pj4gd2hpY2ggcmVxdWlyZXMgY2FsbCBzcGVjaWZpYyBzZWN1 cml0eSBob29rcywgdGhpcyBpbnRlcmZhY2UgcHJvdmlkZXMgYQo+ID4+PiBzaW5nbGUgZ2VuZXJp YyBzZXQgb2YgcHJlIGFuZCBwb3N0IHNlY3VyaXR5IGhvb2tzLsKgwqBUaGUKPiA+Pj4ga2VybmVs X3JlYWRfZmlsZV9pZCBlbnVtZXJhdGlvbiBwZXJtaXRzIHRoZSBzZWN1cml0eSBob29rIHRvCj4g Pj4+IGRpZmZlcmVudGlhdGUgYmV0d2VlbiBjYWxsZXJzLgo+ID4+Pgo+ID4+PiBUbyBjb21wbHkg d2l0aCBzZWN1cmUgYW5kIHRydXN0ZWQgYm9vdCBjb25jZXB0cywgYSBmaWxlIGNhbm5vdCBiZQo+ ID4+PiBhY2Nlc3NpYmxlIHRvIHRoZSBjYWxsZXIgdW50aWwgYWZ0ZXIgaXQgaGFzIGJlZW4gbWVh c3VyZWQgYW5kL29yIHRoZQo+ID4+PiBpbnRlZ3JpdHkgKGhhc2gvc2lnbmF0dXJlKSBhcHByYWlz ZWQuCj4gPj4+Cj4gPj4+IEluIHNvbWUgY2FzZXMsIHRoZSBmaWxlIHdhcyBwcmV2aW91c2x5IHJl YWQgdHdpY2UsIGZpcnN0IHRvIG1lYXN1cmUKPiA+Pj4gYW5kL29yIGFwcHJhaXNlIHRoZSBmaWxl IGFuZCB0aGVuIHJlYWQgYWdhaW4gaW50byBhIGJ1ZmZlciBmb3IKPiA+Pj4gdXNlLsKgwqBUaGlz IGludGVyZmFjZSByZWFkcyB0aGUgZmlsZSBpbnRvIGEgYnVmZmVyIG9uY2UsIGNhbGxzIHRoZQo+ ID4+PiBnZW5lcmljIHBvc3Qgc2VjdXJpdHkgaG9vaywgYmVmb3JlIHByb3ZpZGluZyB0aGUgYnVm ZmVyIHRvIHRoZSBjYWxsZXIuCj4gPj4+ICAgwqAoTm90ZSB1c2luZyBmaXJtd2FyZSBwcmUtYWxs b2NhdGVkIG1lbW9yeSBtaWdodCBiZSBhbiBpc3N1ZS4pCj4gPj4+Cj4gPj4+IFBhcnRpYWwgcmVh ZGluZyBmaXJtd2FyZSB3aWxsIHJlc3VsdCBpbiBuZWVkaW5nIHRvIHByZS1yZWFkIHRoZSBlbnRp cmUKPiA+Pj4gZmlsZSwgbW9zdCBsaWtlbHkgb24gdGhlIHNlY3VyaXR5IHByZSBob29rLgo+ID4+ IFRoZSBlbnRpcmUgZmlsZSBtYXkgYmUgdmVyeSBsYXJnZSBhbmQgbm90IGZpdCBpbnRvIGEgYnVm ZmVyLgo+ID4+IEhlbmNlIG9uZSBvZiB0aGUgcmVhc29ucyBmb3IgYSBwYXJ0aWFsIHJlYWQgb2Yg dGhlIGZpbGUuCj4gPj4gRm9yIHNlY3VyaXR5IHB1cnBvc2VzLCB5b3UgbmVlZCB0byBjaGFuZ2Ug eW91ciBjb2RlIHRvIGxpbWl0IHRoZSBhbW91bnQKPiA+PiBvZiBkYXRhIGl0IHJlYWRzIGludG8g YSBidWZmZXIgYXQgb25lIHRpbWUgdG8gbm90IGNvbnN1bWUgb3IgcnVuIG91dCBvZiBtdWNoCj4g Pj4gbWVtb3J5Lgo+ID4gSG0/IFRoYXQncyBub3QgaG93IHdob2xlLWZpbGUgaGFzaGluZyB3b3Jr cy4gOikKPiAKPiA+Cj4gPiBUaGVzZSBob29rcyBuZWVkIHRvIGZpbmlzaCB0aGVpciBoYXNoaW5n IGFuZCBwb2xpY3kgY2hlY2tpbmcgYmVmb3JlIHRoZXkKPiA+IGNhbiBhbGxvdyB0aGUgcmVzdCBv ZiB0aGUgY29kZSB0byBtb3ZlIGZvcndhcmQuIChUaGF0J3Mgd2h5IGl0J3MgYQo+ID4gc2VjdXJp dHkgaG9vay4pIElmIGtlcm5lbCBtZW1vcnkgdXRpbGl6YXRpb24gaXMgdGhlIHByaW1hcnkgY29u Y2VybiwKPiA+IHRoZW4gc3VyZSwgdGhpbmdzIGNvdWxkIGJlIHJlYXJyYW5nZWQgdG8gZG8gcGFy dGlhbCByZWFkIGFuZCB1cGRhdGUgdGhlCj4gPiBoYXNoIGluY3JlbWVudGFsbHksIGJ1dCB0aGUg ZW50aXJlIGZpbGUgc3RpbGwgbmVlZHMgdG8gYmUgbG9ja2VkLAo+ID4gZW50aXJlbHkgaGFzaGVk IGJ5IGhvb2ssIHRoZW4gcmVhZCBieSB0aGUgY2FsbGVyLCB0aGVuIHVubG9ja2VkIGFuZAo+ID4g cmVsZWFzZWQuCgpFeGFjdGx5LgoKPiA+Cj4gPiBTbywgaWYgeW91IHdhbnQgdG8gaGF2ZSBwYXJ0 aWFsIGZpbGUgcmVhZHMgd29yaywgeW91J2xsIG5lZWQgdG8KPiA+IHJlYXJjaGl0ZWN0IHRoZSB3 YXkgdGhpcyB3b3JrcyB0byBhdm9pZCByZWdyZXNzaW5nIHRoZSBzZWN1cml0eSBjb3ZlcmFnZQo+ ID4gb2YgdGhlc2Ugb3BlcmF0aW9ucy4KPiBJIGFtIG5vdCBmYW1pbGlhciB3aXRoIGhvdyB0aGUg c2VjdXJpdHkgaGFuZGxpbmcgY29kZSB3b3JrcyBhdCBhbGwuCj4gSXMgdGhlIHNhbWUgc2VjdXJp dHkgY2hlY2sgcnVuIG9uIGZpbGVzIG9wZW5lZCBmcm9tIHVzZXIgc3BhY2U/Cj4gQSBmaWxlIGNv dWxkIGJlIGh1Z2UuCj4gCj4gSWYgaXQgYXNzdW1lcyB0aGVyZSBpcyB0aGVyZSBpcyBlbm91Z2gg bWVtb3J5IGF2YWlsYWJsZSB0byByZWFkIHRoZSAKPiBlbnRpcmUgZmlsZSBpbnRvIGtlcm5lbCBz cGFjZSB0aGVuIHRoZSBpbXByb3ZlbWVudCBiZWxvdyBjYW4gYmUgbGVmdCBhcwo+IGEgbWVtb3J5 IG9wdGltaXphdGlvbiB0byBiZSBkb25lIGluIGFuIGluZGVwZW5kZW50IChvciBmdXR1cmUpIHBh dGNoIHNlcmllcy4KClRoZXJlIGFyZSB0d28gc2VjdXJpdHkgaG9va3MgLSBzZWN1cml0eV9rZXJu ZWxfcmVhZF9maWxlKCksCnNlY3VyaXR5X2tlcm5lbF9wb3N0X3JlYWRfZmlsZSAtIGluIGtlcm5l bF9yZWFkX2ZpbGUoKS4gwqBUaGUgZmlyc3QKaG9vayBpcyBjYWxsZWQgYmVmb3JlIHRoZSBmaWxl IGlzIHJlYWQgaW50byBhIGJ1ZmZlciwgd2hpbGUgdGhlIHNlY29uZApob29rIGlzIGNhbGxlZCBh ZnRlcndhcmRzLgoKRm9yIHBhcnRpYWwgcmVhZHMsIG1lYXN1cmluZyB0aGUgZmlybXdhcmUgYW5k IHZlcmlmeWluZyB0aGUgZmlybXdhcmUncwpzaWduYXR1cmUgd2lsbCBuZWVkIHRvIGJlIGRvbmUg b24gdGhlIHNlY3VyaXR5X2tlcm5lbF9yZWFkX2ZpbGUoKQpob29rLgoKPiAKPiA+IFNvLCBwcm9i YWJseSwgdGhlIGNvZGUgd2lsbCBsb29rIHNvbWV0aGluZyBsaWtlOgo+ID4KPiA+Cj4gPiBmaWxl ID0ga2VybmVsX29wZW5fZmlsZV9mb3JfcmVhZGluZyguLi4pCj4gPiAJZmlsZSA9IG9wZW4uLi4K PiA+IAlkaXNhbGxvd193cml0ZXMoZmlsZSk7Cj4gPiAJd2hpbGUgKHByb2Nlc3NlZCA8IHNpemUt b2YtZmlsZSkgewo+ID4gCQlidWYgPSByZWFkKGZpbGUsIHNpemUuLi4pCj4gPiAJCXNlY3VyaXR5 X2ZpbGVfcmVhZF9wYXJ0aWFsKGJ1ZikKPiA+IAl9Cj4gPiAJcmV0ID0gc2VjdXJpdHlfZmlsZV9y ZWFkX2ZpbmlzaGVkKGZpbGUpOwo+ID4gCWlmIChyZXQgPCAwKSB7Cj4gPiAJCWFsbG93X3dyaXRl cyhmaWxlKTsKPiA+IAkJcmV0dXJuIFBUUl9FUlIocmV0KTsKPiA+IAl9Cj4gPiAJcmV0dXJuIGZp bGU7Cj4gPgo+ID4gd2hpbGUgKHByb2Nlc3NlZCA8IHNpemUtb2YtZmlsZSkgewo+ID4gCWJ1ZiA9 IHJlYWQoZmlsZSwgc2l6ZS4uLikKPiA+IAlmaXJtd2FyZV9zZW5kX3BhcnRpYWwoYnVmKTsKPiA+ IH0KPiA+Cj4gPiBrZXJuZWxfY2xvc2VfZmlsZV9mb3JfcmVhZGluZyhmaWxlKQo+ID4gCWFsbG93 X3dyaXRlcyhmaWxlKTsKClJpZ2h0LCB0aGUgaW1hX2ZpbGVfbW1hcCgpLCBpbWFfYnBybV9jaGVj aygpLCBhbmQgaW1hX2ZpbGVfY2hlY2soKQpob29rcyBjYWxsIHByb2Nlc3NfbWVhc3VyZW1lbnQo KSB0byBkbyB0aGlzLiDCoGltYV9wb3N0X3JlYWRfZmlsZSgpCnBhc3NlcyBhIGJ1ZmZlciB0byBw cm9jZXNzX21lYXN1cmVtZW50KCkgaW5zdGVhZC4KClNjb3R0LCB0aGUgY2hhbmdlIHNob3VsZCBi ZSBzdHJhaWdodCBmb3J3YXJkLiDCoFRoZSBhZGRpdGlvbmFsIHBhdGNoCm5lZWRzIHRvOgotIGRl ZmluZSBhIG5ldyBrZXJuZWxfcmVhZF9maWxlX2lkIGVudW1lcmF0aW9uLCBsaWtlCkZJUk1XQVJF X1BBUlRJQUxfUkVBRC4KLSBDdXJyZW50bHkgaW1hX3JlYWRfZmlsZSgpIGhhcyBhIGNvbW1lbnQg YWJvdXQgcHJlLWFsbG9jYXRlZCBmaXJtd2FyZQpidWZmZXJzLiDCoFVwZGF0ZSBpbWFfcmVhZF9m aWxlKCkgdG8gY2FsbCBwcm9jZXNzX21lYXN1cmVtZW50KCkgZm9yIHRoZQpuZXcgZW51bWVyYXRp b24gRklSTVdBUkVfUEFSVElBTF9SRUFEIGFuZCB1cGRhdGUgaW1hX3Bvc3RfcmVhZF9maWxlKCkK dG8gcmV0dXJuIGltbWVkaWF0ZWx5LgoKVGhlIGJ1aWx0LWluIElNQSBtZWFzdXJlbWVudCBwb2xp Y3kgY29udGFpbnMgYSBydWxlIHRvIG1lYXN1cmUKZmlybXdhcmUuIMKgVGhlIHBvbGljeSBjYW4g YmUgc3BlY2lmaWVkIG9uIHRoZSBib290IGNvbW1hbmQgbGluZSBieQpzcGVjaWZ5aW5nICJpbWFf cG9saWN5PXRjYiIuIMKgQWZ0ZXIgcmVhZGluZyB0aGUgZmlybXdhcmUsIHRoZSBmaXJtd2FyZQpt ZWFzdXJlbWVudCBzaG91bGQgYmUgaW4gPHNlY3VyaXR5ZnM+L2ltYS9hc2NpaV9ydW50aW1lX21l YXN1cmVtZW50cy4KCnRoYW5rcywKCk1pbWkKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCmtleGVjIG1haWxpbmcgbGlzdAprZXhlY0BsaXN0cy5pbmZyYWRl YWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8va2V4ZWMK 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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 autolearn=no 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 1BF1DC433E0 for ; Sun, 24 May 2020 02:53:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 03CF420759 for ; Sun, 24 May 2020 02:53:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388309AbgEXCxu (ORCPT ); Sat, 23 May 2020 22:53:50 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:55614 "EHLO mx0b-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388262AbgEXCxu (ORCPT ); Sat, 23 May 2020 22:53:50 -0400 Received: from pps.filterd (m0127361.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 04O2WueA118978; Sat, 23 May 2020 22:52:25 -0400 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 316xn3hqc0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 23 May 2020 22:52:25 -0400 Received: from m0127361.ppops.net (m0127361.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 04O2XQhe120524; Sat, 23 May 2020 22:52:24 -0400 Received: from ppma01fra.de.ibm.com (46.49.7a9f.ip4.static.sl-reverse.com [159.122.73.70]) by mx0a-001b2d01.pphosted.com with ESMTP id 316xn3hqbk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 23 May 2020 22:52:24 -0400 Received: from pps.filterd (ppma01fra.de.ibm.com [127.0.0.1]) by ppma01fra.de.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 04O2pcoi020197; Sun, 24 May 2020 02:52:23 GMT Received: from b06avi18626390.portsmouth.uk.ibm.com (b06avi18626390.portsmouth.uk.ibm.com [9.149.26.192]) by ppma01fra.de.ibm.com with ESMTP id 316uf8gmuw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 24 May 2020 02:52:22 +0000 Received: from d06av25.portsmouth.uk.ibm.com (d06av25.portsmouth.uk.ibm.com [9.149.105.61]) by b06avi18626390.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 04O2p6C066060664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 24 May 2020 02:51:07 GMT Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E7F6311C050; Sun, 24 May 2020 02:52:19 +0000 (GMT) Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 398BE11C04C; Sun, 24 May 2020 02:52:17 +0000 (GMT) Received: from localhost.localdomain (unknown [9.80.203.161]) by d06av25.portsmouth.uk.ibm.com (Postfix) with ESMTP; Sun, 24 May 2020 02:52:17 +0000 (GMT) Message-ID: <1590288736.5111.431.camel@linux.ibm.com> Subject: Re: [PATCH 0/3] fs: reduce export usage of kerne_read*() calls From: Mimi Zohar To: Scott Branden , Kees Cook Cc: Christoph Hellwig , Luis Chamberlain , viro@zeniv.linux.org.uk, gregkh@linuxfoundation.org, rafael@kernel.org, ebiederm@xmission.com, jeyu@kernel.org, jmorris@namei.org, paul@paul-moore.com, stephen.smalley.work@gmail.com, eparis@parisplace.org, nayna@linux.ibm.com, dan.carpenter@oracle.com, skhan@linuxfoundation.org, geert@linux-m68k.org, tglx@linutronix.de, bauerman@linux.ibm.com, dhowells@redhat.com, linux-integrity@vger.kernel.org, linux-fsdevel@vger.kernel.org, kexec@lists.infradead.org, linux-security-module@vger.kernel.org, selinux@vger.kernel.org, linux-kernel@vger.kernel.org Date: Sat, 23 May 2020 22:52:16 -0400 In-Reply-To: References: <20200513152108.25669-1-mcgrof@kernel.org> <20200513181736.GA24342@infradead.org> <20200515212933.GD11244@42.do-not-panic.com> <20200518062255.GB15641@infradead.org> <1589805462.5111.107.camel@linux.ibm.com> <7525ca03-def7-dfe2-80a9-25270cb0ae05@broadcom.com> <202005221551.5CA1372@keescook> 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-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216,18.0.676 definitions=2020-05-23_14:2020-05-22,2020-05-23 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 adultscore=0 malwarescore=0 priorityscore=1501 clxscore=1015 impostorscore=0 lowpriorityscore=0 cotscore=-2147483648 phishscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2005240020 Sender: linux-integrity-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-integrity@vger.kernel.org On Fri, 2020-05-22 at 16:25 -0700, Scott Branden wrote: > Hi Kees, > > On 2020-05-22 4:04 p.m., Kees Cook wrote: > > On Fri, May 22, 2020 at 03:24:32PM -0700, Scott Branden wrote: > >> On 2020-05-18 5:37 a.m., Mimi Zohar wrote: > >>> On Sun, 2020-05-17 at 23:22 -0700, Christoph Hellwig wrote: > >>>> On Fri, May 15, 2020 at 09:29:33PM +0000, Luis Chamberlain wrote: > >>>>> On Wed, May 13, 2020 at 11:17:36AM -0700, Christoph Hellwig wrote: > >>>>>> Can you also move kernel_read_* out of fs.h? That header gets pulled > >>>>>> in just about everywhere and doesn't really need function not related > >>>>>> to the general fs interface. > >>>>> Sure, where should I dump these? > >>>> Maybe a new linux/kernel_read_file.h? Bonus points for a small top > >>>> of the file comment explaining the point of the interface, which I > >>>> still don't get :) > >>> Instead of rolling your own method of having the kernel read a file, > >>> which requires call specific security hooks, this interface provides a > >>> single generic set of pre and post security hooks.  The > >>> kernel_read_file_id enumeration permits the security hook to > >>> differentiate between callers. > >>> > >>> To comply with secure and trusted boot concepts, a file cannot be > >>> accessible to the caller until after it has been measured and/or the > >>> integrity (hash/signature) appraised. > >>> > >>> In some cases, the file was previously read twice, first to measure > >>> and/or appraise the file and then read again into a buffer for > >>> use.  This interface reads the file into a buffer once, calls the > >>> generic post security hook, before providing the buffer to the caller. > >>>  (Note using firmware pre-allocated memory might be an issue.) > >>> > >>> Partial reading firmware will result in needing to pre-read the entire > >>> file, most likely on the security pre hook. > >> The entire file may be very large and not fit into a buffer. > >> Hence one of the reasons for a partial read of the file. > >> For security purposes, you need to change your code to limit the amount > >> of data it reads into a buffer at one time to not consume or run out of much > >> memory. > > Hm? That's not how whole-file hashing works. :) > > > > > These hooks need to finish their hashing and policy checking before they > > can allow the rest of the code to move forward. (That's why it's a > > security hook.) If kernel memory utilization is the primary concern, > > then sure, things could be rearranged to do partial read and update the > > hash incrementally, but the entire file still needs to be locked, > > entirely hashed by hook, then read by the caller, then unlocked and > > released. Exactly. > > > > So, if you want to have partial file reads work, you'll need to > > rearchitect the way this works to avoid regressing the security coverage > > of these operations. > I am not familiar with how the security handling code works at all. > Is the same security check run on files opened from user space? > A file could be huge. > > If it assumes there is there is enough memory available to read the > entire file into kernel space then the improvement below can be left as > a memory optimization to be done in an independent (or future) patch series. There are two security hooks - security_kernel_read_file(), security_kernel_post_read_file - in kernel_read_file().  The first hook is called before the file is read into a buffer, while the second hook is called afterwards. For partial reads, measuring the firmware and verifying the firmware's signature will need to be done on the security_kernel_read_file() hook. > > > So, probably, the code will look something like: > > > > > > file = kernel_open_file_for_reading(...) > > file = open... > > disallow_writes(file); > > while (processed < size-of-file) { > > buf = read(file, size...) > > security_file_read_partial(buf) > > } > > ret = security_file_read_finished(file); > > if (ret < 0) { > > allow_writes(file); > > return PTR_ERR(ret); > > } > > return file; > > > > while (processed < size-of-file) { > > buf = read(file, size...) > > firmware_send_partial(buf); > > } > > > > kernel_close_file_for_reading(file) > > allow_writes(file); Right, the ima_file_mmap(), ima_bprm_check(), and ima_file_check() hooks call process_measurement() to do this.  ima_post_read_file() passes a buffer to process_measurement() instead. Scott, the change should be straight forward.  The additional patch needs to: - define a new kernel_read_file_id enumeration, like FIRMWARE_PARTIAL_READ. - Currently ima_read_file() has a comment about pre-allocated firmware buffers.  Update ima_read_file() to call process_measurement() for the new enumeration FIRMWARE_PARTIAL_READ and update ima_post_read_file() to return immediately. The built-in IMA measurement policy contains a rule to measure firmware.  The policy can be specified on the boot command line by specifying "ima_policy=tcb".  After reading the firmware, the firmware measurement should be in /ima/ascii_runtime_measurements. thanks, Mimi