Re: [Xen-devel] [PATCH RFC v2 00/12] xen/x86: use per-vcpu stacks for 64 bit pv domains

[Juergen Gross <jgross@xxxxxxxx>]

On 22/01/18 15:22, Jan Beulich wrote:
>>>> On 22.01.18 at 15:18, <jgross@xxxxxxxx> wrote:
>> On 22/01/18 13:50, Jan Beulich wrote:
>>>>>> On 22.01.18 at 13:32, <jgross@xxxxxxxx> wrote:
>>>> As a preparation for doing page table isolation in the Xen hypervisor
>>>> in order to mitigate "Meltdown" use dedicated stacks, GDT and TSS for
>>>> 64 bit PV domains mapped to the per-domain virtual area.
>>>>
>>>> The per-vcpu stacks are used for early interrupt handling only. After
>>>> saving the domain's registers stacks are switched back to the normal
>>>> per physical cpu ones in order to be able to address on-stack data
>>>> from other cpus e.g. while handling IPIs.
>>>>
>>>> Adding %cr3 switching between saving of the registers and switching
>>>> the stacks will enable the possibility to run guest code without any
>>>> per physical cpu mapping, i.e. avoiding the threat of a guest being
>>>> able to access other domains data.
>>>>
>>>> Without any further measures it will still be possible for e.g. a
>>>> guest's user program to read stack data of another vcpu of the same
>>>> domain, but this can be easily avoided by a little PV-ABI modification
>>>> introducing per-cpu user address spaces.
>>>>
>>>> This series is meant as a replacement for Andrew's patch series:
>>>> "x86: Prerequisite work for a Xen KAISER solution".
>>>
>>> Considering in particular the two reverts, what I'm missing here
>>> is a clear description of the meaningful additional protection this
>>> approach provides over the band-aid. For context see also
>>> https://lists.xenproject.org/archives/html/xen-devel/2018-01/msg01735.html 
>>
>> My approach supports mapping only the following data while the guest is
>> running (apart form the guest's own data, of course):
>>
>> - the per-vcpu entry stacks of the domain which will contain only the
>>   guest's registers saved when an interrupt occurs
>> - the per-vcpu GDTs and TSSs of the domain
>> - the IDT
>> - the interrupt handler code (arch/x86/x86_64/[compat/]entry.S
>>
>> All other hypervisor data and code can be completely hidden from the
>> guests.
> 
> I understand that. What I'm not clear about is: Which parts of
> the additionally hidden data are actually necessary (or at least
> very desirable) to hide?

Necessary:
- other guests' memory (e.g. physical memory 1:1 mapping)
- data from other guests e.g.in stack pages, debug buffers, I/O buffers,
  code emulator buffers
- other guests' register values e.g. in vcpu structure

Desirable: as much as possible. For instance I don't buy your reasoning
regarding the Xen binary: how would you do this e.g. in a public cloud?
How do you know which Xen binary (possibly with livepatches) is being
used there? And today we don't have something like KASLR in Xen, but
not hiding the text and RO data will make the introduction of that quite
useless.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel