[Xen-devel] [HACKATHON] xSplice session note

[Wei Liu <wei.liu2@xxxxxxxxxx>]

* Signature verification

 Code bloat to verify all sort of sigs.  Limit to two types of sigs

 Verify in hypervisor seems to be the only way.

 What extra security provides? It ensure binaries you get is from the
 vendor.

 Can do in userspace in Dom0? Questionable, even Linux doesn't trust
 module, it verifies sigs in kernel.

 Whether to do it in userspace or Xen is valid question. Dom0 is
 already quite privileged.

 If we were to trust dom0 sig wise then we can rid of all verification
 code in Xen, demand image be verified in dom0. Don't do advanced
 security in Dom0 while basic in Xen.

 Sig verify in the future.  Jan: prefers verification in hypervisor
 unless it becomes to complex.

*  OSStest test case

 Korand has something for that in the next two or three month

* Userspace tooling

 Plan to move to xl / libxl.  Need to have stable interface in libxl
 Tool is simple now, but might be more complex when sig verification
 is involved.

 Jan: use external utility to veirfy, better. Xl should only do basic
 uploading etc. Verification should either be in HV, or completely
 with human intervention.

 Korand: don't trust human intervention much

* Want mechaism for hooks being called on load / unload

 Jan: hooks in those places are easily to be misused. By introducing
 hooks you can basically do everything to the system. (Is that the
 intention?)

 Stefano / Konrad: you can still do it without hooks but just harder.

 Jan: how many real cases do we need these hooks? Need to check in
 detailed. Thinks it's not very useful at this stage.

 Konrad: Not a lot of people to write patches for xsplice. People
 using it would have knowledge, we should allow them to make
 work. Otherwise they invent their own things, worse than hooks.

 Jan: need to check the frequency to find the balance. Need to
 analyse exising XSAs.

* Patching data not yet available

 Konrad: do we want to patch data?

 Jan: data statically described in payload becomes problematic when you
 have multiple instances of something. Some structures that can't be
 enumerated. If we do data patching, only at some very limited
 points. Still need to go through the lists to verify the idea. Don't
 recall many instances of XSAs require data patching.

* Interfaces between generation tools and hypervisor

  Need to have stable interfaces between generation tool and
  hypervisor.  Some fields will be pre-filled by the tools.  Should be
  seen as extension of hypervisor.  Talk about padding later. rename
  that to opaque.

* tboot, secure boot and xsplice

 Jan: secure boot works for xen now, not sure how it works with
 xsplice. xen verifies dom0 kernel in secure boot.

 Daniel: where is the sig in the kernel?

 Jan: don't know, but currently works.

 Jan: with secure boot, how to verify xsplice payload? Need to verify
 by Xen eotherwise breaks chains of trust, which in turn requris whole
 infrastructure.

 Stefano: dom0 kernel verifies sigs? Jan: don't think that's how it is
 meant to work. you can't make such assumptions but there is only
 one direction chain of trust. But not 100% certain.

 Daniel: hence that we can't use xl to load payload?

* Patch nops

 Ross: what is the purpose of noping out a function?

 Stefano: avoid calling it?

 Jan: used to patch in place. if the new thing is smaller
 then you use nops to fill the gap.

 Ross: already have the branching
 mechanism, worthy of the effort of nopping?

 Jan: depends on the complexity. not a lot imo. but this is not
 absolutely required.


* Handling NMI

  Konrad: why can't we take an NMI while patching? Jan: we can, but
  comes with complexity.

  Konrad: have a list of all NMIs, can replay if necessary. but harder
  to replay NMIs tied to a specifc cpu. Jan: if want to replay, only
  replay one, entities should know how to handle such situation.

  Konrad: MCEs? Jan: more difficult, can't be deferred.

  Jan : maybe like Linux kernel, annotate handlers to make sure they
  NMI MCE won't be touched by anything.

  Konrad: Is handling NMI and MCE requirement? J: the sooner the
  better, but in the end it's down to the person who puts the patch
  together.

* Value in ARM32 suppot

 Julien: pointers on ARM of different sizes, do you always require to
 use tool on native? Cross-complication possible?

 Konrad: it doesn't work that way, very x86 specific.

 Jan: what is the input?

 Ross: build xen once and with patch once.

 Konrad: cross compilation can work, tools can be made
 recognise the archs.

 Julien: can things be made all the same on all platforms then let HV
 sort it out? Void pointers are of different sizes.

 Jan: Tools should know what to to, it's a specialised compiler.

 Julien: do you have usecase for ARM32? Likely every server are
 64bits. 32bits need to be maintained and tested. Not much value in it
 in my view.

 Konrad: deprioritise ARM32

 Stefano: don't like dead code. but also don't like different set of
 code for different archs.

 Konrad: xenver hypercall is good enough. his test case coverage is
 also good enough -- load, unload etc. can be augmented by code
 coverage tool.

* Make it work on ARM 32 and 64

 Julien: Limited range for placement function.

 Julien: can move the fixed map. most address space is used in ARM32,
 only limited address space can be used. remapping is the best thing
 to do due to some quirks and more strict settings on ARM.

 Konrad: do we want to announce it supported on ARM64? not a fast ARM
 developer, going to take a while.

 Julien: not the most wanted feature at the moment.

 AndrewPr: something is better than nothing. won't be too complicated
 if something is already avaible.


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