# Initial state of the CPU on AMD ###### tags: `Instructions` ## Problem definition The attestation of the workload includes the CPU state information. When the workload that was running in the AMD keep exits, the system stores the state in the special area (VMSA). When the workload is started again, it loads the state back. This is a well-defined process and works. The initial state, however, needs to be better defined. Currently, it is defined by Kernel without userspace knowledge or ability to influence. As a result, Enarx does not know the initial state and has to guess. If it guesses right the attestation would include the correct data and everything would check out. If Enarx guesses wrong the attestation of the workload would be incorrect. VMSA **MUST** be public, since all parties need to agree on it. So the kernel choosing this information on its own and making everyone guess is unexpected behavior. There are two questions: 1. Who chooses the initial state? 2. How is the initial state communicated to all other parties? If the kernel chooses the initial state, it MUST communicate it to userspace. But this makes the process fragile. Every kernel version might choose a different initial state. So this is very bad for implementation stability. Our preferred approach is that userspace chooses the initial value and communicates it to the kernel (and other parties). The kernel can still choose to reject this initial state if it doesn't like it. But userspace gets more stability this way. ## The requirement * The Kernel should have a way for the user space to provide input regarding the initial state. The kernel might reject requests from the user space if the request does not meet the criteria that Kernel defines. But there must be a way for the userspace to define it. * Kernel must publicly communicate the state it set (returning the corrected VMSA?). * Kernel should rarely (never?) change its mind about what it rejects. ## Requested Action - We must propose Kernel changes to AMD to address the situation and allow userspace to influence the parameters of the initial state. - The Kernel must provide a way for user space to know the initial state that Kernel has chosen based on the userspace request. ## Requested Action for AMD SEV-ES firmware - Ideally we don't need a VMSA measurement by the firmware, but a special `LAUNCH_UPDATE_VMSA_RESET_VECTOR` command with `SEV_FEATURES` and `VINTR_CTRL` as parameters (which will get measured). The firmware will overwrite the inital VMSA with its reset vector VMSA version and will add the `SEV_FEATURES` and `VINTR_CTRL`. So, it shouldn't make a difference what initial VMSA the kernel provides, the firmware would choose its own and this will keep the kernel out of the whole game.