On Wed, 2023-06-28 at 11:02 +0200, gregkh@xxxxxxxxxxxxxxxxxxx wrote: > On Wed, Jun 28, 2023 at 08:56:30AM +0000, Huang, Kai wrote: > > On Wed, 2023-06-28 at 08:46 +0200, gregkh@xxxxxxxxxxxxxxxxxxx wrote: > > > On Wed, Jun 28, 2023 at 02:16:45AM +0000, Huang, Kai wrote: > > > > > You really shouldn't be putting attestation validation logic in the > > > > > kernel. > > > > > > > > Agreed. The data blob for remote verification should be just some data blob to > > > > the kernel. I think the kernel shouldn't even try to understand the data blob > > > > is for which architecture. From the kernel's perspective, it should be just > > > > some data blob that the kernel gets from hardware/firmware or whatever embedded > > > > in the root-of-trust in the hardware after taking some input from usrspace for > > > > the unique identity of the blob that can be used to, e.g., mitigate replay- > > > > attack, etc. > > > > > > Great, then use the common "data blob" api that we have in the kernel > > > for a very long time now, the "firwmare download" api, or the sysfs > > > binary file api. Both of them just use the kernel as a pass-through and > > > do not touch the data at all. No need for crazy custom ioctls and all > > > that mess :) > > > > > > > I guess I was talking about from "kernel shouldn't try to parse attestation data > > blob" perspective. Looking at AMD's attestation flow (I have no deep > > understanding of AMD's attestation flow), the assumption of "one remote > > verifiable data blob" isn't even true -- AMD can return "attestation report" > > (remote verifiable) and the "certificate" to verify it separately: > > > > https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snp-attestation.html > > > > On the other hand, AFAICT Intel SGX-based attestation doesn't have a mechanism > > "for the kernel" to return certificate(s), but choose to embed the > > certificate(s) to the Quote itself. I believe we can add such mechanism (e.g., > > another TDVMCALL) for the kernel to get certificate(s) separately, but AFAICT it > > doesn't exist yet. > > > > Btw, getting "remote verifiable blob" is only one step of the attestation flow. > > For instance, before the blob can be generated, there must be a step to > > establish the attestation key between the machine and the attestation service. > > And the flow to do this could be very different between vendors too. > > > > That being said, while I believe all those differences can be unified in some > > way, I think the question is whether it is worth to put such effort to try to > > unify attestation flow for all vendors. As Erdem Aktas mentioned earlier, "the > > number of CPU vendors for confidential computing seems manageable". > > So you think that there should be a custom user/kernel api for every > single different CPU vendor? That's not how kernel development works, > sorry. Let's try to unify them to make both the kernel, and userspace, > sane. > > And Dan is right, if this is handling keys, then the key subsystem needs > to be used here instead of custom ioctls. > Sure. I have no objection to this.
