[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |