linux-kernel - Re: [PATCH 0/4] keys: Introduce a keys frontend for attestation reports

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <64d307b94bd9_2138e29488@dwillia2-xfh.jf.intel.com.notmuch>
Date:   Tue, 8 Aug 2023 20:27:53 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     "Huang, Kai" <kai.huang@...el.com>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        "dionnaglaze@...gle.com" <dionnaglaze@...gle.com>
CC:     "sameo@...osinc.com" <sameo@...osinc.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "jarkko@...nel.org" <jarkko@...nel.org>,
        "bp@...en8.de" <bp@...en8.de>,
        "dhowells@...hat.com" <dhowells@...hat.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "sathyanarayanan.kuppuswamy@...ux.intel.com" 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        "thomas.lendacky@....com" <thomas.lendacky@....com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
        "brijesh.singh@....com" <brijesh.singh@....com>,
        "James.Bottomley@...senpartnership.com" 
        <James.Bottomley@...senpartnership.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>
Subject: Re: [PATCH 0/4] keys: Introduce a keys frontend for attestation
 reports

Huang, Kai wrote:
> On Tue, 2023-08-08 at 11:17 -0700, Dan Williams wrote:
> > Dionna Amalie Glaze wrote:
> > > > 
> > > > I do not see sysfs precluding a use case like that. If the kernel can
> > > > call out to userspace for TLS connection setup [1], then advanced user
> > > > can call out to a daemon for workload provenance setup. Recall that TDX
> > > > will round trip through the quoting enclave for these reports and,
> > > > without measuring, that seems to have the potential to dominate the
> > > > setup time vs the communication to ask a daemon to convey a report.
> > > > 
> > > 
> > > It's rather hard to get new daemons approved for container
> > > distributions since they end up as resource hogs.
> > > I really don't think it's appropriate to delegate to a daemon to
> > > single-thread use of a kernel interface when the interface could
> > > provide functional semantics to begin with.
> > 
> > That's fair, it's also not without precedence for the kernel to await a
> > strong motivation of a use case before taking on a higher maintenance
> > burden. Unifying kernel interfaces is important for maintainability and
> > difficult / needs care. sysfs simplifies maintainability (but exports
> > complexity to userspace), keyring simplifies that (but there is a valid
> > argument that this is not a key), ioctl complicates that (it is not as
> > amenable to transport unification as the above options).
> > 
> 
> I don't quite follow why ioctl() is not amenable to transport unification as the
> /sysfs?  IIUC both are new ABI(s) to the userspace thus userspace needs to adopt
> anyway.  

Recall that the concern here is kernel maintainability, the kernel can
decide to export complexity to userspace. In that light, ioctl() code is
grotty sysfs is not. sysfs attributes (tsm blob options) are easy to
reason about and audit, ioctl() is not. sysfs is easy to extend with
local attributes to augment the core, ioctl() forces all the optionality
to be planned up front.

Basically, if you hand me a choice between maintaining a cross vendor
ioctl() ABI vs a sysfs ABI, I am picking sysfs every time.

> On the other hand, ioctl() seems to be able to handle concurrent requests better
> than /sysfs, if we want to support the case that integrating attestation to the
> handshake protocols.

There is not an exceedingly strong case for high frequency concurrent
requests vs boot time attestation and deriving further secrets from
that.