From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: NULL pointers and PV guests. Date: Thu, 26 Mar 2015 16:44:22 +0000 Message-ID: <55143766.3050605@citrix.com> References: <20150326162319.GK6519@deinos.phlegethon.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150326162319.GK6519@deinos.phlegethon.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tim Deegan , xen-devel@lists.xen.org Cc: Keir Fraser , David Vrabel , Jan Beulich , Boris Ostrovsky , bouyer@antioche.eu.org List-Id: xen-devel@lists.xenproject.org On 26/03/15 16:23, Tim Deegan wrote: > Hi, > > After XSA-109 (a null function-pointer dereference) we've been > thinking about things we can do to make null pointers less dangerous > in PV guests. This is a problem for pure PV only - when Xen is > running HVM and PVH guests null pointer dereferences will fault. > > [ Disclaimer: it's sadly clear that I'm not going to have time to work > on any of these ideas myself. :( But we could at least put them on > the wish list. ] > > Idea 1: track PV pagetables so that we can tell which pagetables > might map the zero address -- e.g. by adding a flag or new types at > each level to indicate that we've seen this pagetable referenced > from slot zero of a higer-level pagetable that also has the flag set. > Then we could refuse any potential mapping of the bottom virtual 4k. > > This is probably OK as a general feature because most PV OSes will > want to keep the bottom 4k free so that their own null pointers work. > But it would potentially mean that the guest couldn't alias the same > L1/2/3 pagetable at address 0 and some other address. > > Linux/BSD people, can you comment on how likely that is to be a > problem? Is it totally mad? While this would be a very good idea (as would preventing mappings on the boundaries of the canonical region), such a change would break all minios based guests which start .text at 0 As a result I don't think this is a feasible option, although it might be a very good idea to have an opt-in restriction for guests which actively wish to play nice. > > Idea 2: manually audit and fix all structs of function pointers > in Xen so that they always point to one of: > - a useful function; > - a noop stub (for cases where we currently test for != NULL); or > - a function that calls BUG(). > That seems like it would be a good idea, but it only helps for > functions and not for data pointers, and we might easily introduce > more null function pointers in new code. > > Idea 3: #2 plus some sort of preprocessor wrappers (like we > have for guest handles or gfn_ts) to help us maintain discipline. > Uglier, but maybe better? > > Idea 4: build-time support, with something like a clang analysis > pass or coccinelle, for finding uninitialised function pointers, > or for automatically inserting checks on indirect jumps. > Anyone know of existing tools that could help here? I have looked into coccinelle before, and it sadly cant parse our XEN_GUEST_HANDLE() constructs, which causes it to ignore the rest of the translation unit. It would be nice if someone who spoke more Ocaml than me fixed their C parser, as spatch itself is a very useful tool. Independently of fixing the NULL pointer issue, attempting to get the clang analysis running would be a very good thing. > > Anything else we should consider? I have also tried experimenting with sparse, and also come to the conclusion that it is a lot of work. (First and foremost fixing sparse so it understands C11's _StaticAssert(), or hopefully some kind person has already done this since I last checked.) ~Andrew