Re: [Xen-devel] [PATCH FAIRLY-RFC 00/44] x86: Prerequisite work for a Xen KAISER solution

[Juergen Gross <jgross@xxxxxxxx>]

On 05/01/18 10:26, Andrew Cooper wrote:
> On 05/01/2018 07:48, Juergen Gross wrote:
>> On 04/01/18 21:21, Andrew Cooper wrote:
>>> This work was developed as an SP3 mitigation, but shelved when it became 
>>> clear
>>> that it wasn't viable to get done in the timeframe.
>>>
>>> To protect against SP3 attacks, most mappings needs to be flushed while in
>>> user context.  However, to protect against all cross-VM attacks, it is
>>> necessary to ensure that the Xen stacks are not mapped in any other cpus
>>> address space, or an attacker can still recover at least the GPR state of
>>> separate VMs.
>> Above statement is too strict: it would be sufficient if no stacks of
>> other domains are mapped.
> 
> Sadly not.  Having stacks shared by domain means one vcpu can still
> steal at least GPR state from other vcpus belonging to the same domain.
> 
> Whether or not a specific kernel cares, some definitely will.
> 
>> I'm just working on a proof of concept using dedicated per-vcpu stacks
>> for 64 bit pv domains. Those stacks would be mapped in the per-domain
>> region of the address space. I hope to have a RFC version of the patches
>> ready next week.
>>
>> This would allow to remove the per physical cpu mappings in the guest
>> visible address space when doing page table isolation.
>>
>> In order to avoid SP3 attacks to other vcpu's stacks of the same guest
>> we could extend the pv ABI to mark a guest's user L4 page table as
>> "single use", i.e. not allowed to be active on multiple vcpus at the
>> same time (introducing that ABI modification in the Linux kernel would
>> be simple, as the Linux kernel currently lacks support for cross-cpu
>> stack exploits and when that support is being added by per-cpu L4 user
>> page tables we could just chime in). A L4 page table marked as "single
>> use" would map the local vcpu stacks only.
> 
> For PV guests, it is the Xen stacks which matter, not the vcpu guest
> kernel's ones.

Indeed. That's the reason I want to have per-vcpu Xen stacks.

> 64bit PV guest kernels are already mitigated better than KPTI can ever
> manage, because there are no entry stacks or entry stubs required to be
> mapped into guest userspace at all.

But without Xen being secured via a mechanism similar to KPTI this
is moot, as user mode can exploit the whole host including the own
kernel's memory.


Juergen

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