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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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