tools/libs/*: Introduce APIs to restrict handles to a specific domain.

tools/libs/*: Introduce APIs to restrict handles to a specific domain.

These are intended to allow user space processes (in particular QEMU)
to lock down all the handles at start of day and then drop the
privileges which would allow them to open any new unrestricted handles
(e.g. setuid or similar). This will reduce the privileges which taking
over such a process would gain an attacker wrt other domains in the
system.

These are currently unimplemented on all platforms, however the API
semantics are defined as the basis for discussion, and so that
consumers can rely on this interface always having been present rather
than requiring compile time API checks.

It is expected that these will be implemented by adding new ioctl
calls on the underlying driver and that the restrictions will be
enforced at the kernel interface layer (most likely by the kernel
itself).

For evtchn, foreignmemory, gnttab and gntshr this is hopefully
reasonably straightforward.

For call it is not so clear cut. Clearly the kernel cannot enforce
these restrictions for hypercalls which are not stable (domctl et al)
so they can never be on the whitelist. It may also be that potential
users would like to restrict the handle further than just a given
target domain, i.e. to a specific set of functionality (e.g. "things a
device model might reasonably do"). I think we will also need some way
to discover whether a given set of interfaces is available to a
restricted handle, in order to support the addition of new
functionality.

Notes:

- On many (all?) platforms libxencall and libxenforeignmemory are
  implemented by the same underlying privcmd driver. The platform
  level ioctl interface should support restricting the handle to only
  one or the other.
- On platforms with multiple privilege mapping ioctl variants should
  consider only allowing the newest/currently preferred one on a
  restricted handle. e.g. on Linux this would allow
  IOCTL_PRIVCMD_MMAPBATCH_V2 but not IOCTL_PRIVCMD_MMAPBATCH. (Of
  course any subsequently introduced _V3 would be subject to
  compatibility concerns)

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v8: New

This applies on top of the Xen portion of "Begin to disentangle
libxenctrl and provide some stable libraries", v7, plus a couple of
minor fixes which will be in v8. All of this can be found in the
"vwip" branch of the tree referenced by that series at
git://xenbits.xen.org/people/ianc/libxenctrl-split/xen.git.