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

[Tim Deegan <tim@xxxxxxx>]

Hi,

At 10:31 -0400 on 30 Mar (1427711518), Konrad Rzeszutek Wilk wrote:
> On Thu, Mar 26, 2015 at 04:23:19PM +0000, Tim Deegan wrote:
> > 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.

That's about the answer I expected. :)

Between that and needing to have an opt-out for minos/mirage/&c this
line isn't worth pursuing.

> > 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?

I think that between the xen project's coverity runs and other private
instances, we're getting everything we can out of coverity already.

I might have a look at other options in my copious free time -
I know it's possible to find indirect calls with an LLVM pass;
extending that to insert automatic NULL checks would be doable (but
only work if compiled with the right toolchain, of course).  Testing
for existing NULL checks might be more useful.

Cheers,

Tim.

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