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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 23/01/18 08:36, Jan Beulich wrote:
>>>> On 22.01.18 at 20:02, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 22/01/18 18:48, George Dunlap wrote:
>>> On 01/22/2018 06:39 PM, Andrew Cooper wrote:
>>>> Jan: As to the things not covered by the current XPTI, hiding most of
>>>> the .text section is important to prevent fingerprinting or ROP
>>>> scanning.  This is a defence-in-depth argument, but a guest being easily
>>>> able to identify whether certain XSAs are fixed or not is quite bad. 
>>> I'm afraid we have a fairly different opinion of what is "quite bad".
>> I suggest you try talking to some real users then.
>>
>>> Suppose we handed users a knob and said, "If you flip this switch,
>>> attackers won't be able to tell if you've fixed XSAs or not without
>>> trying them; but it will slow down your guests 20%."  How many do you
>>> think would flip it, and how many would reckon that an attacker could
>>> probably find out that information anyway?
>> Nonsense.  The performance hit is already taken.  The argument is "do
>> you want an attacker able to trivially evaluate security weaknesses in
>> your hypervisor", a process which usually has to be done by guesswork
>> and knowing the exact binary under attack.  Having .text fully readable
>> lowers the barrier to entry substantially.
> I neither agree with George's reply being nonsense, nor do I think
> this is an appropriate tone. _Some_ performance hit is already
> taken. Further hiding of information my incur further loss of
> performance, or are you telling me you can guarantee this never
> ever to happen? Additionally, the amount of "guesswork" may
> heavily depend on the nature of a specific issue. I can imagine
> cases where such guesswork may even turn out easier than using
> some side channel approach like those recent ones.
>
> As indicated earlier, I'm not fundamentally opposed to hiding
> more things, but I'm also not convinced we should hide more stuff
> regardless of the price to pay.

Here is an example which comes with zero extra overhead.

Shuffle the virtual layout to put .text adjacent to MMCFG, and steal
some space (1G?) from the top of MMCFG for .entry.text and the per-cpu
stubs.  With some linker adjustments, relative jumps/references will
even work properly.

Anyone serious about security is not going to be happy with XPTI in its
current form, because being able to arbitrarily read .text is far too
valuable for an attacker.  Anyone serious about performance will turn
the whole lot off.

In some theoretical world with three options, only a fool would choose
the middle option, because a 10% hit is not going to be chosen lightly
in the first place, but there is no point taking the hit with the
reduced security.

~Andrew

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