Re: NULL pointers and PV guests.

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Thu, Mar 26, 2015 at 04:23:19PM +0000, 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?

I would stay away from any pagetables manipulation as much as possible
in Linux. Linus is already unhappy with the SHARED_PMD flag being
disabled when running under Xen and wants to eliminate that.

The less (or none) that we touch in Linux pagetables the better.
> 
> 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?

Could Coverity help here?
> 
> Anything else we should consider?
> 
> Cheers,
> 
> Tim.