[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 1/2] x86/xpti: really hide almost all of Xen image
>>> On 02.03.18 at 17:53, <andrew.cooper3@xxxxxxxxxx> wrote: > On 02/03/18 14:34, Jan Beulich wrote: >> Note that the removed BUILD_BUG_ON()s don't get replaced by anything - >> there already is a suitable ASSERT() in xen.lds.S. > > This isn't quite true. You've changed the mechanism by which the stubs > get mapped (from entirely common, to per-pcpu), removing the need for > the BUILD_BUG_ON(). > > The ASSERT() in xen.lds.S serves a different purpose, checking that the > sum total of stubs don't overlap with the compiled code. (On this > note... do we perform the same check for livepatches? I can't spot > anything.) What you say may be true for the one that was in setup_cpu_root_pgt(), but surely not the one I'm removing from alloc_stub_page(). But I can drop this if you prefer. >> What should we do with the TSS? Currently together with it we expose >> almost a full page of other per-CPU data. A simple (but slightly >> hackish) option would be to use one of the two unused stack slots. > > In 64bit, the TSS can be mapped read-only, because hardware never has > cause to write to it. > > I believe that Linux now uses a read-only TSS mapping to double as a > guard page for the trampoline stack, which is a less hacky way of > thinking about it. > > However, doing that in Xen would mean shattering the directmap > superpages in all cases, and we'd inherit the SVM triple fault case into > release builds. A different alternative (and perhaps simpler to > backport) might be to have .bss.percpu.page_aligned and use that to hide > the surrounding data. Well, yes, that's obviously an option, but pretty wasteful. I'd then be tempted to at least do some sharing of the page similar to how the stubs of several CPUs share a single page. > Thinking about it, we've got the same problem with the TSS as the BSP > IDT, if the link order happens to cause init_tss to cross a page boundary. I don't think so, no - the structure is 128 bytes in size and 128 byte aligned. When I created the original XPTI light patch I did specifically check. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |