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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan


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