Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature]: AMD CPU state attestation #6

Open
1 task done
rvolosatovs opened this issue Nov 25, 2022 · 1 comment
Open
1 task done

[Feature]: AMD CPU state attestation #6

rvolosatovs opened this issue Nov 25, 2022 · 1 comment
Assignees
Labels
attestation Issues related to attestation enhancement New feature or request

Comments

@rvolosatovs
Copy link
Member

Is there an existing issue for this?

  • I have searched the existing issues

Description

From https://hackmd.io/zx6x0HHrTeuSvf8r9OhG5w

The attestation of the workload includes the CPU state information.
When the workload 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:

Who chooses the initial state?
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.

Acceptance Criteria

  • 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.

Suggestions for a technical implementation

  • 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.
@rvolosatovs rvolosatovs added the enhancement New feature or request label Nov 25, 2022
@rvolosatovs rvolosatovs transferred this issue from enarx/enarx Nov 25, 2022
@rvolosatovs
Copy link
Member Author

A follow-up shim work will be required in https://github.com/enarx/enarx

@dpal dpal added the attestation Issues related to attestation label Dec 1, 2022
@dpal dpal moved this from Scheduled (this sprint) to Priority (Epic) in Enarx Board Jan 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
attestation Issues related to attestation enhancement New feature or request
Projects
Status: Priority (Epic)
Development

No branches or pull requests

5 participants