Re: [Xen-devel] [PATCH v4 5/9] tools/libxc: common code

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2014-05-07 at 17:30 +0100, Andrew Cooper wrote:
> >
> >>>> @@ -0,0 +1,431 @@
> >>>> +#include <assert.h>
> >>>> +
> >>>> +#include "common_x86_pv.h"
> >>>> +
> >>>> +xen_pfn_t mfn_to_pfn(struct context *ctx, xen_pfn_t mfn)
> >>>> +{
> >>>> +    assert(mfn <= ctx->x86_pv.max_mfn);
> >>> Just to confirm that anywhere there is an assert like this then if it is
> >>> based on potentially user controller input then it has already been
> >>> validated elsewhere first? (with the abstraction I couldn't spot where
> >>> that was)
> >> It is validated in every case I am aware of, usually by
> >> "mfn_in_pseudophysmap()"
> > Good, because it would be a security issue if not...
> 
> In what way?  The absolute worst that could happen is a controlled stop
> of the process handling migration for this domain.

AKA the toolstack daemon, which would be a DoS depending on the
toolstack's architecture.

> 
> >
> >>>> ... normalize_page
> >>>> +    local_page = malloc(PAGE_SIZE);
> >>> How bad is the overhead of (what I pressume are) all these allocs and
> >>> frees? (I've not come across the caller in this patch, maybe it will
> >>> become clear later).
> >>>
> >>> Would it be worth keeping an array around shadowing the "live" batch of
> >>> pages?
> >> The allocation and freeing of pages has allowed valgrind to be
> >> fantastically useful at pointing out when my code was doing something 
> >> silly.
> > Fair enough (I wonder if there is some valgrind mechanism for marking
> > memory as explicitly uninitialised as if it had been freed/reallocated)
> 
> I have searched but cant find anything.  As valgrind is designed to wrap
> compiled binaries, making function calls into it is probably non-trivial.

It was a long shot...

I was imagining you'd have to have a local
        void valgrind_invalidate(void *p) {}
which valgrind would trap calls to in its usual way "somehow"

Ian.


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