Re: [Xen-devel] [PATCH 8/8] libelf: safety: Document safety principles in header file

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

George Dunlap writes ("Re: [PATCH 8/8] libelf: safety: Document safety 
principles in header file"):
> > On Dec 16, 2016, at 12:43 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> > As expressed before, I'm not convinced library code should be
> > concerned about caller restrictions.

I'm not sure what you mean by "caller restrictions".  This is a rule
that applies inside libelf.  Can you explain ?

Assuming you mean what George seems to think you meant:

> People designing toolstacks that call this function are likely to be thinking 
> about domains and things, not, “What happens if I get a rogue elf image that 
> causes this function to run forever?”  I think if we can prevent 
> libelf-source DoS bugs in all toolstacks that rely on libxl, then it makes 
> sense to do so.

I think in fact the only caller of libelf is libxc.  I doubt we have
out-of-tree callers, but I could be wrong of course.

But that doesn't change the underlying point, which I agree with:
callers of any library should be given information on how to use it
safely.

Our libelf does not have a 100% opaque interface for its callers.  For
example, the state struct is transparent, and the multiple entry
points are not entirely clearly set out.

If it did have a more formally defined and opaque interface, then much
of what is currently in libelf.h (including this comment) would be in
libelf-private.h instead.

Thanks,
Ian.

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