Messages in this thread | | | Date | Tue, 8 Aug 2023 11:17:33 -0700 | From | Dan Williams <> | Subject | Re: [PATCH 0/4] keys: Introduce a keys frontend for attestation reports |
| |
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).
| |