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: <CAMkAt6oTnjcpLch7DQmWyM+JOobhRMVNSQFrBxKV4Z4eB51oXA@mail.gmail.com>
Date:   Wed, 9 Aug 2023 10:14:56 -0600
From:   Peter Gonda <pgonda@...gle.com>
To:     Dan Williams <dan.j.williams@...el.com>
Cc:     "Huang, Kai" <kai.huang@...el.com>,
        "dionnaglaze@...gle.com" <dionnaglaze@...gle.com>,
        "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

On Tue, Aug 8, 2023 at 9:28 PM Dan Williams <dan.j.williams@...el.com> wrote:
>
> 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.

Thanks for the explanation. My pushback isn't because I really want an
IOCTL, rather I want the user to have the ability to get the exact
attestation report they want. This interface shown here was too
restrictive. If this can be accomplished with another ABI that sounds
fine to me.