Hello everyone, On 7/12/23 1:14 AM, Reshetova, Elena wrote: >> On Tue, Jul 11, 2023 at 09:12:57AM -0500, Carlos Bilbao wrote: >>> Kernel developers working on confidential computing for virtualized >>> environments in x86 operate under a set of assumptions regarding the Linux >>> kernel threat model that differs from the traditional view. Historically, >>> the Linux threat model acknowledges attackers residing in userspace, as >>> well as a limited set of external attackers that are able to interact with >>> the kernel through networking or limited HW-specific exposed interfaces >>> (e.g. USB, thunderbolt). The goal of this document is to explain additional >>> attack vectors that arise in the virtualized confidential computing space >>> and discuss the proposed protection mechanisms for the Linux kernel. >> >> When you have a "and" in a changelog text, that's a huge hint that it >> needs to be split up into multiple patches. >> >> And that's the case here, you want to do two things, describe your crazy >> model of different attack vectors AND propose new ways to protect from >> them. > > Actually if you read the full doc we are not proposing *yet* any *concrete* new > mechanisms of protecting against these attack vectors that would require > kernel patches. These are indeed going to come later with the code changes > as you highlight below. What we *do* discuss below is high-level mitigation > strategies that wont make sense to include in the actual patches, because > some of these mitigations wont need *any* new patches to linux. For example, > the first attack we have is " Guest malicious configuration", where the > misbehaving host modifies one of the guest's configuration (kernel binary, > command line, etc). The general mitigation for this attack vector is a way > to authenticate/attest this configuration and it is mostly transparent for the > kernel. So, we either need to drop this attack description fully form the doc > (and this would result in questions from people not familiar with CoCo: why > do you try to harden the kernel apis when you don’t describe how kernel > binary integrity is protected), or we leave it in for an overall picture to provide > context and justify the overall reasoning. > > That said we can rewrite the sentence that you commented upon not to create > confusion (I do agree it can be misinterpreted the way you pointed out): > > "The goal of this document is to explain additional > attack vectors that arise in the virtualized confidential computing space, > as well as highlight the overall mitigation strategies that can used > to address them. > The concrete mechanisms, if determined needed for Linux, > will be described in the future extensions of this document, together with the > code that implements them". > > Does this address your concern? I'm writing to re-ping the email thread and kindly request any additional comments or feedback from the list. The issue that Greg raises is whether we should discuss and cover high-level mitigation strategies _before_ we start pushing code. In addition to Elena's response, I would like to point out that a document that explains our agreements on the high-level mitigation strategies would serve as reference when the time comes to discuss concrete code mitigation strategies. Saidd foundation would avoid explanations and repetitive discussions whenever the code arrives. More importantly, it would relieve the individual confidential computing contributors from the burden of discussing the rationale behind their solution all the way down to the very basic ideas of confidential computing within our context. Greg, I would like to know if Elena's reasoning has addressed your concerns. If you still have concerns/doubts with this approach, please do let us know. > > Best Regards, > Elena Thanks, Carlos
