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 2:17 PM, Juergen Gross <jgross@xxxxxxxx> wrote:
> On 05/01/18 15:11, George Dunlap wrote:
>> 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.
>
> You are aware this includes the mappings when running in the hypervisor?
> So i.e. the mapping of physical memory of the host...

Yes, of course.  You'd have to map domain memory on-demand, and make
sure it was unmapped before switching to a different domain.  (And in
the case of 64-bit PV guests, before switching back to guest space.)
And you'd have to try to identify as much 'sensitive' information as
possible and move it out of the xen-wide domain heap, into per-domain
structures.

We already have map_domain_page(), as a result of 32-bit mode and
>5TiB mode, so getting the domain pages out of the HV should be pretty
easy.

 -George

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