On Tue, Jun 27 2023 at 00:50, Chong Cai wrote:
On Sun, Jun 25, 2023 at 9:32 PM Dan Williams dan.j.williams@intel.com wrote:
What I would ask of those who absolutely cannot support the TDVMCALL method is to contribute a solution that intercepts the "upcall" to the platform "guest_attest_ops" and turn it into a typical keys upcall to userspace that can use the report data with a vsock tunnel.
That way the end result is still the same, a key established with the TDX Quote evidence contained within a Linux-defined envelope.
I agree a unified ABI across vendors would be ideal in the long term. However, it sounds like a non-trivial task and could take quite some time to achieve. Given there's already an AMD equivalent approach upstreamed, can we also allow this TDVMCALL patch as an intermediate step to unblock various TDX attestation user cases while targeting unified ABI? The TDVMCALL here is quite isolated and serves a very specific purpose, it should be very low risk to other kernel features and easy to be reverted in the future.
No way. This is exactly how the kernel ends up with an unmaintainable mess simply because this creates an user space ABI which is not revertable ever.
It's bad enough that nobody paid attention when the AMD muck was merged, but that does not make an argument or any form of justification to add more of this.
Dan's proposal makes a lot of sense and allows to implement this in a mostly vendor agnostic way. While the AMD interface is not going away due to that, I'm 100% confident (pun intended) that such an unified interface is going to be utilized and supported by AMD (or any other vendor) sooner than later simply because the user space people who have to implement vendor agnostic orchestration tools will go for it as it makes their life easier too.
The time wasted to argue about this TDX ioctl mess could have been spent to actually migrate TDX over to this scheme. But sure it's way simpler to flog a dead horse instead of actually sitting down and getting useful work done.
Thanks,
tglx