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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7334CEB64DD for ; Fri, 11 Aug 2023 15:48:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ngPnU2XjsjsrI0K7OSYy1p1ZlS+jEFo3ujKOFbrC8zM=; b=MJsv+TUBz4l917 75dQXvKgc8I0REfFYZOJGSxG9N/7vFr0Xrxu24y4zxQgJevjQ1q8nE6N64szD+GL0ssfPXnnaGlIS JDrLLsycMheqMpgmR80rQmmY/WsVhIuT/nDIt8bKkopTqm9AVLLeYtAz2u2ToSEtrUaRVlH62gS4e +ZGew33iFcc9mzKkpfmowCjJWIQp38peVXRAgheXubLFgaCjQgu0eq2FgexV5N7/LIcOq7Ex/gPBT ZRqZUEwTYGd98eb5rpmr+3XWM21QWo2+V/hnqqmsKGcNhsQsmG1o5561ehsObscGlTEnTQMa1etti 3CYjpHEVUYUBB9UEC9wA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qUUNL-00Azyk-05; Fri, 11 Aug 2023 15:48:31 +0000 Received: from linux.microsoft.com ([13.77.154.182]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qUUNH-00AzyF-2p for kexec@lists.infradead.org; Fri, 11 Aug 2023 15:48:29 +0000 Received: from [192.168.87.33] (c-98-237-170-177.hsd1.wa.comcast.net [98.237.170.177]) by linux.microsoft.com (Postfix) with ESMTPSA id 7D7F220FD0C5; Fri, 11 Aug 2023 08:48:25 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 7D7F220FD0C5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1691768906; bh=UKEi7WJXl5hJdjwWxrw5NDZOvUTxztWU9msXupBAioE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=A6+wUIIfI7qkrBchbUMDtIOLwpRi462atJwsAdwPMskRKIouLHmAuAFQcqqhKe3sw IbTJPMBTNn74Wx7KMNU/BJFuXsumZex+1WQ8TVvGWSYxeC66PQXxRyC7/3THmzbYtN ShK5qUuuLyTQk6zoKUh8SAI5FmkRRZXid70JmORs= Message-ID: <72e39852-1ff1-c7f6-ac7e-593e8142dbe8@linux.microsoft.com> Date: Fri, 11 Aug 2023 08:48:25 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [RFC] IMA Log Snapshotting Design Proposal Content-Language: en-US To: James Bottomley , Stefan Berger , Sush Shringarputale , linux-integrity@vger.kernel.org, zohar@linux.ibm.com, peterhuewe@gmx.de, jarkko@kernel.org, jgg@ziepe.ca, kgold@linux.ibm.com, bhe@redhat.com, vgoyal@redhat.com, dyoung@redhat.com, kexec@lists.infradead.org, jmorris@namei.org, Paul Moore , serge@hallyn.com Cc: code@tyhicks.com, nramas@linux.microsoft.com, linux-security-module@vger.kernel.org References: <5d21276a-daac-fc9b-add9-62e7c04bbdcd@linux.ibm.com> <8ad131f35c33cf10788344be6c981473971f9c1c.camel@HansenPartnership.com> <350ecdcbf7796f488807fcd7983414a02dd71be4.camel@HansenPartnership.com> <04fb2fe5-9ebe-b35f-bdde-6ef22786438f@linux.ibm.com> <5cb03349-7a32-8f74-f2a1-ff3c6247c1ef@linux.microsoft.com> <8ccaec30bf85cfbf4415bbafa22646a62e753840.camel@HansenPartnership.com> From: Tushar Sugandhi In-Reply-To: <8ccaec30bf85cfbf4415bbafa22646a62e753840.camel@HansenPartnership.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230811_084827_990163_53216C1E X-CRM114-Status: GOOD ( 42.56 ) X-BeenThere: kexec@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: "kexec" Errors-To: kexec-bounces+kexec=archiver.kernel.org@lists.infradead.org CgpPbiA4LzEwLzIzIDA0OjQzLCBKYW1lcyBCb3R0b21sZXkgd3JvdGU6Cj4gT24gV2VkLCAyMDIz LTA4LTA5IGF0IDIxOjQzIC0wNzAwLCBUdXNoYXIgU3VnYW5kaGkgd3JvdGU6Cj4+IE9uIDgvOC8y MyAxNDo0MSwgSmFtZXMgQm90dG9tbGV5IHdyb3RlOgo+Pj4gT24gVHVlLCAyMDIzLTA4LTA4IGF0 IDE2OjA5IC0wNDAwLCBTdGVmYW4gQmVyZ2VyIHdyb3RlOgo+IFsuLi5dCj4+Pj4gIMKgIGF0IHRo aXMgcG9pbnQgZG9lc24ndCBzZWVtIG5lY2Vzc2FyeSBzaW5jZSBvbmUgcHJlc3VtYWJseSBjYW4K Pj4+PiB2ZXJpZnkgdGhlIGxvZyBhbmQgUENSIHN0YXRlcyBhdCB0aGUgZW5kIHdpdGggdGhlICdy ZWd1bGFyJwo+Pj4+IHF1b3RlLgo+Pj4gICAKPj4+IEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGlzLsKg IEEgcmVndWxhciBxdW90ZSBpcyBhIHNpZ25hdHVyZSBvdmVyIFBDUgo+Pj4gc3RhdGUgYnkgYW4g QUsuwqAgVGhlIHBvaW50IGFib3V0IHNhdmluZyB0aGUgQUsgaW4gdGhlIGxvZyBmb3IgdGhlCj4+ PiBvcmlnaW5hbCBpcyB0aGF0IGlmIHRoZSAqa2VybmVsKiB0cnVuY2F0ZXMgdGhlIGxvZyBhbmQg c2F2ZXMgaXQgdG8KPj4+IGEgZmlsZSwgaXQgbmVlZHMgdG8gZ2VuZXJhdGUgYm90aCB0aGUgQUsg YW5kIHRoZSBxdW90ZSBmb3IgdGhlIHRvcAo+Pj4gb2YgdGhlIGZpbGUgc2hhcmQuIFRoYXQgbWVh bnMgdGhlIEFLL0VLIGJpbmRpbmcgaXMgdW52ZXJpZmllZCwgYnV0Cj4+PiBjYW4gYmUgdmVyaWZp ZWQgYnkgbG9hZGluZyB0aGUgQUsgYW5kIHJ1bm5pbmcgdGhlIHVzdWFsIHRlc3RzLAo+Pj4gd2hp Y2ggY2FuIG9ubHkgYmUgZG9uZSBpZiB5b3UgaGF2ZSB0aGUgbG9hZGFibGUgQUssIHdoaWNoIGlz IHdoeQo+Pj4geW91IG5lZWQgaXQgYXMgcGFydCBvZiB0aGUgbG9nIHNhdmluZyBwcm9wb3NhbC4K Pj4gICAKPj4gSSBoYWQgdGhpcyBxdWVzdGlvbiBhYm91dCB0aGUgdXNhYmlsaXR5IG9mIEFLL0VL IGluIHRoaXMKPj4gY29udGV4dC4gQWx0aG91Z2ggQUsvRUsgKyBQQ1IgcXVvdGUgaXMgbmVlZGVk IHRvIHZlcmlmeSB0aGUgc25hcHNob3QKPj4gc2hhcmRzIC8gSU1BIGxvZ3MgYXJlIG5vdCB0YW1w ZXJlZCB3aXRoLCBJIGFtIHN0aWxsIG5vdCBzdXJlIHdoeQo+PiBBSy9FSyBuZWVkcyB0byBiZSBw YXJ0IG9mIHRoZSBzaGFyZC9JTUEgbG9nLiBUaGUgY2xpZW50IHNlbmRpbmcgQUsvRUsKPj4gdG8g YXR0ZXN0YXRpb24gc2VydmljZSBzZXBhcmF0ZWx5IHdvdWxkIHN0aWxsIHNlcnZlIHRoZSBwdXJw b3NlLAo+PiByaWdodD8KPiAKPiBXZWxsLCB0aGUgRUsgZG9lc24ndCBuZWVkIHRvIGJlIHBhcnQg b2YgdGhlIGxvZzogaXQncyBqdXN0IGEgcGVybWFuZW50Cj4gcGFydCBvZiB0aGUgVFBNIGlkZW50 aXR5LiAgVG8gdmVyaWZ5IHRoZSBsb2csIHlvdSBuZWVkIGFjY2VzcyB0byB0aGUKPiBUUE0gdGhh dCB3YXMgdXNlZCB0byBjcmVhdGUgaXQsIHNvIHRoYXQncyB0aGUgcG9pbnQgYXQgd2hpY2ggeW91 IGdldAo+IHRoZSBFSy4KPiAKQWdyZWVkLiBFSyBpcyBwYXJ0IG9mIFRQTSBpZGVudGl0eS4gQnV0 IHRvIHZlcmlmeSB0aGUgbG9nLAp5b3UgZG9u4oCZdCBuZWVkIHRvIGhhdmUgcGh5c2ljYWwgYWNj ZXNzIHRvIHRoZSBUUE0uIFlvdSBuZWVkIHRvIGhhdmUKYWNjZXNzIHRvIGp1c3QgcHVibGljIHBh cnQgb2YgRUsgYW5kIEFLL0FJSyBjZXJ0cyAoVFBNIG9uIHRoZSBzeXN0ZW0Kd291bGQgc2lnbiB0 aGUgcXVvdGUgdXNpbmcgdGhlIHByaXZhdGUgQUspLgpJIGJlbGlldmUgeW91IGFscmVhZHkga25v dyB0aGlzLCBqdXN0IHN0YXRpbmcgZm9yIHRoZSBzYWtlIG9mCmNvbXBsZXRpbmcgdGhlIGNvbnZl cnNhdGlvbi4gOikKPiBBbiBBSyBpcyBzaW1wbHkgYSBUUE0gZ2VuZXJhdGVkIHNpZ25pbmcga2V5 IChtZWFuaW5nIHRoZSBwcml2YXRlIHBhcnQKPiBvZiB0aGUga2V5IGlzIHNlY3VyZWQgYnkgdGhl IFRQTSBhbmQga25vd24gdG8gbm8tb25lIGVsc2UpLiAgSW4gdGhlCj4gbGl0ZXJhdHVyZSBhIFRQ TSBnZW5lcmF0ZWQgc2lnbmluZyBrZXkgZG9lc24ndCBiZWNvbWUgYW4gQXR0ZXN0YXRpb24KPiBL ZXkgdW50aWwgaXQncyBiZWVuIHZlcmlmaWVkIHVzaW5nIGFuIEVLIHByb3BlcnR5IChlaXRoZXIg YSBjZXJ0aWZ5IGZvcgo+IGEgc2lnbmluZyBFSyBvciBhIG1ha2UvYWN0aXZhdGUgY3JlZGVudGlh bCByb3VuZCB0cmlwIGZvciB0aGUgbW9yZQo+IHVzdWFsIGVuY3J5cHRpb24gRUsuCj4gClllcy4g VGhhdCBhbGlnbnMgd2l0aCBteSB1bmRlcnN0YW5kaW5nIG9mIEVLL0FLIGluIGdlbmVyYWwuClRo YW5rcyBmb3IgZGVzY3JpYmluZy4KCj4gU28gdGhlIHByb3Bvc2FsIGlzIGZvciBlYWNoIHF1b3Rl IHRoYXQncyB1c2VkIHRvIHZlcmlmeSBhIGxvZyBzaGFyZCBpcwo+IHRoYXQgdGhlIFRQTSBzaW1w bHkgZ2VuZXJhdGUgYSByYW5kb20gc2lnbmluZyBrZXkgYW5kIHVzZSB0aGF0IHRvIHNpZ24KSSBi ZWxpZXZlIHlvdSBhcmUgc3VnZ2VzdGluZyBjcmVhdGluZyBhIG5ldyBBSyBlYWNoIHRpbWUgeW91 CndhbnQgdG8gc2lnbiBhIFBDUiBxdW90ZS4gSXQgaXMgZG9hYmxlIGluIFRQTSAyLjAsIGFuZCBp dCBwcm92aWRlcwpiZW5lZml0cyBsaWtlIHByaXZhY3kgYW5kIHVudHJhY2VhYmlsaXR5LiBCdXQg aXQgY29tZXMgd2l0aCBpdOKAmXMgb3duCmNvc3RzIOKAkyBjb3N0IG9mIGdlbmVyYXRpbmcgbmV3 IEFLIGVhY2ggdGltZSB5b3Ugd2FudCB0byBzaWduLAptYWludGFpbmluZyBtYXBwaW5nIG9mIEFL IGFuZCBpdOKAmXMgc2lnbmVkIHF1b3RlcywgbWFpbnRhaW5pbmcKbXVsdGlwbGUgcHVibGljIEFL IGNlcnRzIGV0Yy4KCj4gdGhlIHF1b3RlLiAgWW91IG5lZWQgdG8gc2F2ZSB0aGUgVFBNIGZvcm0g b2YgdGhlIGdlbmVyYXRlZCBrZXkgc28gaXQKPiBjYW4gYmUgbG9hZGVkIGxhdGVyIGFuZCB0aGUg cmVhc29uIGZvciB0aGF0IGlzIHlvdSBjYW4gZG8gdGhlIEVLCj4gdmVyaWZpY2F0aW9uIGF0IGFu eSB0aW1lIGFmdGVyIHRoZSBxdW90ZSB3YXMgZ2l2ZW4gYnkgbG9hZGluZyB0aGUgc2F2ZWQKPiBr ZXkgYW5kIHJ1bm5pbmcgdGhlIHZlcmlmaWNhdGlvbiBwcm90b2NvbC4gIEluIHRoZSBub3JtYWwg YXR0ZXN0YXRpb24KPiB5b3UgZG8gdGhlIEVLIHZlcmlmaWNhdGlvbiBvZiB0aGUgQUsgKmJlZm9y ZSogdGhlIHF1b3RlLCBidXQgdGhlcmUncyBubwo+IHByb3BlcnR5IG9mIHRoZSBxdW90ZSB0aGF0 IGRlcGVuZHMgb24gdGhpcyBwcmVjZWRlbmNlIHByb3ZpZGVkIHlvdSBkbwo+IHRoZSBxdW90ZSB3 aXRoIGEgVFBNIGdlbmVyYXRlZCBzaWduaW5nIGtleS4KWWVzLgoKPiAKPiBUaGUgdW5kZXJseWlu ZyBwb2ludCBpcyB0aGF0IHRoZSB1c3VhbCB3YXkgYW4gRUsgdmVyaWZpZXMgYW4gQUsKPiByZXF1 aXJlcyBhIHJlbW90ZSBvYnNlcnZlciwgd2hpY2ggdGhlIGtlcm5lbCB3b24ndCBoYXZlLCBzbyB0 aGUga2VybmVsCkFncmVlZC4KCj4gbXVzdCBkbyBhbGwgaXRzIHN0dWZmIGxvY2FsbHkgKGdlbmVy YXRlIGtleSwgZ2V0IHF1b3RlKSBhbmQgdGhlbiBhdApJIGJlbGlldmUgdGhlIEtlcm5lbCBkb2Vz buKAmXQgaGF2ZSB0byBnZW5lcmF0ZSBrZXkgd2hpbGUKdGFraW5nIHRoZSBzbmFwc2hvdC4gSW4g dGhlIGN1cnJlbnQgcHJvcG9zYWwsIEtlcm5lbCBjYW4gc2ltcGx5IGdldAp0aGUgKHVuc2lnbmVk KSBQQ1IgcXVvdGUgYW5kIGxvZyBpdCBpbiBJTUEgbG9nIGFzIHBhcnQgb2YgdGhlCnNuYXBzaG90 X2FnZ3JlZ2F0ZSBldmVudC4gV2UgZG9u4oCZdCBuZWVkIHRvIHNpZ24gdGhlIHF1b3RlIHdoaWxl CmxvZ2dpbmcgaXQgaW4gdGhlIElNQSBsb2cgYXMgc25hcHNob3RfYWdncmVnYXRlLiBBbmQgdGhl IGFjdCBvZgpsb2dnaW5nIHRoYXQgZXZlbnQgaW4gSU1BIGxvZyBleHRlbmRzIHRoZSBQQ1IgYmFu ay4gU29tZXRpbWUgbGF0ZXIsCndoZW4gYSByZW1vdGUgb2JzZXJ2ZXIgd2FudHMgdG8gdmFsaWRh dGUgdGhlIGxvZyDigJMgaXQgY2FuIGRvIGl0IGJ5CmNvbXBhcmluZyBhZ2FpbnN0IHRoZSBQQ1Ig cXVvdGUgdGhhdCB3YXMgc2lnbmVkIGF0IHRoYXQgcG9pbnQuCgo+IHNvbWUgcG9pbnQgbGF0ZXIg dGhlIHN5c3RlbSBjYW4gYmVjb21lIHJlbW90ZSBjb25uZWN0ZWQgYW5kIHByb3ZlIHRvCj4gd2hh dGV2ZXIgZXh0ZXJuYWwgZW50aXR5IHRoYXQgdGhlIGxvZyBzaGFyZCBpcyB2YWxpZC4gIFNvIHdl IGhhdmUgdG8KPiBoYXZlIGFsbCB0aGUgY29tcG9uZW50cyBuZWNlc3NhcnkgZm9yIHRoYXQgcHJv b2Y6IHRoZSBsb2cgc2hhcmQsIHRoZQo+IHF1b3RlIGFuZCB0aGUgVFBNIGZvcm0gb2YgdGhlIEFL Lgo+IAo+PiBGb3IgaW5zdGFuY2UsIFBDUiBxdW90ZXMgd2lsbCBiZSBzaWduZWQgYnkgQUsuIFNv IGFzIGxvbmcgYXMgdGhlCj4+IHZlcmlmaWVyIHRydXN0cyB0aGUgQUsvRUssCj4gCj4gUmlnaHQs IGJ1dCBpZiB5b3UncmUgc2hhcmRpbmcgYSBsb2csIHRoZSBrZXJuZWwgZG9lc24ndCBrbm93IGlm IGEKPiB2ZXJpZmllciBoYXMgYmVlbiBpbiBjb250YWN0IHlldC4gIFRoZSBwb2ludCBvZiB0aGUg cHJvdG9jb2wgYWJvdmUgaXMKPiB0byBtYWtlIHRoYXQgbm90IG1hdHRlci4gIFRoZSB2ZXJpZmll ciBjYW4gY29udGFjdCB0aGUgc3lzdGVtIGFmdGVyIHRoZQo+IGxvZyBoYXMgYmVlbiBzYXZlZCBh bmQgdGhlIHZlcmlmaWNhdGlvbiB3aWxsIHN0aWxsIHdvcmsuCj4gClRoZSBLZXJuZWwgZG9lc27i gJl0IG5lZWQgdG8ga25vdy4gQW5kIGl0IHN0aWxsIGRvZXNu4oCZdCBtYXR0ZXIuClRoZSBiZW5l Zml0IG9mIG91ciBhcHByb2FjaCBpcyB0aGUgUENSIHZhbHVlcyB0aGF0IHJlcHJlc2VudCB0aGUK cHJldmlvdXMgc25hcHNob3Qoc2hhcmQpIGlzIG5vdyBsb2dnZWQgaW4gdGhlIElNQSBsb2cgYXMK c25hcHNob3RfYWdncmVnYXRlLCBhbmQgdGhlIFBDUnMgYXJlIGV4dGVuZGVkIGFnYWluIGFzIHBh cnQgb2YKbG9nZ2luZyB0aGF0IGV2ZW50IGluIElNQSBsb2cuCgo+PiAgIGl0IGNhbiB2ZXJpZnkg dGhlIHF1b3RlcyBhcmUgbm90IHRhbXBlcmVkIHdpdGguCj4+IFJlcGxheWluZyBJTUEgbG9nL3Nu YXBzaG90IGNhbiBwcm9kdWNlIHRoZSBQQ1IgcXVvdGVzIHdoaWNoIGNhbiBiZQo+PiBtYXRjaGVk IHdpdGggc2lnbmVkIFBDUiBxdW90ZXMuIElmIHRoZXkgbWF0Y2gsIHRoZW4gdGhlIHZlcmlmaWVy IGNhbgo+PiBjb25jbHVkZSB0aGF0IHRoZSBJTUEgbG9nIGlzIG5vdCB0YW1wZXJlZCB3aXRoLiBT byBBSyBkb2Vzbid0IG5lZWQgdG8KPj4gYmUgcGFydCBvZiB0aGUgbG9nL3NuYXBzaG90Lgo+IAo+ IE9ubHkgaWYgdGhlIHN5c3RlbSBpcyBjdXJyZW50bHkgaW4gY29udGFjdCB3aXRoIHRoZSB2ZXJp ZmllciBhbmQgdGhlCj4gdmVyaWZpZXIgaGFzIGNyZWF0ZWQgdGhlIEFLLiAgVGhhdCBtYXkgbm90 IGhhdmUgaGFwcGVuZWQuCj4gCkhvcGUgbXkgYWJvdmUgZXhwbGFuYXRpb24gYWRkcmVzc2VzIHRo aXMgcG9pbnQuCgo+PiBCVFcsIGluIHRoaXMgcHJvcG9zYWwsIGtlcm5lbCBpcyB0cnVuY2F0aW5n IHRoZSBsb2cgYW5kIHBhc3NpbmcgdGhlCj4+IHRydW5jYXRlZCBidWZmZXIgdG8gVU0uwqAgVU0g Y2xpZW50IG5lZWQgdG8gc2F2ZSBpdCB0byB0aGUgZGlzawo+PiBsb2NhdGlvbiBvZiBpdCdzIGNo b2ljZS4KPiAKPiBZZXMsIGJ1dCBJIHdhcyBhc3N1bWluZyB0YW1wZXJpbmcgd2l0aCBvciBkaXNj YXJkaW5nIHRoZSBsb2cgZmlsZSB3b3VsZAo+IGJlIHRyZWF0ZWQgaW4gZXhhY3RseSB0aGUgc2Ft ZSB3YXkgYXMgYW4gaW4ta2VybmVsIElNQSBsb2cgdGFtcGVyLgo+IApIb3BlIG15IGFib3ZlIGV4 cGxhbmF0aW9uIGFkZHJlc3NlcyB0aGlzIHBvaW50LgoKflR1c2hhcgoKPiBKYW1lcwoKX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Ka2V4ZWMgbWFpbGluZyBs aXN0CmtleGVjQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcv bWFpbG1hbi9saXN0aW5mby9rZXhlYwo= 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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7A085C04A94 for ; Fri, 11 Aug 2023 15:48:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233612AbjHKPsk (ORCPT ); Fri, 11 Aug 2023 11:48:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35818 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235982AbjHKPs1 (ORCPT ); Fri, 11 Aug 2023 11:48:27 -0400 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id A21DF211C; Fri, 11 Aug 2023 08:48:26 -0700 (PDT) Received: from [192.168.87.33] (c-98-237-170-177.hsd1.wa.comcast.net [98.237.170.177]) by linux.microsoft.com (Postfix) with ESMTPSA id 7D7F220FD0C5; Fri, 11 Aug 2023 08:48:25 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 7D7F220FD0C5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1691768906; bh=UKEi7WJXl5hJdjwWxrw5NDZOvUTxztWU9msXupBAioE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=A6+wUIIfI7qkrBchbUMDtIOLwpRi462atJwsAdwPMskRKIouLHmAuAFQcqqhKe3sw IbTJPMBTNn74Wx7KMNU/BJFuXsumZex+1WQ8TVvGWSYxeC66PQXxRyC7/3THmzbYtN ShK5qUuuLyTQk6zoKUh8SAI5FmkRRZXid70JmORs= Message-ID: <72e39852-1ff1-c7f6-ac7e-593e8142dbe8@linux.microsoft.com> Date: Fri, 11 Aug 2023 08:48:25 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [RFC] IMA Log Snapshotting Design Proposal Content-Language: en-US To: James Bottomley , Stefan Berger , Sush Shringarputale , linux-integrity@vger.kernel.org, zohar@linux.ibm.com, peterhuewe@gmx.de, jarkko@kernel.org, jgg@ziepe.ca, kgold@linux.ibm.com, bhe@redhat.com, vgoyal@redhat.com, dyoung@redhat.com, kexec@lists.infradead.org, jmorris@namei.org, Paul Moore , serge@hallyn.com Cc: code@tyhicks.com, nramas@linux.microsoft.com, linux-security-module@vger.kernel.org References: <5d21276a-daac-fc9b-add9-62e7c04bbdcd@linux.ibm.com> <8ad131f35c33cf10788344be6c981473971f9c1c.camel@HansenPartnership.com> <350ecdcbf7796f488807fcd7983414a02dd71be4.camel@HansenPartnership.com> <04fb2fe5-9ebe-b35f-bdde-6ef22786438f@linux.ibm.com> <5cb03349-7a32-8f74-f2a1-ff3c6247c1ef@linux.microsoft.com> <8ccaec30bf85cfbf4415bbafa22646a62e753840.camel@HansenPartnership.com> From: Tushar Sugandhi In-Reply-To: <8ccaec30bf85cfbf4415bbafa22646a62e753840.camel@HansenPartnership.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-integrity@vger.kernel.org On 8/10/23 04:43, James Bottomley wrote: > On Wed, 2023-08-09 at 21:43 -0700, Tushar Sugandhi wrote: >> On 8/8/23 14:41, James Bottomley wrote: >>> On Tue, 2023-08-08 at 16:09 -0400, Stefan Berger wrote: > [...] >>>>   at this point doesn't seem necessary since one presumably can >>>> verify the log and PCR states at the end with the 'regular' >>>> quote. >>> >>> I don't understand this.  A regular quote is a signature over PCR >>> state by an AK.  The point about saving the AK in the log for the >>> original is that if the *kernel* truncates the log and saves it to >>> a file, it needs to generate both the AK and the quote for the top >>> of the file shard. That means the AK/EK binding is unverified, but >>> can be verified by loading the AK and running the usual tests, >>> which can only be done if you have the loadable AK, which is why >>> you need it as part of the log saving proposal. >> >> I had this question about the usability of AK/EK in this >> context. Although AK/EK + PCR quote is needed to verify the snapshot >> shards / IMA logs are not tampered with, I am still not sure why >> AK/EK needs to be part of the shard/IMA log. The client sending AK/EK >> to attestation service separately would still serve the purpose, >> right? > > Well, the EK doesn't need to be part of the log: it's just a permanent > part of the TPM identity. To verify the log, you need access to the > TPM that was used to create it, so that's the point at which you get > the EK. > Agreed. EK is part of TPM identity. But to verify the log, you don’t need to have physical access to the TPM. You need to have access to just public part of EK and AK/AIK certs (TPM on the system would sign the quote using the private AK). I believe you already know this, just stating for the sake of completing the conversation. :) > An AK is simply a TPM generated signing key (meaning the private part > of the key is secured by the TPM and known to no-one else). In the > literature a TPM generated signing key doesn't become an Attestation > Key until it's been verified using an EK property (either a certify for > a signing EK or a make/activate credential round trip for the more > usual encryption EK. > Yes. That aligns with my understanding of EK/AK in general. Thanks for describing. > So the proposal is for each quote that's used to verify a log shard is > that the TPM simply generate a random signing key and use that to sign I believe you are suggesting creating a new AK each time you want to sign a PCR quote. It is doable in TPM 2.0, and it provides benefits like privacy and untraceability. But it comes with it’s own costs – cost of generating new AK each time you want to sign, maintaining mapping of AK and it’s signed quotes, maintaining multiple public AK certs etc. > the quote. You need to save the TPM form of the generated key so it > can be loaded later and the reason for that is you can do the EK > verification at any time after the quote was given by loading the saved > key and running the verification protocol. In the normal attestation > you do the EK verification of the AK *before* the quote, but there's no > property of the quote that depends on this precedence provided you do > the quote with a TPM generated signing key. Yes. > > The underlying point is that the usual way an EK verifies an AK > requires a remote observer, which the kernel won't have, so the kernel Agreed. > must do all its stuff locally (generate key, get quote) and then at I believe the Kernel doesn’t have to generate key while taking the snapshot. In the current proposal, Kernel can simply get the (unsigned) PCR quote and log it in IMA log as part of the snapshot_aggregate event. We don’t need to sign the quote while logging it in the IMA log as snapshot_aggregate. And the act of logging that event in IMA log extends the PCR bank. Sometime later, when a remote observer wants to validate the log – it can do it by comparing against the PCR quote that was signed at that point. > some point later the system can become remote connected and prove to > whatever external entity that the log shard is valid. So we have to > have all the components necessary for that proof: the log shard, the > quote and the TPM form of the AK. > >> For instance, PCR quotes will be signed by AK. So as long as the >> verifier trusts the AK/EK, > > Right, but if you're sharding a log, the kernel doesn't know if a > verifier has been in contact yet. The point of the protocol above is > to make that not matter. The verifier can contact the system after the > log has been saved and the verification will still work. > The Kernel doesn’t need to know. And it still doesn’t matter. The benefit of our approach is the PCR values that represent the previous snapshot(shard) is now logged in the IMA log as snapshot_aggregate, and the PCRs are extended again as part of logging that event in IMA log. >> it can verify the quotes are not tampered with. >> Replaying IMA log/snapshot can produce the PCR quotes which can be >> matched with signed PCR quotes. If they match, then the verifier can >> conclude that the IMA log is not tampered with. So AK doesn't need to >> be part of the log/snapshot. > > Only if the system is currently in contact with the verifier and the > verifier has created the AK. That may not have happened. > Hope my above explanation addresses this point. >> BTW, in this proposal, kernel is truncating the log and passing the >> truncated buffer to UM.  UM client need to save it to the disk >> location of it's choice. > > Yes, but I was assuming tampering with or discarding the log file would > be treated in exactly the same way as an in-kernel IMA log tamper. > Hope my above explanation addresses this point. ~Tushar > James