>>> On 19.01.18 at 16:43, <george.dun...@citrix.com> wrote: > On 01/19/2018 02:37 PM, Jan Beulich wrote: >> All, >> >> along the lines of the relatively easy first step submitted yesterday, >> I've had some further thoughts in that direction. A fundamental >> thing for this is of course to first of all establish what kind of >> information we consider safe to expose (in the long run) to guests. >> >> The current state of things is deemed incomplete, yet despite my >> earlier inquiries I haven't heard back any concrete example of >> information, exposure of which does any harm. While it seems to be >> generally believed that large parts of the Xen image should not be >> exposed, it's not all that clear to me why that would be. I could >> agree with better hiding writable data parts of it, just to be on the >> safe side (I'm unaware of statically allocated data though which >> might carry any secrets), but what would be the point of hiding >> code and r/o data? Anyone wanting to know their contents can >> simply obtain the Xen binary for their platform. > > This tails into a discussion I think we should have about dealing with > SP1, and also future-proofing against future speculative execution attacks. > > Right now there are "windows" through which people can look using SP1-3, > which we are trying to close. SP1's "window" is the guest -> hypervisor
I think you mean SP3 here. > virtual address space (hence XPTI, separating the address spaces). > SP2's "window" is branch-target-poisoned gadgets (hence using retpoline > and various techniques to prevent branch target poisoning). SP1's > "window" is array boundary privilege checks, hence Linux's attempts to > prevent speculation over privilege checks by using lfence or other > tricks[1]. > > But there will surely be more attacks like this (in fact, there may > already be some in the works[2]). > > So what if instead of trying to close the "windows", we made it so that > there was nothing through the windows to see? If no matter what the > hypervisor speculatively executed, nothing sensitive was visibile except > what a vcpu was already allowed to see, I think you didn't finish your sentence here, but I also think I can guess the missing part. There's a price to pay for such an approach though - iterating over domains, or vCPU-s of a domain (just as an example) wouldn't be simple list walks anymore. There are certainly other things. IOW - yes, and approach like this seems possible, but with all the lost performance I think we shouldn't go overboard with further hiding. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel