[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [RFC 0/4] Adding Virtual Memory Fuses to Xen
Hi Stefano, On 22/12/2022 00:53, Stefano Stabellini wrote: On Tue, 20 Dec 2022, Demi Marie Obenour wrote:On Tue, Dec 20, 2022 at 10:17:24PM +0000, Smith, Jackson wrote:Hi Stefano, On 16/12/2022 01:46, Stefano Stabellini wrote:On Thu, 15 Dec 2022, Julien Grall wrote:On 13/12/2022 19:48, Smith, Jackson wrote:Yes, we are familiar with the "secret-free hypervisor" work. Asyoupoint out, both our work and the secret-free hypervisor remove the directmap region to mitigate the risk of leaking sensitive guest secrets. However, our work is slightly different because it additionally prevents attackers from tricking Xen into remapping aguest.I understand your goal, but I don't think this is achieved (see above). You would need an entity to prevent write to TTBR0_EL2 in order to fully protect it.Without a way to stop Xen from reading/writing TTBR0_EL2, wecannotclaim that the guest's secrets are 100% safe. But the attacker would have to follow the sequence you outlinesaboveto change Xen's pagetables and remap guest memory beforeaccessing it.It is an additional obstacle for attackers that want to steal otherguests'secrets. The size of the code that the attacker would need to inject in Xen would need to be bigger and more complex.Right, that's why I wrote with a bit more work. However, the nuance you mention doesn't seem to be present in the cover letter: "This creates what we call "Software Enclaves", ensuring that an adversary with arbitrary code execution in the hypervisor STILL cannot read/write guest memory." So if the end goal if really to protect against *all* sort ofarbitrarycode, then I think we should have a rough idea how this will look like inXen.From a brief look, it doesn't look like it would be possible topreventmodification to TTBR0_EL2 (even from EL3). We would need to investigate if there are other bits in the architecture to help us.Every little helps :-)I can see how making the life of the attacker more difficult is appealing. Yet, the goal needs to be clarified and the risk with the approach acknowledged (see above).You're right, we should have mentioned this weakness in our first email. Sorry about the oversight! This is definitely still a limitation that we have not yet overcome. However, we do think that the increase in attacker workload that you and Stefano are discussing could still be valuable to security conscious Xen users. It would nice to find additional architecture features that we can use to close this hole on arm, but there aren't any that stand out to me either. With this limitation in mind, what are the next steps we should take to support this feature for the xen community? Is this increase in attacker workload meaningful enough to justify the inclusion of VMF in Xen?Personally, I don’t think so. The kinds of workloads VMF is usable for (no hypercalls) are likely easily portable to other hypervisors, including formally verified microkernels such as seL4 that provide...What other hypervisors might or might not do should not be a factor in this discussion and it would be best to leave it aside. To be honest, Demi has a point. At the moment, VMF is a very niche use-case (see more below). So you would end up to use less than 10% of the normal Xen on Arm code. A lot of people will likely wonder why using Xen in this case? This suggests a mix of guests are running (some using hypercalls and other not). It would not be possible if you were using VMF.From an AMD/Xilinx point of view, most of our customers using Xen in productions today don't use any hypercalls in one or more of their VMs. Xen is great for these use-cases and it is rather common in embedded. It is certainly a different configuration from what most are come to expect from Xen on the server/desktop x86 side. There is no question that guests without hypercalls are important for Xen on ARM. > As a Xen community we have a long history and strong interest in making Xen more secure and also, more recently, safer (in the ISO 26262 safety-certification sense). The VMF work is very well aligned with both of these efforts and any additional burder to attackers is certainly good for Xen. I agree that we have a strong focus on making Xen more secure. However, we also need to look at the use cases for it. As it stands, there will no: - IOREQ use (don't think about emulating TPM) - GICv3 ITS - stage-1 SMMUv3 - decoding of instructions when there is no syndrome - hypercalls (including event channels) - dom0That's a lot of Xen features that can't be used. Effectively you will make Xen more "secure" for a very few users. I disagree, I think this is also about use cases. On the paper VMF look very great, but so far it still has a big flaw (the TTBR can be changed) and it would restrict a lot what you can do.Now the question is what changes are necessary and how to make them to the codebase. And if it turns out that some of the changes are not applicable or too complex to accept, the decision will be made purely from a code maintenance point of view and will have nothing to do with VMs making no hypercalls being unimportant (i.e. if we don't accept one or more patches is not going to have anything to do with the use-case being unimportant or what other hypervisors might or might not do). To me, if you can't secure the TTBR, then there are other way to improve the security of Xen for the same setup and more. The biggest attack surface of Xen on Arm today are the hypercalls. So if you remove hypercalls access to the guest (or even compile out), then there is a lot less chance for an attacker to compromise Xen. This is not exactly the same guarantee as VMF. But as I wrote before, if the attacker has access to Xen, then you are already doomed because you have to assume they can switch the TTBR. Cheers, -- Julien Grall
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |