On Fri, Apr 10, 2015 at 11:56:12AM -0700, Jordan Justen wrote:
> On 2015-04-10 06:56:55, Peter Jones wrote:
> > As promised back in March, here's an updated patch set to add a test
> > harness for ESRT/UpdateCapsule to Ovmf/Aavmf. It's now split into three
> > patches along functional grounds, with renaming and reorganization to
> > make them match UEFI conventions to the degree I understand them.
> >
> > This version is also conditionalized at compile time on
> > "FAKE_CAPSULE_ENABLE" being defined from your ./build command line (or
> > wherever you define those things.)
> >
> > The last one includes an ASCII flow chart of how you might choose to use
> > this thing. I hope you enjoy my artwork :)
>
> What is preventing a real capsule from working with OVMF?
Well, nothing really; the need and desire for that just happens to not
have been my motivation here.
Brainstorming that a bit, if you want to replace the firmware actually
being run by the virtual machine there are various minutiae about the
usage model that do need answers - for example, do you replace the file
or create a new one so other VM instances don't get updated? I suspect
the answer is the latter, at least usually, which means more complex
communication between OVMF and the VM hypervisor or whatnot.
If there's any chance anyone would actually enable that for end users,
it *really* needs to be NIST SP800-147 compliant. That means we also
need to implement some sort of non-reversable locking mechanism in a
DXE_SMM_DRIVER analogous to real hardware's BLE and flash configuration
lock/block write disable mechanisms. We'd need to make UpdateCapsule()
verify signatures against some cryptographic keyring hidden from inside
the VM - whether that's by implementing an SMM-like system like x86 uses
to implement that now, or means making the hypervisor do it
specifically. We'd also to implement a mechanism for UpdateCapsule() to
store the update across the reboot so we can process it before the
locking mechanism has taken effect (or I guess just make it so the
hypervisor does all the work, and make it so remaps the firmware when we
hit the reset vector? Clearly there are options here.) There may be
more; I haven't read SP800-147 recently, nor while thinking about it in
the context of virtual machines.
None of that is fundamentally intractable, but I don't have a use case
it solves at the moment. Right now we (that is, Red Hat) have OVMF
firmware being managed by rpm/yum/RHN/etc outside of the virtual
machine, and as far as I know that works for the usage model we're
currently presenting. I do agree it would be useful to have a real
capsule update mechanism so virtual machines can be managed with the
same mechanism as real machines - some deployments will surely prefer
that.
In any case it could be implemented orthogonally to this set of drivers.
Part of this patch set is setting things up to make such an
implementation more simple to add (you'll notice that a lot of the patch
set is shuffling existing things around to locations which make reuse
easier), and since inclusion of the actual drivers are conditional at
build time, you could easily make the driver you're speaking of exist
with the same or another conditional, exclusive of this one.
The biggest reason the actual CapsuleLib and Esrt protocol providers
here are conditional at build is that I wouldn't expect RH (or anybody
else) to actually deploy this feature in e.g. the firmware we ship in
RHEL. End users don't need it, OS developers do.
> The fake part is that you are storing the entire payload directly in
> variables?
Yes, but also that it's not actually using the updated "firmware" in any
capacity like that of normal firmware - the payload isn't /executed/.
So in that since there's no danger of "bricking" the VM it's running in
if something goes wrong. (Which doesn't mean I don't have any bugs
where malformatting it can cause bad behavior, of course.)
I'm totally welcome to naming suggestions, of course, and any place
you'd like me to add documentation as to the concept, the usage, or the
mechanisms here (or whatever else).
> I think having a real capsule update for OVMF would be good for Linux,
> UEFI and EDK II.
I think it would too - but right now my goal is to make a test harness
we can build, so that I can run my pre-boot, OS-kernel, and userland
firmware update code through a large variety of test scenarios using
100% real APIs in the exact same way we would use them when doing a real
firmware update to a flash part, completely automated, before I start
bricking whole datacenters of real hardware :) And I'm posting it for
inclusion in edk2 because it seems a) other OS developers and similar
can benefit from similar tools, and b) it seems like if we're going to have
an upstream for this driver, it should be the regular edk2 upstream.
--
Peter
------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
