[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 2/6] x86/boot: Map the trampoline as read-only



On 07.01.2020 20:04, Andrew Cooper wrote:
> On 07/01/2020 16:19, Jan Beulich wrote:
>> On 07.01.2020 16:51, Andrew Cooper wrote:
>>> On 07/01/2020 15:21, Jan Beulich wrote:
>>>> On 06.01.2020 16:54, Andrew Cooper wrote:
>>>>> c/s ec92fcd1d08, which caused the trampoline GDT Access bits to be set,
>>>>> removed the final writes which occurred between enabling paging and 
>>>>> switching
>>>>> to the high mappings.  There don't plausibly need to be any memory writes 
>>>>> in
>>>>> few instructions is takes to perform this transition.
>>>>>
>>>>> As a consequence, we can remove the RWX mapping of the trampoline.  It is 
>>>>> RX
>>>>> via its identity mapping below 1M, and RW via the directmap.
>>>>>
>>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>>> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
>>>>
>>>>> This probably wants backporting, alongside ec92fcd1d08 if it hasn't yet.
>>>> This is just cleanup, largely cosmetic in nature. It could be argued
>>>> that once the directmap has disappeared this can serve as additional
>>>> proof that the trampoline range has no (intended) writable mappings
>>>> anymore, but prior to that point I don't see much further benefit.
>>>> Could you expand on the reasons why you see both as backporting
>>>> candidates?
>>> Defence in depth.
>>>
>>> An RWX mapping is very attractive for an attacker who's broken into Xen
>>> and is looking to expand the damage they can do.
>> Such an attacker is typically in the position though to make
>> themselves RWX mappings.
> 
> This is one example of a possibility.  I wouldn't put it in the "likely"
> category, and it definitely isn't a guarantee.
> 
>>  Having as little as possible is only
>> complicating their job, not making it impossible, I would say.
> 
> Yes, and?
> 
> This is the entire point of defence in depth.  Make an attackers job harder.
> 
> Enforcing W^X is universally considered a good thing from a security
> perspective, because it removes a load of trivial cases cases where a
> stack over-write can easily be turned into arbitrary code execution.

Then let me ask the question differently: Did we backport any of the
earlier RWX elimination changes? I don't recall us doing so. Please
don't get me wrong - I'm happy to be convinced of the backport need,
but as always I'd like to take such a decision in a consistent (and
hence sufficiently predictable) manner, or alternatively with a good
enough reason to ignore this general goal.

Jan

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.