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 7319EC001DE for ; Fri, 11 Aug 2023 15:57:32 +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=WYXRv9UOcABIoSHsAaVzsKQdfFNSa3BLrY3DTXCEk5I=; b=tWOSs+EN+UkiAj uxGEYLGs1nHNPIBjAWE7rQ3SBe2C3uniyYnkgdCDs/fiW4/BDCbLx/Z+fkdP95AE/O74s+tIjpiCW zmBlo4m/05iqluqIhHSBJacDcCbGZwAERPkoYaBgF3fvYylYTcIQ7LEv8paCmMFuZqxb4m/mh+tVs TaHiRbKGfIdpWkBYIvXbX5W+GUkl5058a6CXA4SQ4yWjvuUyqtcbzR88ngPtR+ZbDxLnMuG4OFURG ruKZOtqBVvl33ZIhPJpRvFlWfXXq0U+CA6N+/IXesrHX6T+odtWuv6T+6JbnZZ173Qf0TaySYbNct 4IJA+lmbJHlDR9Myotgw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qUUW2-00B15Q-0f; Fri, 11 Aug 2023 15:57:30 +0000 Received: from linux.microsoft.com ([13.77.154.182]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qUUVy-00B14u-2d for kexec@lists.infradead.org; Fri, 11 Aug 2023 15:57: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 3EFB920FD0DE; Fri, 11 Aug 2023 08:57:25 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 3EFB920FD0DE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1691769445; bh=zdTZE46AC8XAcWdlVWP+KP3ZBU6mAfYi7siVLldLQyw=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=k4AlgKxEQE0nNZShm8hOi8/E5PIJILFlXh+hf+CccgFQjV2xJTIsKJU07QmBmptnX KoFCnVY3j4FyACoWuL/HkFeMBTj3lTgipUG26Pcd2V6XwxH8+DpYvIlYqm0H31cmc2 5ab1jqMuReitE2mAt29x9TM1e9QmFkjRFhMcBwUI= Message-ID: Date: Fri, 11 Aug 2023 08:57:24 -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: Stefan Berger , James Bottomley , 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> <011d8a79-236f-dc20-08fc-b5da7dd1d5a7@linux.ibm.com> From: Tushar Sugandhi In-Reply-To: <011d8a79-236f-dc20-08fc-b5da7dd1d5a7@linux.ibm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230811_085726_919857_A7F3D658 X-CRM114-Status: GOOD ( 66.52 ) 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 CgpPbiA4LzEwLzIzIDA3OjEyLCBTdGVmYW4gQmVyZ2VyIHdyb3RlOgo+IAo+IAo+IE9uIDgvOS8y MyAyMToxNSwgVHVzaGFyIFN1Z2FuZGhpIHdyb3RlOgo+PiBUaGFua3MgYSBsb3QgU3RlZmFuIGZv ciBsb29raW5nIGludG8gdGhpcyBwcm9wb3NhbCwKPj4gYW5kIHByb3ZpZGluZyB5b3VyIGZlZWRi YWNrLiBXZSByZWFsbHkgYXBwcmVjaWF0ZSBpdC4KPj4KPj4gT24gOC83LzIzIDE1OjQ5LCBTdGVm YW4gQmVyZ2VyIHdyb3RlOgo+Pj4KPj4+Cj4+PiBPbiA4LzEvMjMgMTc6MjEsIEphbWVzIEJvdHRv bWxleSB3cm90ZToKPj4+PiBPbiBUdWUsIDIwMjMtMDgtMDEgYXQgMTI6MTIgLTA3MDAsIFN1c2gg U2hyaW5nYXJwdXRhbGUgd3JvdGU6Cj4+Pj4gWy4uLl0KPj4+Pj4gVHJ1bmNhdGluZyBJTUEgbG9n IHRvIHJlY2xhaW0gbWVtb3J5IGlzIG5vdCBmZWFzaWJsZSwgc2luY2UgaXQgbWFrZXMKPj4+Pj4g dGhlIGxvZyBnbyBvdXQgb2Ygc3luYyB3aXRoIHRoZSBUUE0gUENSIHF1b3RlIG1ha2luZyByZW1v dGUKPj4+Pj4gYXR0ZXN0YXRpb24gZmFpbC4KPj4+Pgo+Pj4+IFRoaXMgYXNzdW1wdGlvbiBpc24n dCBlbnRpcmVseSB0cnVlLsKgIEl0J3MgcGVyZmVjdGx5IHBvc3NpYmxlIHRvIHNoYXJkCj4+Pj4g YW4gSU1BIGxvZyB1c2luZyB0d28gVFBNMl9RdW90ZSdzIGZvciB0aGUgYmVnaW5uaW5nIGFuZCBl bmQgUENSIHZhbHVlcwo+Pj4+IHRvIHZhbGlkYXRlIHRoZSBzaGFyZC7CoCBUaGUgSU1BIGxvZyBj b3VsZCBiZSB0cnVuY2F0ZWQgaW4gdGhlIHNhbWUgd2F5Cj4+Pj4gKHJlcGxhY2UgdGhlIHJlbW92 ZWQgcGFydCBvZiB0aGUgbG9nIHdpdGggYSBUUE0yX1F1b3RlIGFuZCBBSywgc28gdGhlCj4+Pj4g bG9nIHN0aWxsIHZhbGlkYXRlcyBmcm9tIHRoZSBiZWdpbm5pbmcgcXVvdGUgdG8gdGhlIGVuZCku Cj4+Pj4KPj4+PiBJZiB5b3UgdXNlIGEgVFBNMl9RdW90ZSBtZWNoYW5pc20gdG8gc2F2ZSB0aGUg bG9nLCBhbGwgeW91IG5lZWQgdG8gZG8KPj4+PiBpcyBoYXZlIHRoZSBrZXJuZWwgZ2VuZXJhdGUg dGhlIHF1b3RlIHdpdGggYW4gaW50ZXJuYWwgQUsuwqAgWW91IGNhbgo+Pj4+IGtlZXAgYSByZWNv cmQgb2YgdGhlIHF1b3RlIGFuZCB0aGUgQUsgYXQgdGhlIGJlZ2lubmluZyBvZiB0aGUgdHJ1bmNh dGVkCj4+Pj4ga2VybmVsIGxvZy7CoCBJZiB0aGUgdHJ1bmNhdGVkIGVudHJpZXMgYXJlIHNhdmVk IGluIGEgZmlsZSBzaGFyZCBpdAo+Pj4KPj4+IFRoZSB0cnVuY2F0aW9uIHNlZW1zIGRhbmdlcm91 cyB0byBtZS4gTWF5YmUgbm90IGFsbCB0aGUgc2NlbmFyaW9zIAo+Pj4gd2l0aCBhbiBhdHRlc3Rh dGlvbgo+Pj4gY2xpZW50IChjbGllbnQgPSByZWFkaW5nIGxvZ3MgYW5kIHF1b3RpbmcpIGFyZSBw b3NzaWJsZSB0aGVuIGFueW1vcmUsIAo+Pj4gc3VjaCBhcyBzdGFydGluZwo+Pj4gYW4gYXR0ZXN0 YXRpb24gY2xpZW50IG9ubHkgYWZ0ZXIgdHJ1bmNhdGlvbiBidXQgYSB2ZXJpZmllciBtdXN0IGhh dmUgCj4+PiB3aXRuZXNzZWQgdGhlCj4+PiBzeXN0ZW0ncyBQQ1JzIGFuZCBsb2cgc3RhdGUgYmVm b3JlIHRoZSB0cnVuY2F0aW9uIG9jY3VycmVkLgo+PiBZb3UgYXJlIGNvcnJlY3QgdGhhdCB0cnVu Y2F0aW9uIG9uIGl04oCZcyBvd24gaXMgZGFuZ2Vyb3VzLiBJdCBuZWVkcyB0byBiZQo+PiBhY2Nv bXBhbmllZCBieSAoYSkgc2F2aW5nIHRoZSBJTUEgbG9nIGRhdGEgdG8gZGlzayBhcyBzbmFwc2hv dHMsIChiKSAKPj4gYWRkaW5nIHRoZQo+PiBuZWNlc3NhcnkgVFBNIFBDUiBxdW90ZXMgdG8gdGhl IGN1cnJlbnQgSU1BIGxvZyAoYXMgSmFtZXMgbWVudGlvbmVkIAo+PiBhYm92ZSksCj4+IChjKSBh dHRlc3RhdGlvbiBjbGllbnRzIGhhdmluZyBhbiBhYmlsaXR5IHRvIHNlbmQgdGhlIHBhc3Qgc25h cHNob3RzIAo+PiB0byB0aGUKPj4gcmVtb3RlLWF0dGVzdGF0aW9uLXNlcnZpY2UgKHZlcmlmaWVy cyksIChkKSBhbmQgdmVyaWZpZXJzIGhhdmluZyBhbiAKPj4gYWJpbGl0eQo+PiB0byB1c2UgdGhl IHNuYXBzaG90cyBhbG9uZyB3aXRoIGN1cnJlbnQgSU1BIGxvZ3MgZm9yIHRoZSBwdXJwb3NlIG9m IAo+PiBhdHRlc3RhdGlvbi4KPj4gQWxsIHRoZXNlIHBvaW50cyBhcmUgZXhwbGFpbmVkIGluIHRo ZSBvcmlnaW5hbCBSRkMgZW1haWwgaW4gc2VjdGlvbnMgCj4+IEIuMSB0aHJvdWdoIEIuNSBbMV0u Cj4gCj4gSSByZWFkIGl0Lgo+IAo+IE1heWJlIHlvdSBoYXZlIGRpc21pc3NlZCB0aGUgUENSIHVw ZGF0ZSBjb3VudGVyIGFscmVhZHkuLi4KPiBJIGFtIG5vdCBzdXJlIHdoYXQgdGhlIFBDUiB1cGRh dGUgY291bnRlciBpcyBzdXBwb3NlZCB0byBoZWxwIHdpdGguIEl0IAo+IHdvbid0IGFsbG93IHlv dSB0byBkZXRlY3QKPiBtaXNzaW5nIGxvZyBldmVudHMgYnV0IHJhdGhlciB3aWxsIGNvbmZ1c2Ug YW55b25lIGxvb2tpbmcgYXQgaXQgd2hlbiBteSAKPiBhcHBsaWNhdGlvbiBleHRlbmRzIFBDUiAx Mgo+IGZvciBleGFtcGxlLCB3aGljaCBhbHNvIGFmZmVjdHMgdGhlIHVwZGF0ZSBjb3VudGVyLiBJ dCdzIGEgZ2xvYmFsIAo+IGNvdW50ZXIgdGhhdCBpbmNyZWFzZXMgd2l0aCBldmVyeQo+IFBDUiBl eHRlbnNpb24gKGV4Y2VwdCBQQ1IgMTYsIDIxLCAyMiwgMjMpIGFuZCBpZiB1c2VkIGFzIHByb3Bv c2VkIHdvdWxkIAo+IHByZXZlbnQgYW55IGFwcGxpY2F0aW9uIGZyb20KPiBleHRlbmRpbmcgUENS cy4KPiAKPiBodHRwczovL2dpdGh1Yi5jb20vc3RlZmFuYmVyZ2VyL2xpYnRwbXMvYmxvYi9tYXN0 ZXIvc3JjL3RwbTIvUENSLmMjTDY2Nwo+IGh0dHBzOi8vZ2l0aHViLmNvbS9zdGVmYW5iZXJnZXIv bGlidHBtcy9ibG9iL21hc3Rlci9zcmMvdHBtMi9QQ1IuYyNMNjI5Cj4gaHR0cHM6Ly9naXRodWIu Y29tL3N0ZWZhbmJlcmdlci9saWJ0cG1zL2Jsb2IvbWFzdGVyL3NyYy90cG0yL1BDUi5jI0wxNjEK PiAKPiAKQWdyZWUgd2l0aCB5b3VyIHBvaW50IGFib3V0IFRQTSBQQ1IgdXBkYXRlIGNvdW50ZXIg U3RlZmFuLgpJIHdpbGwgYnJpbmcgaXQgdXAgaW4gdGhlIHVwZGF0ZSBjb3VudGVyIHBhdGNoIHNl cmllcyBkaXNjdXNzaW9uIFsxXS4KClsxXSAKaHR0cHM6Ly9wYXRjaHdvcmsua2VybmVsLm9yZy9w cm9qZWN0L2xpbnV4LWludGVncml0eS9jb3Zlci8yMDIzMDgwMTE4MTkxNy44NTM1LTEtdHVzaGFy c3VAbGludXgubWljcm9zb2Z0LmNvbS8gCgoKPiBUaGUgc2hhcmRzIHNob3VsZCB3aWxsIG5lZWQg dG8gYmUgd3JpdHRlbiBpbnRvIHNvbWUgc29ydCBvZiBzdGFuZGFyZCAKPiBsb2NhdGlvbiBvciBh IGNvbmZpZyBmaWxlIG5lZWRzIHRvCj4gYmUgZGVmaW5lZCwgc28gdGhhdCBldmVyeW9uZSBrbm93 cyB3aGVyZSB0byBmaW5kIHRoZW0gYW5kIGhvdyB0aGV5IGFyZSAKPiBuYW1lZC4KPiAKV2UgdGhv dWdodCBhYm91dCB3ZWxsIGtub3duIHN0YW5kYXJkIGxvY2F0aW9uIGVhcmxpZXIuCkxldHRpbmcg dGhlIEtlcm5lbCBjaG9vc2UgdGhlIG5hbWUvbG9jYXRpb24gb2YgdGhlIHNuYXBzaG90CmZpbGUg Y29tZXMgd2l0aCBpdHMgb3duIGNvbXBsZXhpdHkuIE91ciBpbml0aWFsIHN0YW5jZSBpcyB3ZSBk b27igJl0CndhbnQgdG8gaGFuZGxlIHRoYXQgYXQgS2VybmVsIGxldmVsLCBhbmQgbGV0IHRoZSBV TSBjbGllbnQgY2hvb3NlCnRoZSBsb2NhdGlvbi9uYW1pbmcgb2YgdGhlIHNuYXBzaG90IGZpbGVz LiBCdXQgd2UgYXJlIGhhcHB5IHRvCnJlY29uc2lkZXIgaWYgdGhlIGNvbW11bml0eSByZXF1ZXN0 cyBpdC4KPiAKPj4+Cj4+PiBJIHRoaW5rIGFuIGltYS1idWYgKG9yIHNpbWlsYXIpIGxvZyBlbnRy eSBpbiBJTUEgbG9nIHdvdWxkIGhhdmUgdG8gCj4+PiBhcHBlYXIgYXQgdGhlIGJlZ2lubmluZyBv ZiB0aGUKPj4+IHRydW5jYXRlZCBsb2cgc3RhdGluZyB0aGUgdmFsdWUgb2YgYWxsIFBDUnMgdGhh dCBJTUEgdG91Y2hlZCAKPj4+ICh0eXBpY2FsbHkgb25seSBQQ1IgMTAKPj4+IGJ1dCBpdCBjYW4g YmUgb3RoZXJzKS4gVGhlIG5lZWRzIHRvIGJlIGRvbmUgc2luY2UgdGhlIHF1b3RlIGl0c2VsZiAK Pj4+IGRvZXNuJ3QKPj4+IHByb3ZpZGUgdGhlIHN0YXRlIG9mIHRoZSBpbmRpdmlkdWFsIFBDUnMu IFRoaXMgd291bGQgYXQgbGVhc3QgYWxsb3cgCj4+PiBhbiBhdHRlc3RhdGlvbgo+Pj4gY2xpZW50 IHRvIHJlLXJlYWQgdGhlIGxvZyBmcm9tIHRoZSBiZWdpbm5pbmcgKHdoZW4gaXQgaXMgcmUtc3Rh cnQgb3IgCj4+PiBzdGFydGVkIGZvciB0aGUKPj4+IGZpcnN0IHRpbWUgYWZ0ZXIgdGhlIHRydW5j YXRpb24pLiAKPj4gwqDCoEFncmVlZC4gU2VlIHRoZSBkZXNjcmlwdGlvbiBvZiBzbmFwc2hvdF9h Z2dyZWdhdGUgaW4gU2VjdGlvbiBCLjUgaW4gdGhlCj4+IG9yaWdpbmFsIFJGQyBlbWFpbCBbMV0u Cj4+PiBIb3dldmVyLCB0aGlzIGFsb25lICh3aXRob3V0IHRoZQo+Pj4gaW50ZXJuYWwgQUsgcXVv dGluZyB0aGUgb2xkIHN0YXRlKSBjb3VsZCBsZWFkIHRvIGFidXNlIHdoZXJlIEkgY291bGQgCj4+ PiBjcmVhdGUgdG90YWxseQo+Pj4gZmFrZSBJTUEgbG9ncyBzdGF0aW5nIHRoZSBzdGF0ZSBvZiB0 aGUgUENScyBhdCB0aGUgYmVnaW5uaW5nIChzbyB0aGUgCj4+PiB2ZXJpZmllcgo+Pj4gc3luY3Mg aXRzIGludGVybmFsIFBDUiBzdGF0ZSB0byB0aGlzIHN0YXRlKS4gCj4+IFllcywgdGhlIFBDUiBx dW90ZXMgc2VudCB0byB0aGUgdmVyaWZpZXIgbXVzdCBiZSBzaWduZWQgYnkgdGhlIEFLIHRoYXQK Pj4gaXMgdHJ1c3RlZCBieSB0aGUgdmVyaWZpZXIuIFRoYXQgYXNzdW1wdGlvbiBpcyB0cnVlIHJl Z2FyZGxlc3Mgb2YgSU1BIGxvZwo+PiBzbmFwc2hvdHRpbmcgZmVhdHVyZS4KPj4+IEZ1cnRoZXIs IGV2ZW4gd2l0aCB0aGUgQUstcXVvdGUgdGhhdAo+Pj4geW91IHByb3Bvc2UgSSBtYXkgYmUgYWJs ZSB0byBjcmVhdGUgZmFrZSBsb2dzIGFuZCB0cmljayBhIHZlcmlmaWVyIGludG8KPj4+IHRydXN0 aW5nIHRoZSBtYWNoaW5lIElGRiBpdCBkb2Vzbid0IGtub3cgd2hhdCBrZXJuZWwgdGhpcyBzeXN0 ZW0gd2FzIAo+Pj4gYm9vdGVkIHdpdGgKPj4+IHRoYXQgSSBtYXkgaGF2ZSBoYWNrZWQgdG8gcHJv dmlkZSBhIGZha2UgQUstcXVvdGUgdGhhdCBqdXN0IGhhcHBlbnMgCj4+PiB0byBtYXRjaCB0aGUK Pj4+IFBDUiBzdGF0ZSBwcmVzZW50ZWQgYXQgdGhlIGJlZ2lubmluZyBvZiB0aGUgbG9nLgo+Pj4K Pj4gSWYgdGhlIEtlcm5lbCBpcyBjb21wcm9taXNlZCwgdGhlbiBhbGwtYmV0cyBhcmUgb2ZmLgo+ PiAoUmVnYXJkbGVzcyBvZiBJTUEgbG9nIHNuYXBzaG90dGluZyBmZWF0dXJlLikKPj4+ID0+IENh biBhIHRydW5jYXRlZCBsb2cgYmUgbWFkZSBzYWZlIGZvciBhdHRlc3RhdGlvbiB3aGVuIHRoZSAK Pj4+IGF0dGVzdGF0aW9uIHN0YXJ0cwo+Pj4gb25seSBhZnRlciB0aGUgdHJ1bmNhdGlvbiBvY2N1 cnJlZD8KPj4+Cj4+IFllcy4gSWYgdGhlIOKAnFBDUiBxdW90ZXMgaW4gdGhlIHNuYXBzaG90X2Fn Z3JlZ2F0ZSBldmVudCBpbiBJTUEgbG9n4oCdCj4gCj4gUENSIHF1b3RlIG9yICdxdW90ZXMnPyBX aHkgbXVsdGlwbGU/Cj4gCj4gRm9ybSB5b3VyIHByb3Bvc2FsIGJ1dCB5b3UgbWF5IGhhdmUgY2hh bmdlZCB5b3VyIG9waW5pb27CoCBmb2xsb3dpbmcgd2hhdCAKPiBJIHNlZSBpbiBvdGhlciBtZXNz YWdlczoKPiAiLSBUaGUgS2VybmVsIHdpbGwgZ2V0IHRoZSBjdXJyZW50IFRQTSBQQ1IgdmFsdWVz IGFuZCBQQ1IgdXBkYXRlIGNvdW50ZXIgCj4gWzJdCj4gIMKgwqAgYW5kIHN0b3JlIHRoZW0gYXMg dGVtcGxhdGUgZGF0YSBpbiBhIG5ldyBJTUEgZXZlbnQgCj4gInNuYXBzaG90X2FnZ3JlZ2F0ZSIu Igo+IAo+IEFmYWlrIFRQTSBxdW90ZSdzIGRvbid0IGdpdmUgeW91IHRoZSBzdGF0ZSBvZiB0aGUg aW5kaXZpZHVhbCBQQ1IgdmFsdWVzLCAKPiB0aGVyZWZvcmUKPiBJIHdvdWxkIGV4cGVjdCB0byBh dCBsZWFzdCBmaW5kIHRoZSAnUENSIHZhbHVlcycgb2YgYWxsIHRoZSBQQ1JzIHRoYXQgCj4gSU1B IHRvdWNoZWQgdG8KPiBiZSBpbiB0aGUgc25hcHNob3RfYWdncmVnYXRlIHNvIEkgY2FuIHJlcGxh eSBhbGwgdGhlIGZvbGxvd2luZyBldmVudHMgb24gCj4gdG9wIG9mIHRoZXNlCj4gUENSIHZhbHVl cyBhbmQgY29tZSB1cCB3aXRoIHRoZSB2YWx1ZXMgdGhhdCB3ZXJlIHVzZWQgaW4gdGhlICJmaW5h bCBQQ1IgCj4gcXVvdGUiLiBUaGlzCj4gaXMgdW5sZXNzIHlvdSBleHBlY3QgdGhlIHNlcnZlciB0 byB0YWtlIGFuIGF1dG9tYXRpYyBzbmFwc2hvdCBvZiB0aGUgCj4gdmFsdWVzIG9mIHRoZQo+IFBD UnPCoCB0aGF0IGl0IGNvbXB1dGVkIHdoaWxlIGV2YWx1YXRpbmcgdGhlIGxvZyBpbiBjYXNlIGl0 IGV2ZXIgbmVlZHMgdG8gCj4gZ28gYmFjay4KPiAKSSBtZWFudCBhIHNpbmdsZSBzZXQgb2YgUENS IHZhbHVlcyBjYXB0dXJlZCB3aGVuIHNuYXBzaG90X2FnZ3JlZ2F0ZQppcyBsb2dnZWQuIFNvcnJ5 IGZvciB0aGUgY29uZnVzaW9uLgoKPj4gKyAicmVwbGF5IG9mIHJlc3Qgb2YgdGhlIGV2ZW50cyBp biBJTUEgbG9nIiByZXN1bHRzIGluIHRoZSDigJxmaW5hbCBQQ1IgCj4+IHF1b3Rlc+KAnQo+PiB0 aGF0IG1hdGNoZXMgd2l0aCB0aGUg4oCcQUsgc2lnbmVkIFBDUiBxdW90ZXPigJ0gc2VudCBieSB0 aGUgY2xpZW50LCB0aGVuIAo+PiB0aGUgdHJ1bmNhdGVkCj4+IElNQSBsb2cgY2FuIGJlIHRydXN0 ZWQuIFRoZSB2ZXJpZmllciBjYW4gZWl0aGVyIOKAmHRydXN04oCZIHRoZSDigJxQQ1IgCj4+IHF1 b3RlcyBpbiB0aGUKPj4gc25hcHNob3RfYWdncmVnYXRlIGV2ZW50IGluIElNQSBsb2figJ0gb3Ig aXQgY2FuIGFzayBmb3IgdGhlIChuLTEpdGggCj4+IHNuYXBzaG90IHNoYXJkCj4+IHRvIGNoZWNr IHRoZSBwYXN0IGV2ZW50cy4KPiAKPiBGb3IgYW55dGhpbmcgcmVnYXJkaW5nIGRldGVybWluaW5n IHRoZSAndHJ1c3R3b3J0aGluZXNzIG9mIGEgc3lzdGVtJyBvbmUgCj4gd291bGQgaGF2ZSB0bwo+ IGJlIGFibGUgdG8gZ28gYmFjayB0byB0aGUgdmVyeSBiZWdpbm5pbmcgb2YgdGhlIGxvZyAqb3Iq IHJlbWVtYmVyIGluIAo+IHdoYXQgc3RhdGUgYQo+IHN5c3RlbSB3YXMgd2hlbiB0aGUgbGF0ZXN0 IHNuYXBzaG90IHdhcyB0YWtlbiBzbyB0aGF0IGlmIGEgcmVzdGFydCAKPiBoYXBwZW5zIGl0IGNh biByZXN1bWUKPiB3aXRoIHRoYXQgYXNzdW1wdGlvbiBhYm91dCBzdGF0ZSBvZiB0cnVzdHdvcnRo aW5lc3MgYW5kIGtub3cgd2hhdCB0aGUgCj4gdmFsdWVzIG9mIHRoZSBQQ1JzCj4gd2VyZSBhdCB0 aGF0IHRpbWUgc28gaXQgY2FuIHJlc3VtZSByZXBsYXlpbmcgdGhlIGxvZyAob3IgdGhlIHNlcnZl ciAKPiB3b3VsZCBnZXQgdGhlc2UKPiB2YWx1ZXMgZnJvbSB0aGUgbG9nKS4KPiAKQ29ycmVjdC4g V2UgaW50ZW5kIHRvIHN1cHBvcnQgdGhlIGFib3ZlLiBJIGhvcGUgb3VyIHByb3Bvc2FsCmRlc2Ny aXB0aW9uIGNhcHR1cmVzIGl0LiBCVFcsIHdoZW4geW91IHNheSDigJhyZXN0YXJ04oCZLCB5b3Ug bWVhbiB0aGUgVU0KcHJvY2VzcyByZXN0YXJ0LCByaWdodD8gQmVjYXVzZSBpbiBjYXNlIG9mIGEg S2VybmVsIHJlc3RhcnQKKGkuZS4gY29sZC1ib290KSB0aGUgcGFzdCBJTUEgbG9nIChhbmQgdGhl IFRQTSBzdGF0ZSkgaXMgbG9zdCwKYW5kIG9sZCBzbmFwc2hvdHMgKGlmIGFueSkgYXJlIHVzZWxl c3MuCgo+IFRoZSBBSyBxdW90ZXMgYnkgdGhlIGtlcm5lbCAod2hpY2ggYWRkcyBhIDJuZCBBSyBr ZXkpIHRoYXQgSmFtZXMgaXMgCj4gcHJvcG9zaW5nCj4gY291bGQgYmUgdXNlZnVsIGlmIHRoZSBl bnRpcmUgbG9nLCBjb25zaXN0aW5nIG9mIG11bHRpcGxlIHNoYXJkcywgaXMgCj4gdmVyeSBsYXJn ZSBhbmQKPiBjYW5ub3QgYmUgdHJhbnNmZXJyZWQgZnJvbSB0aGUgY2xpZW50IHRvIHRoZSBzZXJ2 ZXIgaW4gb25lIGdvIHNvIHRoYXQgCj4gdGhlIHNlcnZlciBjb3VsZAo+IGV2YWx1YXRlIHRoZSAn ZmluYWwgUENSIHF1b3RlJyBpbW1lZGlhdGVseSAuIEhvd2V2ZXIsIGlmIGEgY2xpZW50IGNhbiAK PiBpbmRpY2F0ZWQgJ0kgd2lsbAo+IHNlbmQgbW9yZSB0aGUgbmV4dCB0aW1lIGFuZCBJIGhhdmUg dGhpcyBtdWNoIG1vcmUgdG8gdHJhbnNmZXInIGFuZCB0aGUgCj4gc2VydmVyIGFsbG93cwo+IHRo aXMgbXVsdGlwbGUgdGltZXMgKHVudGlsIGFsbCB0aGUgMU1CIHNoYXJkcyBvZiB0aGUgMjBNQiBs b2cgYXJlIAo+IHRyYW5zZmVycmVkKSB0aGVuIHRoYXQKPiBrZXJuZWwgQUsga2V5IHdvdWxkIG5v dCBiZSBuZWNlc3Nhcnkgc2luY2UgcHJlc3VtYWJseSB0aGUgImZpbmFsIFBDUiAKPiBxdW90ZSIs IGNyZWF0ZWQKPiBieSBhIHVzZXIgc3BhY2UgY2xpZW50LCB3b3VsZCByZXNvbHZlIHdoZXRoZXIg dGhlIGVudGlyZSBsb2cgaXMgCj4gdHJ1c3R3b3J0aHkuCj4gClNlZSBteSByZXNwb25zZXMgdG8g SmFtZXMgdG9kYXkgWzJdCgpbMl0gCmh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL2FsbC83MmUzOTg1 Mi0xZmYxLWM3ZjYtYWM3ZS01OTNlODE0MmRiZThAbGludXgubWljcm9zb2Z0LmNvbS8KPj4KPj4+ ID0+IEV2ZW4gaWYgYXR0ZXN0YXRpb24gd2FzIG9jY3VycmluZyAnd2hhdCcgc3RhdGUgZG9lcyBh biBhdHRlc3RhdGlvbiAKPj4+IHNlcnZlcgo+Pj4gbmVlZCB0byBjYXJyeSBhcm91bmQgZm9yIGFu IGF0dGVzdGVkLXRvIHN5c3RlbSBzbyB0aGF0IHRoZSB0cnVuY2F0aW9uIAo+Pj4gaXMgJ3NhZmUn Cj4+PiBhbmQgSSBjYW5ub3QgY3JlYXRlIGZha2UgQUstcXVvdGVzIGFuZCBmYWtlIElNQSBsb2dz IHdpdGggaW5pdGlhbCBQQ1IgCj4+PiBzdGF0ZXM/Cj4+IEFzc3VtaW5nIG1vc3Qgb2YgdGhlIGNs aWVudCBkZXZpY2VzIHRha2UgYSBzbmFwc2hvdCBhdCBzcGVjaWZpYyAKPj4gY2hlY2twb2ludHMs Cj4+IHRoZSDigJxQQ1IgcXVvdGVzIGluIHRoZSBzbmFwc2hvdF9hZ2dyZWdhdGUgZXZlbnQgaW4g SU1BIGxvZ+KAnSB3aWxsIGJlIAo+PiB0aGUgc2FtZSBmb3IgdGhlbS4KPj4gVGhlIHJlbW90ZSBh dHRlc3RhdGlvbiBzZXJ2ZXIgd2lsbCBoYXZlIHRvIHJlbWVtYmVyIHRoZXNlIGdvbGRlbiBQQ1Ig Cj4+IHF1b3Rlcy4KPiAKPiBJIHRob3VnaHQgbWF5YmUgJ2dvbGRlbiBQQ1IgdmFsdWVzJy4uLiBi ZWNhdXNlIHRob3NlIGxldCBtZSByZXBsYXkgUENSIAo+IGV4dGVuc2lvbnMgZnJvbQo+IGEgcHJl dmlvdXMgcG9pbnQuCj4gCj4+IEl0IGRvZXNuJ3QgaGF2ZSB0byByZW1lbWJlciB0aGUgc3RhdGUg b2YgZWFjaCBjbGllbnQgZGV2aWNlLgo+IAo+IENhbiB5b3UgZ2l2ZSBhIHJlYXNvbiBmb3IgdGhp cz8gWW91IG1lYW4gdGhlIHN0YXRlIGRvZXNuJ3QgbmVlZCB0byBiZSAKPiByZW1lbWJlcmVkIGZv ciBjbGllbnQKPiBkZXZpY2VzIHdob3NlIGxvZyBoYXNuJ3QgYmVlbiB0cnVuY2F0ZWQ/Cj4gCkkg bWVhbnQgaXQgZG9lc27igJl0IGhhdmUgdG8gYmUgcmVtZW1iZXJlZCBmb3IgZWFjaCBpbmRpdmlk dWFsCmNsaWVudCBkZXZpY2UuIE1ham9yaXR5IG9mIHRoZSBjbGllbnQgZGV2aWNlcyB3aWxsIGJl IGluIG9uZSBvZiB0aGUgZmV3CmdvbGRlbi1QQ1Itc3RhdGVzIHdoZW4gdGhlIHNuYXBzaG90cyBh cmUgY2FwdHVyZWQuCgp+IFR1c2hhcgoKPiAKPj4+IENhbiBJIGV2ZXIgcmVzdGFydCB0aGUgY2xp ZW50IGFuZCBoYXZlIGl0IHJlYWQgdGhlIHRydW5jYXRlZCBsb2cgZnJvbSAKPj4+IHRoZQo+Pj4g YmVnaW5uaW5nIGFuZCB3aGF0IHR5cGUgb2YgdmVyaWZpY2F0aW9uIG5lZWRzIHRvIGhhcHBlbiBv biB0aGUgc2VydmVyIAo+Pj4gdGhlbj8KPj4+Cj4+IFllcywgcmVzdGFydGluZyB0aGUgY2xpZW50 IHNob3VsZCBiZSBwb3NzaWJsZS4KPiAKPiBZZXMsIHRoaXMgbXVzdCBiZSBwb3NzaWJsZS4KPiAK Pj4+IEl0IHNlZW1zIGxpa2UgdGhlIHNlcnZlciB3b3VsZCBoYXZlIHRvIHJlbWVtYmVyIHRoZSBz dGF0ZSBvZiB0aGUgSU1BIAo+Pj4gUENScyB1cG9uCj4+PiBsYXN0IHRydW5jYXRpb24gdG8gZGV0 ZWN0IGEgcG9zc2libGUgYXR0YWNrLiBUaGlzIHdvdWxkIG1ha2Ugc3RhcmluZyAKPj4+IHRvIG1v bml0b3IKPj4+IGEgc3lzdGVtIGFmdGVyIHRydW5jYXRpb24gaW1wb3NzaWJsZSAtLSB3b3VsZCBi ZSBnb29kIHRvIGtub3cgdGhlc2UgCj4+PiBkZXRhaWxzLgo+Pj4KPj4gVGhlIHNlcnZlciBpcyBu b3QgZm9yY2VkIHRvIHJlbWVtYmVyIHRoZSBzdGF0ZSBvZiBJTUEgUENScy4gSXQgY2FuCj4+IGFs d2F5cyBhc2sgZm9yIHRoZSBsYXN0IG4gc25hcHNob3QgZmlsZXMgKHNoYXJkcykgYW5kIHJlcGxh eSB0aGUgCj4+IGV2ZW50cy4gRXZlbgo+PiB0aG91Z2ggdGhlIGRhdGEgaXMgdHJ1bmNhdGVkIGZy b20gdGhlIElNQSBsb2csIGl0IGlzIG5vdCB0b3RhbGx5IGxvc3QuIAo+PiBJdCBpcwo+PiBzaW1w bHkgYmVpbmcgdHJhbnNmZXJyZWQgdG8gdGhlIGRpc2suIEl0IGlzIHNhdmVkIGJ5IFVNIGFzIHNu YXBzaG90IAo+PiBmaWxlcy9zaGFyZHMuCj4+IFRoZSBnb2FsIG9mIElNQSBzbmFwc2hvdHRpbmcg aXMgdG8gcmVkdWNlIHRoZSBLZXJuZWwgbWVtb3J5IHByZXNzdXJlIAo+PiBvbiB0aGUKPj4gY2xp ZW50IGRldmljZXMgLSB0byBzYXZlIHRoZW0gZnJvbSBvdXQtb2YtbWVtb3J5IGVycm9ycyB3aGlj aCBhcmUgCj4+IGhhcmRlciB0byBtYW5hZ2UKPj4gb24gbG9uZyBydW5uaW5nIGNsaWVudHMuIEl0 IGNvbWVzIHdpdGggYSBjb3N0IG9mIGFkZGl0aW9uYWwgd29yayBvbiAKPj4gdGhlIHNlcnZlcgo+ PiBzaWRlIHRvIGF0dGVzdCB0aG9zZSBjbGllbnRzLgo+IAo+IEFncmVlZC4KPj4KPj4KPj4gQmVp bmcgc2FpZCB0aGF0LCBpbiB0aGUgY3VycmVudCBwcm9wb3NhbCwgdGFraW5nIGEgc25hcHNob3Rz IGlzIAo+PiB0b3RhbGx5IG9wdGlvbmFsCj4+IGFuZCBjb250cm9sbGVkIGJ5IFVNIGF0dGVzdGF0 aW9uIGNsaWVudHMuIElmIHRoZSAKPj4gYXR0ZXN0YXRpb24tY2xpZW50cy9zZXJ2aWNlcyBhcmUK Pj4gbm90LXJlYWR5L2RvbuKAmXQtd2FudCB0byB0YWtlIGFkdmFudGFnZSBvZiBJTUEgbG9nIHNu YXBzaG90dGluZywgdGhleSAKPj4gZG9u4oCZdCBoYXZlIHRvLgo+IAo+IEFncmVlZC4KPiAKPj4K Pj4gTm8gc25hcHNob3Qgd2lsbCBiZSB0YWtlbiwgYW5kIHRoZSBjbGllbnQtc2VydmljZSBjYW4g cHJvY2VzcyB0aGUgCj4+IG1vbm9saXRoaWMgSU1BCj4+IGxvZyBqdXN0IGxpa2UgdGhleSBkbyB0 b2RheS4KPj4KPiAKPiBBZ3JlZWQuCj4gCj4+IFsxXSAKPj4gaHR0cHM6Ly9sb3JlLmtlcm5lbC5v cmcvYWxsL2M1NzM3MTQxLTc4MjctMWM4My1hYjM4LTAxMTlkY2ZlYTQ4NUBsaW51eC5taWNyb3Nv ZnQuY29tLyN0Cj4+Cj4+Pgo+Pj4KPj4+Cj4+Pj4gc2hvdWxkIGhhdmUgYSBiZWdpbm5pbmcgYW5k IGVuZCBxdW90ZSBhbmQgYSByZWNvcmQgb2YgdGhlIEFLIHVzZWQuCj4+Pj4gU2luY2UgdmVyaWZp ZXJzIGxpa2UgS2V5bGltZSBhcmUgYWxyZWFkeSB1c2luZyB0aGlzIGJlZ2lubmluZyBhbmQgZW5k Cj4+Pj4gcXVvdGUgZm9yIHNoYXJkZWQgbG9ncywgaXQncyB0aGUgbW9zdCBuYXR1cmFsIGZvcm1h dCB0byBmZWVkIHRvCj4+Pj4gc29tZXRoaW5nIGV4dGVybmFsbHkgZm9yIHZlcmlmaWNhdGlvbiBh bmQgaXQgbWVhbnMgeW91IGRvbid0IGhhdmUgdG8KPj4+PiBpbnZlbnQgYSBuZXcgZm9ybWF0IHRv IGRvIHRoZSBzYW1lIHRoaW5nLgo+Pj4+Cj4+Pj4gUmVnYXJkcywKPj4+Pgo+Pj4+IEphbWVzCj4+ Pj4KPj4+Pgo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCj4+Pj4ga2V4ZWMgbWFpbGluZyBsaXN0Cj4+Pj4ga2V4ZWNAbGlzdHMuaW5mcmFkZWFkLm9y Zwo+Pj4+IGh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8va2V4ZWMK Pj4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmtleGVj IG1haWxpbmcgbGlzdAprZXhlY0BsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZy YWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8va2V4ZWMK 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 75697EB64DD for ; Fri, 11 Aug 2023 15:57:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236673AbjHKP51 (ORCPT ); Fri, 11 Aug 2023 11:57:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57246 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231364AbjHKP51 (ORCPT ); Fri, 11 Aug 2023 11:57:27 -0400 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 2CA8330D5; Fri, 11 Aug 2023 08:57: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 3EFB920FD0DE; Fri, 11 Aug 2023 08:57:25 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 3EFB920FD0DE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1691769445; bh=zdTZE46AC8XAcWdlVWP+KP3ZBU6mAfYi7siVLldLQyw=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=k4AlgKxEQE0nNZShm8hOi8/E5PIJILFlXh+hf+CccgFQjV2xJTIsKJU07QmBmptnX KoFCnVY3j4FyACoWuL/HkFeMBTj3lTgipUG26Pcd2V6XwxH8+DpYvIlYqm0H31cmc2 5ab1jqMuReitE2mAt29x9TM1e9QmFkjRFhMcBwUI= Message-ID: Date: Fri, 11 Aug 2023 08:57:24 -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: Stefan Berger , James Bottomley , 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> <011d8a79-236f-dc20-08fc-b5da7dd1d5a7@linux.ibm.com> From: Tushar Sugandhi In-Reply-To: <011d8a79-236f-dc20-08fc-b5da7dd1d5a7@linux.ibm.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 07:12, Stefan Berger wrote: > > > On 8/9/23 21:15, Tushar Sugandhi wrote: >> Thanks a lot Stefan for looking into this proposal, >> and providing your feedback. We really appreciate it. >> >> On 8/7/23 15:49, Stefan Berger wrote: >>> >>> >>> On 8/1/23 17:21, James Bottomley wrote: >>>> On Tue, 2023-08-01 at 12:12 -0700, Sush Shringarputale wrote: >>>> [...] >>>>> Truncating IMA log to reclaim memory is not feasible, since it makes >>>>> the log go out of sync with the TPM PCR quote making remote >>>>> attestation fail. >>>> >>>> This assumption isn't entirely true.  It's perfectly possible to shard >>>> an IMA log using two TPM2_Quote's for the beginning and end PCR values >>>> to validate the shard.  The IMA log could be truncated in the same way >>>> (replace the removed part of the log with a TPM2_Quote and AK, so the >>>> log still validates from the beginning quote to the end). >>>> >>>> If you use a TPM2_Quote mechanism to save the log, all you need to do >>>> is have the kernel generate the quote with an internal AK.  You can >>>> keep a record of the quote and the AK at the beginning of the truncated >>>> kernel log.  If the truncated entries are saved in a file shard it >>> >>> The truncation seems dangerous to me. Maybe not all the scenarios >>> with an attestation >>> client (client = reading logs and quoting) are possible then anymore, >>> such as starting >>> an attestation client only after truncation but a verifier must have >>> witnessed the >>> system's PCRs and log state before the truncation occurred. >> You are correct that truncation on it’s own is dangerous. It needs to be >> accompanied by (a) saving the IMA log data to disk as snapshots, (b) >> adding the >> necessary TPM PCR quotes to the current IMA log (as James mentioned >> above), >> (c) attestation clients having an ability to send the past snapshots >> to the >> remote-attestation-service (verifiers), (d) and verifiers having an >> ability >> to use the snapshots along with current IMA logs for the purpose of >> attestation. >> All these points are explained in the original RFC email in sections >> B.1 through B.5 [1]. > > I read it. > > Maybe you have dismissed the PCR update counter already... > I am not sure what the PCR update counter is supposed to help with. It > won't allow you to detect > missing log events but rather will confuse anyone looking at it when my > application extends PCR 12 > for example, which also affects the update counter. It's a global > counter that increases with every > PCR extension (except PCR 16, 21, 22, 23) and if used as proposed would > prevent any application from > extending PCRs. > > https://github.com/stefanberger/libtpms/blob/master/src/tpm2/PCR.c#L667 > https://github.com/stefanberger/libtpms/blob/master/src/tpm2/PCR.c#L629 > https://github.com/stefanberger/libtpms/blob/master/src/tpm2/PCR.c#L161 > > Agree with your point about TPM PCR update counter Stefan. I will bring it up in the update counter patch series discussion [1]. [1] https://patchwork.kernel.org/project/linux-integrity/cover/20230801181917.8535-1-tusharsu@linux.microsoft.com/ > The shards should will need to be written into some sort of standard > location or a config file needs to > be defined, so that everyone knows where to find them and how they are > named. > We thought about well known standard location earlier. Letting the Kernel choose the name/location of the snapshot file comes with its own complexity. Our initial stance is we don’t want to handle that at Kernel level, and let the UM client choose the location/naming of the snapshot files. But we are happy to reconsider if the community requests it. > >>> >>> I think an ima-buf (or similar) log entry in IMA log would have to >>> appear at the beginning of the >>> truncated log stating the value of all PCRs that IMA touched >>> (typically only PCR 10 >>> but it can be others). The needs to be done since the quote itself >>> doesn't >>> provide the state of the individual PCRs. This would at least allow >>> an attestation >>> client to re-read the log from the beginning (when it is re-start or >>> started for the >>> first time after the truncation). >>   Agreed. See the description of snapshot_aggregate in Section B.5 in the >> original RFC email [1]. >>> However, this alone (without the >>> internal AK quoting the old state) could lead to abuse where I could >>> create totally >>> fake IMA logs stating the state of the PCRs at the beginning (so the >>> verifier >>> syncs its internal PCR state to this state). >> Yes, the PCR quotes sent to the verifier must be signed by the AK that >> is trusted by the verifier. That assumption is true regardless of IMA log >> snapshotting feature. >>> Further, even with the AK-quote that >>> you propose I may be able to create fake logs and trick a verifier into >>> trusting the machine IFF it doesn't know what kernel this system was >>> booted with >>> that I may have hacked to provide a fake AK-quote that just happens >>> to match the >>> PCR state presented at the beginning of the log. >>> >> If the Kernel is compromised, then all-bets are off. >> (Regardless of IMA log snapshotting feature.) >>> => Can a truncated log be made safe for attestation when the >>> attestation starts >>> only after the truncation occurred? >>> >> Yes. If the “PCR quotes in the snapshot_aggregate event in IMA log” > > PCR quote or 'quotes'? Why multiple? > > Form your proposal but you may have changed your opinion  following what > I see in other messages: > "- The Kernel will get the current TPM PCR values and PCR update counter > [2] >    and store them as template data in a new IMA event > "snapshot_aggregate"." > > Afaik TPM quote's don't give you the state of the individual PCR values, > therefore > I would expect to at least find the 'PCR values' of all the PCRs that > IMA touched to > be in the snapshot_aggregate so I can replay all the following events on > top of these > PCR values and come up with the values that were used in the "final PCR > quote". This > is unless you expect the server to take an automatic snapshot of the > values of the > PCRs  that it computed while evaluating the log in case it ever needs to > go back. > I meant a single set of PCR values captured when snapshot_aggregate is logged. Sorry for the confusion. >> + "replay of rest of the events in IMA log" results in the “final PCR >> quotes” >> that matches with the “AK signed PCR quotes” sent by the client, then >> the truncated >> IMA log can be trusted. The verifier can either ‘trust’ the “PCR >> quotes in the >> snapshot_aggregate event in IMA log” or it can ask for the (n-1)th >> snapshot shard >> to check the past events. > > For anything regarding determining the 'trustworthiness of a system' one > would have to > be able to go back to the very beginning of the log *or* remember in > what state a > system was when the latest snapshot was taken so that if a restart > happens it can resume > with that assumption about state of trustworthiness and know what the > values of the PCRs > were at that time so it can resume replaying the log (or the server > would get these > values from the log). > Correct. We intend to support the above. I hope our proposal description captures it. BTW, when you say ‘restart’, you mean the UM process restart, right? Because in case of a Kernel restart (i.e. cold-boot) the past IMA log (and the TPM state) is lost, and old snapshots (if any) are useless. > The AK quotes by the kernel (which adds a 2nd AK key) that James is > proposing > could be useful if the entire log, consisting of multiple shards, is > very large and > cannot be transferred from the client to the server in one go so that > the server could > evaluate the 'final PCR quote' immediately . However, if a client can > indicated 'I will > send more the next time and I have this much more to transfer' and the > server allows > this multiple times (until all the 1MB shards of the 20MB log are > transferred) then that > kernel AK key would not be necessary since presumably the "final PCR > quote", created > by a user space client, would resolve whether the entire log is > trustworthy. > See my responses to James today [2] [2] https://lore.kernel.org/all/72e39852-1ff1-c7f6-ac7e-593e8142dbe8@linux.microsoft.com/ >> >>> => Even if attestation was occurring 'what' state does an attestation >>> server >>> need to carry around for an attested-to system so that the truncation >>> is 'safe' >>> and I cannot create fake AK-quotes and fake IMA logs with initial PCR >>> states? >> Assuming most of the client devices take a snapshot at specific >> checkpoints, >> the “PCR quotes in the snapshot_aggregate event in IMA log” will be >> the same for them. >> The remote attestation server will have to remember these golden PCR >> quotes. > > I thought maybe 'golden PCR values'... because those let me replay PCR > extensions from > a previous point. > >> It doesn't have to remember the state of each client device. > > Can you give a reason for this? You mean the state doesn't need to be > remembered for client > devices whose log hasn't been truncated? > I meant it doesn’t have to be remembered for each individual client device. Majority of the client devices will be in one of the few golden-PCR-states when the snapshots are captured. ~ Tushar > >>> Can I ever restart the client and have it read the truncated log from >>> the >>> beginning and what type of verification needs to happen on the server >>> then? >>> >> Yes, restarting the client should be possible. > > Yes, this must be possible. > >>> It seems like the server would have to remember the state of the IMA >>> PCRs upon >>> last truncation to detect a possible attack. This would make staring >>> to monitor >>> a system after truncation impossible -- would be good to know these >>> details. >>> >> The server is not forced to remember the state of IMA PCRs. It can >> always ask for the last n snapshot files (shards) and replay the >> events. Even >> though the data is truncated from the IMA log, it is not totally lost. >> It is >> simply being transferred to the disk. It is saved by UM as snapshot >> files/shards. >> The goal of IMA snapshotting is to reduce the Kernel memory pressure >> on the >> client devices - to save them from out-of-memory errors which are >> harder to manage >> on long running clients. It comes with a cost of additional work on >> the server >> side to attest those clients. > > Agreed. >> >> >> Being said that, in the current proposal, taking a snapshots is >> totally optional >> and controlled by UM attestation clients. If the >> attestation-clients/services are >> not-ready/don’t-want to take advantage of IMA log snapshotting, they >> don’t have to. > > Agreed. > >> >> No snapshot will be taken, and the client-service can process the >> monolithic IMA >> log just like they do today. >> > > Agreed. > >> [1] >> https://lore.kernel.org/all/c5737141-7827-1c83-ab38-0119dcfea485@linux.microsoft.com/#t >> >>> >>> >>> >>>> should have a beginning and end quote and a record of the AK used. >>>> Since verifiers like Keylime are already using this beginning and end >>>> quote for sharded logs, it's the most natural format to feed to >>>> something externally for verification and it means you don't have to >>>> invent a new format to do the same thing. >>>> >>>> Regards, >>>> >>>> James >>>> >>>> >>>> _______________________________________________ >>>> kexec mailing list >>>> kexec@lists.infradead.org >>>> http://lists.infradead.org/mailman/listinfo/kexec >>