 Thanks everybody for coming My name is Jeremy Powell. I'm a security architect for AMD And I work on the confidential compute solution SMP Today I'm gonna be talking about attestation a lot of folks have asked about how does attestation work in SNP and it's kind of complicated. So I'd like to kind of go through it explainer So to overview what SEV is we have Three different features that kind of stack on top of each other. The first one is SEV SEV provides the confidentiality of The confidential compute solution We do this through memory encryption and then SEV is covering only the memory of a guest SEV ES was introduced after that and that includes the confidentiality and somewhat integrity of Of the registers of the guest these two features have a Lighter weight threat model because we're only talking about confidentiality in SNP We could we introduced the idea of both confidentiality and integrity for a guest SEV and SEV ES were introduced and first and second generation of epic and SNP was introduced and the third generation so What is the threat model? I think that it's important to always talk about the threat model of whatever you're talking about because Oftentimes you can get off into the weeds about, you know The mini gritty mechanics and you forget what you're trying to address so confidential computes threat model is about confidentiality and integrity and it's about the flipped notion that the cloud provider or the hypervisor that the folks that are hosting the the guest Are not trustworthy so They can do a number of different threats or actions that amount to threats inside this threat model They can run a malicious hypervisor The hypervisor can mix pages and alias pages and mess with Injecting events into the guests unexpectedly The cloud provider can run malicious guests in conjunction with attacks by the hypervisor The the cloud provider can Have host applications to support that they can run malicious devices. So you could think of a Malicious device as either being a commercial device that the hypervisor has programmed to try to touch guest memory Or you could think of even a you know bespoke bad Device intending like built for the purpose of attacking guests Finally we have the the whole fact that the cloud providers responsible for maintaining the configuration of the platform and For initializing and launching guests So the the hypervisor could run Vulnerable firmware or it could run It could lie and say oh, this is you know AMD hardware and it really isn't and then when the hypervisor runs guests then in you know in our model particularly the hypervisors is responsible for bootstrapping the environment of of a secure guest, but Maybe it doesn't do it correctly or maybe it does it in a way that the guest wasn't expecting So these are both confidentiality and integrity Related threats the hypervisor and the cloud provider are still expected to provide the availability to the guest That's you know push the button over and over again to make sure it runs So this talk is going to focus on the threats around misconfiguring the Platform and basically configuring the guest on its launch So we've heard a lot about out at a station over the past week at a station in a confidentiality confidential guest environment company computational compute environment is Ultimately a case where the the hardware that is enforcing the security properties of a confidential guest knows all of the measurements all the inputs to the security Security control security policy, but it doesn't actually know the policy itself. So, you know, this is the case where Our security processor knows You know the measurement of the guest or how the guest is laid out in memory or the version numbers of the firmware But it doesn't know how to take that and turn that into a security decision. So attestation is necessary to delay and delegate that security decision to a A remote relying party like in our case. We're talking about the guest owner So in attestation the hypervisor is going to launch the guests The security processor grabs that information about what how the guest was launched It grabs information with the platform produces an attestation report Sends it to the guest owner and then the guest owner is responsible for making the decision Yes, or no, and it's only in that time that the guest actually gets the trust We at like I trust the workload I trust this guest to do my workload or I trust this guest to actually touch my secrets And so the guest owner provides that through some Channel that it sets up with the guest and says hey, here's all your secrets or here's the some master secret to unlock a desk in S&P this diagram maps really great and really directly our security processor is the one who's doing all the measurements and the AMD firmware the x86 Microcode all that stuff is being in is being collected by our our security processor doing during during this execution during launch so To talk about how we do attestation we have to go through several different areas We want to talk about the platform measurements themselves. We want to talk about how the guest is measured We want to talk about how does the guest owner know? Whether or not the the report that it receives is authentic We want to talk about from a kind of a mechanical way, how does a guest owner get the attestation report? And then we want to talk about okay, so now you've attested the guest Now what how do you how do you connect the dots between a you know a small kernel bootloader? OVMF in it or ID, whichever you decide to measure how do you connect that to the rest of the system? So our trusted computing base for a guest running an S&P It starts at the hardware root of trust So we have a boot ROM and the boot ROM is this site and is executed by our security processor At the very beginning of boot and that's where we derive our you know manufacturing silicon security From there trust is chained down to the security processor bootloader the security processor operating system The firmware that runs inside that security processor like the application that does all the business logic for for S&P and then Also a major part of our implementation is x86 microcode and microcode can be patched So it's a mutable thing that we need to measure other the rest of the of the TCB is involving with the guests, so we have We want to measure the guests Image we want to measure it's some of the metadata We want to measure the runtime environment of what that guest looks like so certain features could be turned on and off Hypervisor has a great control over what that looks like so we want to make sure that the guest owner sees that and can make a decision about whether it trust that guest Okay so this the the thing that we report in our attestation report is for for the Identity of the mutable firmware that's in our system is The TCB version so we build this TCB version string from the bootloader operating system Firmware version and microcode patch level. This is built into basically a you know for component You know like major minor kind of thing where the bootloader's SVN is The most significant whereas the x86 microcode patch level is the least significant And we use that to order and compare patch levels or TCB versions across Different executions and to say this one that has a greater version than this one so We track a Lot of TCB versions in the implementation And a lot of this is built for the purpose of live update of our firmware Some of the firmware can be updated and so we want to make sure that we understand precisely what is running could run in the future was run at the launch of the guest and Some other management so the the we have a well we have the current version which is the natural intuitive what's running now We have a committed version which is our It's the anti rollback low-water mark so in the diagram you can see kind of this timeline where you have a Committed version and a current version and so what this is saying is that the current version is a version 3 and It could potentially roll back to the committed version But it can't roll back to a previous version and we allowed this to happen to allow for Provisional updates so if the if the cloud provider wants to roll out firmware provisionally try it out figure it out and Then we can allow it to go forward, but the only security. We're going to guarantee is that the committed version So, you know, we call this but when this is like in the diagram call that a provisional installation there's a reported version that is a management tool for us to display a version to the guest that is Not surprising so the hypervisor can set this reported tcb version to Something that the guest is already using so if for instance the The hypervisor of the cloud provider wants to present Once to install version 3 guests are running it version 1 or 2 here It can set reported tcb to one and that will be with the the the version that's used for various different operations inside of our Firmware for you know version keying that we'll talk in a few minutes and It allows the the case where a guest can't process an attestation report With a newer version. So reported version is a way to kind of hold off the Visibility of the upgrade to the guest until Infrastructures in place so that the guest has you know, it knows about the new version It knows how to retrieve a certificate. That's specific to that new version And it won't fall in its face when it sees a brand new thing We also track the launch version. So you can imagine if a guest is running and it starts off at an early version and throughout the lifetime of Execution of the of SNP You live update the firmware You may want to know what the with the with the version at the time of launch that guest had So, you know, okay everything looks great, but my guest was launched at an early stage an early version I may have opinions about that as a guest owner I may say well I don't trust this guest anymore because I know about vulnerabilities and version whatever version one But so we so we track that launch that launched TCB that so the diagram describes also how you go back and forth so We have if you're in this state that the diagram describes we're committed as version two and The current is version three to to raise that low watermark the to to change the committed version you execute SNP commit and SNP commit basically all it does is change that version, but now the guests can start saying Yeah, I'm on version three now, and you can trust me more It isn't until that committed version low watermark goes up that the guests can start using and seeing secrets Released by the guest owner by the relying party That's associated with the trust that's that's granted till a version three If for whatever reason we're at a provisional installation and we say, you know, nope I don't want to do that hypervisor can execute download firmware EX and this function basically loads the new firmware image and will Set the current version back to the committed version whenever it gets rolled back so this is a table of The platform measurements that we put into the attestation report each of you if you look into our spec the each of the these lines here are Lines in the in the attestation report. So current ECB like I said, it's informational If if the the firmware that's running is could be rolled back in the future You don't want to trust it necessarily So we say that we put current here for potentially like Development purposes, but it is informational You should really trust and base your security decisions on the committed TCB and the committed TCB tells you I will never be at a lower state during the execution of lifetime of this particular guest And so you can use that to figure out, you know, do I trust this guest? The the reported TCB in the attestation report does a couple things It's and it is the I Think most importantly reported TCB keys. It tells you which Which key is used to sign this we use a versioned key to sign each of the attestation reports based on the version of the platform So reported TCB is that is one of the major keys to figuring out How do I find the certificate to validate this sort of this this this report? The chip ID there is also part of that our version key is is chip unique And so you need to go when you go into our our key service. You want to say I have this chip ID Here's the TCB of my system. Please give me a My version key The the launch It tells you whether or not what what the what the what the committed version of the guest was Now kind of a side comment on launch it's something that could be More complicated than you might think if you consider the case where a guest is migrated The version that the system is at at a particular time may not be the actual system that the guest was launched at so you may want to migrate and continually Transitively continue that guests launch TCB across migration and so that can tell you even though it's moved across the world It was actually launched in an older version the the platform info which we haven't talked about yet is a bit mask it describes Ultimately what the cyst what the platforms configuration is at a given at the time of the attestation report being generated so Currently we we track two things we're intending for this to be something that could be tracking more things over time The first one is to say whether or not whole system memory encryption is enabled. We call it TSME transparent secure memory encryption So if you cared that the system had full memory encryption as in Host memory encryption something that doesn't have to do with confidential compute But you care that you know even shared pages are encrypted with something then you would look for that bit Also, if you wanted to say I don't want to run a sit on a system that has SMT enabled Which is the simultaneously simultaneous multi-threading with sibling threads to two hardware threads in the same core You can say you know I don't want that one reason might you might want not want that is if you're particularly concerned about the side channels that could happen on sit between two sibling threads, so this is a good a Bit vector to look at if you want to have if you have particular concerns about the the the platform configuration at a hole as a whole so Going to guest measurements To launch a guest we have three Commands roughly start update finish kind of mirrors how you would do you know in a hash off the hash function You know I started initialize the context do a bunch of updates on each of the pages of the guest and they call a single finish operation to cap it off and complete the operation each update operation is executed in a single page and That page is being placed is a plain text page that the hypervisor has you know, I can imagine having a Buntu image CD that you want to turn into a Confidential guest well the CD is unencrypted But you need to make it encrypted you need to make it prepared for doing confidential compute so as the the security processors processing these commands it has the notion of where the where the pages and System physical memory as well as where it is inside the guest physical memory space and so what we do is we take the contents of that page and Some of the page metadata like you know, it's GPA What kind of pages it is like if it's a page that's intended to contain guest, you know and pre initialized data does it contain the register save state area the VMS a for for execution like the initial like CPU state or If it contains, you know other special kinds of pages that we've defined all that metadata is placed into a structure and the contents of the page and that metadata is Extended into a running launch digest. So as each of these update operations occur We are measuring the state the initial state of that guest And so once we get finished we have a launch update a launch digest that can be used to say, you know Objectively, this is what is actually launched Note that our launch digest isn't really a running hash. It's kind of done in the terms of a PCR extension. So The notion here is that we take the launch digest that we've previously had and we concatenate that roughly with the page metadata and the page and we hash that again We replace the old hash all digest the new digest So once we get to launch finish This is when we want to finish off the the launch operation get the guests ready to go among other things like You know doing some of the sock initialization to say, you know install new encryption keys or or actually saying the you know The guests can start reading those keys through their firmware controller We also have The final step, which is this ID block and I have a slide after this but ultimately the ID block contains information about what the guest owner expects the guest to look like so it Contains of among several other things. It contains the launch digest of what it expects and Expect it has contains the expected guest policy. Now. I don't have a slide here that describes the the guest policy but the guest policy describes some Some runtime Decisions that we care that you might care about like Allowing debug commands to be executed sometime in most cases you want that to be disabled So that's the kind of thing that's in the guest policy So The the ID block is produced by the guest owner The ID block contains all this information that you've produced at the image creation time You're saying I have this image this a bunch of disc or whatever it happens to be and I have all this information. I want it. I expect it to look like after it's been launched and I want to make sure that at the at the first instruction that that is actually being enforced and so The ID block contains this information and you produce it at the same time you create the image and then you have a ID key so this ID key is owned by the guest owner and it signs the ID block and When When the launch finish command is executed the firmware receives The signed ID block and the public key of the ID key pair and it Validates first of all this is the signature of the ID block and if that passes then it enforces the the contents that the small policy that's inside the ID block We also have optionally a way to have an author key, which we've just recalled that signs the ID block ID key and to be able to support a Perhaps more flexible PKI around around signing these blocks so One of the things that's inside the ID block is Some image metadata We have a family ID and image ID a guest SVN none of these fields here are actually Parced or looked at by the firmware We just collect them from the ID block and stash them away in a guest context inside of our firmware And then where we create the attestation report We we place these fields into the report and so this can be used for Tracking the images that you've produced it can also It can also be a way to Decouple the production of the image with a particular measurement From the guest owner looking at a an image and saying I trust this image so you can imagine the case where you produce image ID 5 and With some measurement right and you you you roll it out into the cloud and at some point there's a vulnerability in it Well, oh, I'm sorry at some point There's a non a non security related Functional update to this image like you do you have to get update and you just pull a new package or whatever it happens to be and You don't really care about the measurement at the time you You you do the attestation? Interpretation so you just say I just need to see image ID 5 so when the new version of the image is created the A new ID block with a new measurement is there because the measurement has to match But the ID the image ID can be used to Raise up the interpretation of you know, what does it mean for this image to be you know have this measurement? Well, perhaps the guest owner doesn't know at that time. He just says I need to know I need to see image 5 We do place the measurement in the attestation report so if you wanted to you can Disregard the ID block and you can look at a measurement and check that out You know, it's the same measurement that we produced during launch during launch We also have in order for you to trust that the right ID block was used The one that was associated with your image because perhaps the hypervisor and invented its own Key it placed its own public key into the launch finish and it has a malicious ID block Well, we take a digest a fingerprint basically of the ID key and if the author key if present And we put it into our attestation report So you can go look to say, you know, maybe you want to bring up bring your your guest policy up or a guest owner Relying party attestation interpretation up another level So you might say I don't care. I Don't care about any of the other metadata. I just want to know that it came from me at some point So you may say as long as the ID key digest matches something that I matches a key that I own then I That's that's good enough for me The the guest policy is placed in the attestation report tells you again, you know, what? What the debug is enabled or other various things? And we have this last line. I don't have a Slide for this but we have a notion of a migration agent This is a special guest that has a special relationship with the guest that's launched and Its job is to essentially assist in the migration of a guest This isn't a necessary feature. We have other ways to do it but if you were to say if you were to imagine say a Single tenant has multiple guests They could have all of its guests bind with a single migration agent and that migration agent can be in charge of looking at a the receiving Machine it's going to take that guest so The the the guest has this this migration agent has the ability to see a lot of the secrets of that of the other guest So it is within the TCB of that guest so if you're using a migration agent we have a Unique report ID that we generate randomly. It's like a 128 bit value and Each attestation report contains the report ID of the migration agent, which is which has to be an SNP guest So when you're when you're reviewing an attestation report and you see that there are a migration agent report ID is in the attestation report You need to say wait a second Migration agent is bound to this do I expect that if no then reject the attestation report but if yes, then go compare to The you know the report the the attestation report of that that migration agent So how do you how do you how do you determine the authenticity of attestation report? So in our in our parts, we have a chip unique secret burned into fuses at manufacturing time and this secret is essentially mixed with the security version numbers the TCB version in total of the platform so Anytime the SNP firmware SVN bumps, then you need a new a different VCK different versioned key attestation key If the microcode patch changes you need a different key so in order to support that we have a Signing service or a key service that you can go request given the the unique chip identifier and the Version you get you get back a certificate chain for that For that VCK, so a guest needs to go retrieve that in order to process a particular attestation report so What do you do with? With an attestation report Like how do you how do you make it useful so you you couldn't you know? I think there was a talk yesterday about all the different methods of attesting different chunks of an image You can you know only the bootloader and then everything has a bootstrap from there or you can on the other side of the spectrum measure the entire guest image and Then you don't do anything So somewhere in between where you're chaining trust from a you know a kernel or a kernel on an it Rd to The rest of user space You want to be able to use our attestation report so When the attestation report is requested by the guest itself the guest can say here is 64 bytes of opaque data that I want you to place into the report It's not interpreted by firmware We just blindly put it in there and the intent is for the guest to put something in there that identifies itself cryptographically so the you know the what we envision is that I guess creates a key pair and That ephemeral II like on each guest instance. It wouldn't be something safe to desk. It would be something you generate on the fly You place the digest of that key pair Inside the report data and then now when somebody processes and accepts an attestation report They now have a cryptographic binding using our our chipping key to the to the to the to the new ephemeral key that the guests created so it's kind of like the attestation report is a It's a kind of the spoke certificate for that key And so one use case that's been discussed in past week is use that key that report data to to to Certify so to speak the endorsement key of a vtpm So as I mentioned the guest is the one who retrieves a An attestation report We have a secure channel We have a secure channel between the guest and the security processor that the hypervisor cannot Cannot see or cannot cannot break into the plaintext. It's a it's a encrypted channel the The messages that are center of that channel are defined in our spec one of them one of which is the message report request Message this is the message that's going to contain that report data And it's going to be wrapped up in the in the trusted channel Sent to a security processor and the security processor is going to send back another message in that channel That's going to contain the attestation report The the hypervisor is just simply the transport here So it's going to receive the packet from the guest if there's no Direct communication to the security processor between the the guest And the security processor it's actually hypervisor receiving the encrypted packet and then Shuffling it off to the the security processor Then the hypervisor passes that to the security processor using this s&p guest request command So Linux has two sets of or two device Files that are used for managing sev And the host or in the guest that is there is this dev sev guest and through that device file You can retrieve the attestation report you know that to to to get To get it from the the security processor There are there's two I octals get report and get this extended guess report The extended get report allows you to ask for both the attestation report and the certificate so in this case what you're looking at is is The the the host is already going to prefetch Or it came in this in this mechanism can prefetch the at this the certificate for you So it knows what platform you're on it knows what Version of the platform it knows what version of the platform firmware you are you're using so it can go Retrieve that certificate ahead of time And so whenever you ask for the attestation report it can funnel that through and the hypervisor can provide that the host can Provide that through dev sev through this set extended configuration so Ultimately s&p attestation is Allows us to measure and had getting confidence in the platform and in the guest configuration It can boot trap bootstrap these deeper chains of attestation So if you wanted to put a vtpm and the guest that's this is how you would connect it to the hardware When I when I finished these slides Tom was the only one Tom's Conversation was the only one I knew about that had to do with this But there've actually been several talks in the past week talking about svsm vtpm attestation So, you know, I encourage you guys to go check those out We also have some tooling that we're working on with the community. There's an scv tool Get hub repository that talks that has a it's a multi tool for various things and We also have another one that's being developed from the community for Currently it's in rust it has support for some of the legacy interfaces that we have But there's a pull request that's being processed right now that that adds s&p and attestation bits and pieces to it So the future work here is us and you guys potentially Contributing more to that to that tooling Okay That's all I've got any questions Okay, so so can you does it support nested virtualization? It does not okay. Okay I've been wondering that for once. I just in terms of your attestation report You only mentioned Attesting version numbers and it looked like that might only be related to the VC ek Does the attestation report include? The version numbers of the firmware that is being reported So our firmware tracks we have two versions associated with the firmware image We have a you know a classic version number that we associate with it And then we have a security version number Security version number takes along only whenever we have security related updates And so it's the security version number that we're tracking in the firmware and that that comes in the attestation report Yes, but you might lie about that if I haven't acknowledged that the version current versus reported If I update the firmware underneath and I haven't yet committed that version number And I'm running on a newer version of the firmware. Is that visible in the attestation report in any way? So you're saying you've What I'm missing is I don't see how the guest can trust the version of Underlying firmware that's being provided Firstly because you're only providing version numbers not actual hashes of the components from from the description here and Secondly because you have this mechanism by which the underlying firmware and hypervisor Pretend to the guest that the firmware hasn't been updated. So as the guest, how do I know? what actual underlying pieces I'm running off where's your attestation of The platform that I'm running on even if I haven't done the update or whatever I should I still want to be able to see that Something has changed underneath me in terms of the environment. I'm running in and I don't see where that piece is right so I Let's talk about the the versions for you know, you've updated and you want to see that that something has happened so What we we report all of this in fact we we don't even just report that the SVNs We report the actual version numbers inside the attestation report as well I didn't talk about it here because those version numbers aren't as critical to security But we do show that things are changing out from underneath you the the reported TCB in Terms of lying so to speak It needs to it needs to be less than or equal to the committed version So it can't be anything higher. So and with the with the assumption that As you increase the version it gets more secure. I mean that may be a tenuous argument, but The Security version the reported version never goes higher than committed. So you can't lie to say oh, yeah You're you're at a high level good for you and you're secure So we will be limit that And and for the current version we report the current version of the firmware as well as we report the current TCB the current SVN of the firmware now to your question about hashes We don't actually report the hashes of the firmware I think I suppose it could be you know something to look into in terms of extra information to provide a lot of times hashing is More difficult because you're you're you're trying to track, you know It's it's hard to interpret that particularly from Vendors whenever we're gonna say trust, you know, you're just gonna have to just take the latest A version number does almost the same thing, but I agree there could be some cases where it would be better to have the Measurement I've seen firmware vendors ship Exactly the same version with differences is sort of like you always trust right in an ideal world of every version is unique Every version gets Incrementally better. It's always good to actually have some visibility even if you if it's an opaque value It's still a value that changes that means you can tell something is different. Yeah. Good point So what I'm gathering is that the version number is connected to a specific release of that firmware and it's not a Incremental indication of this is the next I guess a serial not necessarily a serial number, but a commit What's the word I'm looking for? A an indication of the serial serially committed versions that have been Committed in that particular Device so you may have skipped a certain number certain Versions released versions of the firmware in that platform But it's it basically an update number of how many times it has been updated on this particular platform No, okay, so it's so it's basically a release number. It's a release number Okay, we have we have a direct relationship between SVN and release number. Okay. Yeah So you're talking about the boot measurements. I wonder if it includes the ufi and if so is how we expected the guest to put the The matter that's measurement in the id block as well So it is it's entirely up. It's so we don't control what actually is measured All the so it's up to the hypervisor and the guest ecosystem to decide How do you load and and and do that initial launch? So it's really up to say You know red hat to decide. Okay, we're gonna launch just the ufi and kernel and and everything else is loaded later And then that launch image is what's actually being measured. So It's entirely up to the ecosystem and the operating system distros to say how they want to To to determine what's what's actually measured in this attestation of work Now that goes to the question of like chaining attestation, right? If you're not going to measure You know user space if you're not going to measure Anything past ufi You need another next step in that chain to measure the rest of it So for one one thing that's been talked about is you measure this SVSM this like Separate module inside the the guest image that contains a virtual TPM and that virtual TPM is used to attest the rest of the way Okay, so the ID So what what the guest put in the ID block should match what the hypervisor is basically put in in the measurement Yeah, I mean since the ID block is controlled by the guest owner and by the image maker The image maker just has to make sure that those measurements inside the ID block match the image Leave that launch image that they're setting up you mentioned The measurements of the firmware include the security version number and so on And that wasn't really in force anyway So the firmware developers can just choose whatever they want the version number that and you just have to assume It's correct if they've signed it correctly and so on And And you also mentioned that the entire point of this in the first place is to work around the concept of a malicious cloud vendor and so on But the way that cloud vendors are deploying hardware these days They typically have access to the source code for the firmware. They might be writing that firmware themselves so Doesn't that undermine the story if they could just release a later version of the firmware that completely undermines the security Good question. So when I when I speak of firmware in this this context, I really mean our sock firmware AMD controls a hundred percent that that code and we sign it and It is our job to make sure that anything that we sign We make sure that we manage the SVNs get incremented correctly. We manage that, you know, the the firmware isn't going to maliciously rollback patches security patches as we increment that SVN Number so it is entirely ours. I think maybe, you know, there's this all all this kind of stuff around x86 firmware Which we don't control so you fee and other things inside of a guest or or inside the host to but Yeah, we we AMD controls that sock firmware Okay, any other questions? All right, thank you very much