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

Re: [Xen-devel] NULL pointers and PV guests.



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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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