[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <65c2e4aa54a0_d4122947f@dwillia2-mobl3.amr.corp.intel.com.notmuch>
Date: Tue, 6 Feb 2024 18:02:18 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: James Bottomley <James.Bottomley@...senpartnership.com>, "Xing, Cedric"
<cedric.xing@...el.com>, Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@...ux.intel.com>, Dan Middleton
<dan.middleton@...ux.intel.com>, Samuel Ortiz <sameo@...osinc.com>, "Dan
Williams" <dan.j.williams@...el.com>
CC: Qinkun Bao <qinkun@...gle.com>, "Yao, Jiewen" <jiewen.yao@...el.com>,
Dionna Amalie Glaze <dionnaglaze@...gle.com>, <biao.lu@...el.com>,
<linux-coco@...ts.linux.dev>, <linux-integrity@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v2 0/4] tsm: Runtime measurement registers ABI
James Bottomley wrote:
> There isn't really anything more complex about an interface that takes
> a log entry, and does the record an extend, than an interface which
> takes a PCR extension value. So best practice would say that you
> should create the ABI that you can't get wrong (log and record) rather
> than creating one that causes additional problems for userspace.
Agree, there's no need for the kernel to leave deliberately pointy edges
for userspace to trip over.
Cedric, almost every time we, kernel community, build an interface where
userspace says "trust us, we know what we are doing" it inevitably
results later in "whoops, turns out it would have helped if the kernel
enforced structure here". So the log ABI adds that structure for the
primary use cases.
Powered by blists - more mailing lists