-
Notifications
You must be signed in to change notification settings - Fork 12
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
Pick a name #8
Comments
I think kbs is a hardware irrelevant component and it acts as the term "relaying party" according to RATS arch. Instead, what is really communicating with KBC to directly or indirectly retrieve the evidence (yes, this is only case where a runtime attestation procedure uses) is "verifier". From a long term, it is better to separate them. kbs is a specific instance of relaying party, which might be vendor-specific, and it is highly related to business and use case. "verifier" can be a layered design: the upper layer is general (with an appraisal policy engine), and the lower is hardware TEE vendor-specific (Intel PCS/PCCS, AMD KDS). If the lower is implemented by a set of low level verifier drivers for various hardware TEE platforms (sgx, tdx, snp and so on) with proper encapsulation, the entire "verifier" can be general. I suggest we can share a general "verifier" which encapsulates all possible low level verifier drivers with modulization design. Verdictd can be a candidate of "verifier". |
Yes, in general I think it's a good idea to separate the attestation server from the platform-specific logic that validates launch information. Ideally the attestation server will be modular just like the attestation agent. There are a couple of different ways to break it down, but I think what you're saying is that there is
I think this is a pretty good way of thinking about it. This kbs is so simple that I didn't bother to separate out the different components. In fact it is mainly focused on policy validation, which I felt was missing from some of the existing options. I think it is a good idea to minimize code duplication, especially at the lowest level. |
typo? implements the API that talks to "KBC"? |
I think there are several functions that KBS / AS needs to implement from a long term:
|
What is the scope of the KBS here? and what is the architecture design for KBS? without the scope/goal and architecture design agreed by community, it is hard to understand the issue here. From our experience of KBS implementation, KBS needs to deal with key policy management, different types of attestation, and support different kinds of KMS (very user and CSP specific). and there are quite a few KBS implementations out there. why cannot we point to existing implementations, but create a new project to reimplement? |
It seems this conversation is drifting into an architectural one, although we're only looking for a name that reflects more accurately the scope of this new code base :-) There are clearly some interesting proposals as to how we could architect a attestation/secret/key backend for CC here, and I think this is not really the current scope of Now, to get back to the topic of that issue (remember, renaming the project :-)), I would characterise the proposed code as:
The name we want to pick should not be too specific in order to allow for extending that code base to e.g. support SEV-SNP or SE without having to rename it again. But we'd want it to be less generic in order to not confuse people as to what the scope of this project is.
Feel free to add more, or pick one and let's move on :) I'd much rather spend my time discussing architectural proposals for a generic KBS in CC and/or seeing code contributions to that repo. (whatever the name is)... |
I think |
|
|
still, I am not sure what we are trying to achieve here, and what is the governance process to add code/example in CC. without good understanding, it is hard to recommend a name. If CC decides to need a KBS, we should go through design process/definition of the goal, similar as other components such as ocicrypt-rs, image-rs, KBC, etc. |
@hdxia The basic idea with this project is straightforward. It provides a component that is required to use CC with SEV(-ES). Pre-attestation has been out of scope for any of the existing attestation options. When we first setup CC with SEV we provided some python scripts that served a similar purpose, so the basic functionality has been known about for a long time. We wanted to improve those scripts and find a good place to host them. This is the result. The goal is not to create an official or general KBS and it isn't to compete with any other offerings. That said, I don't want to completely lock-in the scope because there may be some improvements like support for online attestation for SEV(-ES) and Secure Execution with encrypted images. Honestly, I think the scope of this project is simple. The real ambiguity comes from the fact that the broader attestation picture is not yet clear. For example, the solutions for SEV-SNP attestation are still emerging. I don't want to completely rule out SNP support in this project yet because we're only just starting to see what the other options look like. That said, I don't personally plan on working on SNP support here anytime soon and I am fully committed to finding a solution that works best for the whole community. I fully agree that we need should have a rigorous community design process (see Samuel's issue) if we want to develop an official KBS/AS. That is not the goal of this project. This isn't so much like |
@fitzthum I think the intention is good, but simple is not that simple to me, but complicated. if this becomes part of CC, it needs to be maintained by CC and every code change needs to be reviewed. however, it will fail and go wild without any design/agreement from the community. if it stays in its own repo and referred by CC, the maintainer can do what they need. |
@hdxia I guess I just don't see this project being as popular as all that. The init code does most of what we need. I've made some issues regarding a few future improvements. I don't really foresee a massive amount of other development in the near future. It seems like it should be relatively easy to maintain. If some random person comes with a huge PR that complicates things, we will stop and discuss it in the broader context of the community. |
I agree with @fitzthum here. Compared with existing implementation, those few hundreds lines of rust code for a complete KBS is arguably simple. As a project, we should discuss if we want to implement and support something more generic, complex and supporting many protocols and hardware implementations through confidential-containers/documentation#26 |
@hdxia your argument regarding code maintenance is a valid concern, but falls a bit outside of the scope of this discussion. Perhaps by establishing the project's scope, and then finding a matching name will help to ease concerns about maintainability? I think |
@sameo @fitzthum @hdxia If we are targeting to implement a sample-kbs, it should be simple enough without so many features to describe. About sample-kbs, AA has already one: https://github.com/confidential-containers/attestation-agent/tree/main/sample_kbs It proves how a hardware-irrelevant kbs is possibly communicated with kbc to provide the connection with attestation-agent. More specific, the specific hardware support such as SEV-ES should not be part of sample-kbs. It should go the general kbs/product/sev-specific implementation (to be discussed in confidential-containers/documentation#26 ). Even pre-attestation is unique, but it doesn't mean it cannot be described as runtime attestation with a high level design. I think the function scope and naming of this project should match up. The features described above sounds more like a general kbs and it just provides the first support for SEV-ES TEE. If so, I would vote keep kbs-rs without renaming it. Otherwise, sample-kbs should be simple, generic, essential and hardware-irrelevant. In summary, once we are trying to fill more things into sample-kbs, it will tend to talk about a general attestation service/kbs IMO. |
@jiazhang0 The sample KBS in AA has a different purpose (and should maybe be renamed). That sample KBS implements the But the proposal here is to change the name to As you say, a general KBS could support pre-attestation, but as I understand it none of the current general-purpose offerings do. Adding support for pre-attestation would increase complexity even more and I think it is probably wise to focus a general KBS only on platforms that do runtime attestation. As long as we can come to some agreement on a general KBS, I don't think there would be any need to add support for runtime attestation here. |
Oops! I didn't recognize it sorry.
I agree on its position. The following statements looks out-of-scope of simple-kbs:
But I understand your contradiction point, as you mentioned, which is caused by
Agreed. Getting some agreement on a general KBS would be helpful to define the scope of this project. Otherwise, this project will need to support more hardware platforms for the same purpose as you currently mentioned for SEV(-ES) platform, and by then the scope of project will be re-discussed again. About how to handle pre-attestation in a same manner with runtime attestation, I have some ideas. But currently it is not the moment. |
Ok it seems like I want to reiterate that this not a hugely ambitious project. I know some people might be skeptical about that, but I can at least guarantee that I don't have time to do anything more ambitious than what I have already outlined. Like I said, if other people want to reshape the scope of the project, we will step on the brakes and make sure that it fits with the community. |
kbs-rs
is a relatively generic name. This is not supposed to be the "official" attestation server for CC and it currently has a relatively narrow scope. Maybe we should pick a name that is less generic. On the other hand, the project is probably going to grow at least a little bit so we should choose a name that does not limit this or cause confusion in the future.Specifically, we are thinking about supporting an online kbc/kbs for SEV(-ES) and maybe supporting this online approach via an encrypted image for Secure Execution. None of the other attestation servers support either of these options. We have also talked about supporting SNP and maybe even TDX, but we don't have any concrete plans for this. EAA/Verdictd already supports these platforms. I don't yet know the best path forward for SNP.
I am not attached to the current name, so if we can think of something that is a bit less generic while still being somewhat flexible, I am all for it. On the other hand, if we are clear about purpose and scope elsewhere in the project, maybe the name doesn't really matter that much.
The text was updated successfully, but these errors were encountered: