Re: [Xen-devel] [PATCH v2 1/2] x86/xpti: really hide almost all of Xen image

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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