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

[George Dunlap <dunlapg@xxxxxxxxx>]

On Fri, Jan 5, 2018 at 9:39 AM, Juergen Gross <jgross@xxxxxxxx> wrote:
> 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.

Here's a question:  What if we didn't try to prevent the guest from
reading hypervisor memory at all, but instead just tried to make sure
that there was nothing of interest there?

If sensitive information pertaining to a given vcpu were only maped on
the processor currently running that vcpu, then it would mitigate not
only SP3, but also SP2 and SP1.

 -George

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