Securing Secure Boot on Xen

Video in TIB AV-Portal: Securing Secure Boot on Xen

Formal Metadata

Title
Securing Secure Boot on Xen
Title of Series
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
2019
Language
English

Content Metadata

Subject Area
Abstract
UEFI is a replacement for the BIOS. It supports Secure Boot which is signature verification of bootloaders and OS kernels which helps prevent attacks where malware injects itself into the bootloader or kernel so that it can be loaded during startup. Despite the poor reputation that Secure Boot has in the free software community (mostly due to non-technical reasons), this would be useful to have for VMs running on Xen. It is also required for features in guests such as Windows Credential Guard. This talk describes how Secure Boot support has been added to Xen. Xen has long had support for running guests booted with UEFI using a build of edk2/Tianocore built for VMs called OVMF. Systems that use UEFI boot have a small amount of NVRAM that stores variables critical for booting the system. Secure Boot is built upon the concepts of authenticated variables and a set of keys. Authenticated variables require updates to be signed by particular keys. These keys themselves are stored in authenticated variables. Verifying updates to authenticated variables needs to be performed in a way that cannot be tampered with by the guest which may have been infected by malware. There are a few ways of dealing with this. The talk will look at the approach taken by bare metal, KVM, and finally how we have implemented it for Xen. This is done by introducing a new component called varstored which runs outside of the context of the guest. It acts as an interface to the guest's NVRAM and verifies updates to it. Actual storage of the NVRAM is delegated to a number of backends to support different uses cases. For example, for a single host it could store the NVRAM in a simple file. For a pool of hosts it could store the NVRAM in database server accessible poolwide.
Loading...
Software System programming Bit Information security Metropolitan area network Booting Booting
Point (geometry) Booting Implementation Service (economics) Open source Virtual machine Mereology Number Revision control Medical imaging Malware Latent heat Operating system Firmware Information security Physical system Point cloud Moment (mathematics) Kernel (computing) Malware System programming Point cloud Quicksort Booting Booting
Booting Computer file Structural load File system Data storage device Database Electronic signature Public key certificate Variable (mathematics) Non-volatile memory Number Non-volatile memory Kernel (computing) Computer hardware Operating system File system Firmware Partition (number theory) Public key certificate Key (cryptography) Variable (mathematics) Flow separation Kernel (computing) Malware Computer hardware MiniDisc Quicksort Table (information) Booting Firmware Booting
Sensitivity analysis Context awareness Run time (program lifecycle phase) Code System administrator Sheaf (mathematics) Set (mathematics) Database Mereology Public key certificate Variable (mathematics) Data management Non-volatile memory Malware Information security Physical system Service (economics) Public key certificate Physicalism Data storage device Variable (mathematics) Latent heat Befehlsprozessor Malware System programming Quicksort Asynchronous Transfer Mode Booting Laptop Asynchronous Transfer Mode Real number Device driver Coprocessor Theory Number Latent heat Computer hardware Operating system Factory (trading post) Energy level Firmware Computing platform Form (programming) Code Database System call Personal digital assistant Factory (trading post) Computing platform Window Booting
Booting Asynchronous Transfer Mode Code System administrator Flash memory Limit (category theory) Data storage device Mereology Regular graph Variable (mathematics) Software bug Data management Non-volatile memory Virtual memory Computer hardware Core dump Implementation Firmware Vulnerability (computing) Addition Service (economics) Code Bit Virtualization Mereology Variable (mathematics) Limit (category theory) Cache (computing) Computer hardware Internet forum System programming Right angle Quicksort Block (periodic table) Information security Booting Asynchronous Transfer Mode
Demon Context awareness Service (economics) Computer file Code Flash memory Database Data storage device Mereology Variable (mathematics) Front and back ends Emulator Energy level Boundary value problem Directed set Implementation Curvature Module (mathematics) Context awareness Service (economics) Demon Computer file Data storage device Code Database Variable (mathematics) Flow separation Curvature Energy level
Demon System call Run time (program lifecycle phase) Code State of matter Set (mathematics) Database Parameter (computer programming) Public key certificate Perspective (visual) Variable (mathematics) Non-volatile memory Front and back ends Virtual memory Information security Area Service (economics) Web page Moment (mathematics) Bit Variable (mathematics) Flow separation Latent heat Buffer solution output Right angle Quicksort Booting Booting Functional (mathematics) Implementation Module (mathematics) Service (economics) Data storage device Regular graph Number Latent heat Operating system Implementation Proxy server Firmware Address space Computing platform Module (mathematics) Authentication Dependent and independent variables Demon Content (media) Database System call Personal digital assistant Computing platform Window
Service (economics) Run time (program lifecycle phase) Demo (music) Bit Computer programming Electronic signature Virtual memory Kernel (computing) String (computer science) Videoconferencing Videoconferencing Traffic reporting Firmware Information security Booting
Kernel (computing) Firmware Information security Physical system Booting
Demon Suite (music) Server (computing) Observational study Code Multiplication sign Public key certificate Computer programming Non-volatile memory Software testing Extension (kinesiology) Information security Domain name Authentication Area Email Demo (music) Surface Electronic mailing list Line (geometry) Instance (computer science) Euler angles Flow separation Vector potential Emulation Integrated development environment Quicksort
hi man my name is Russell Agarwal I work
for Citrix on Zen and Zen sir and I'm going to be talking about implementing secure B's there is no audio so I'm going to be talking about secure boot on Zen so I'll briefly go into some
background about it and why it's useful so secure boot is basically a way of preventing malware from running at boot so the worst kind of the worst thing that can happen is malware sort of affects the bootloader or operating system kernel image and once it's got to that point you can basically in the system I mean this could happen from like a rogue update or something so there are a number of ways that it could happen but one way of preventing it is to use secure boot so it's the firmware basically has a way of trust working out where the image is trusted or not and preventing you from booting untrusted images so this works well if you've got real hardware and but if you've got a VM in the cloud for example like running Xen unfortunately it doesn't support security at the moment so what can you do about it so just on some background secure boots
is actually part of the UEFI specification just added in version 2.3 that one and this is basically a replacement for the bios which the firm eight sort of starts the operating system and provide some services to it so the first thing to notice is that well if we're running if we want to use secure boot then we need to be using uef our guests luckily is then does support you if our guests are ready so there's nothing for us to do it makes use of ivmf which is kind of like the build of the tiyanak or open-source ufr implementation tailored for virtual machines not the way that
UEFI starts kernel or bootloader is kind of different from if you used to buy us a super-earth bios basically it chooses a disk to boot and starts executing from the MBR at the beginning of the disk with UEFI the firmware knows how to understand GPT partition tables and fat file systems and so it's configured to boot a particular file of a particular file system and this is sort of quite a lot like how an operating system would start some executable that it knows about now when you turn on secure boot there's an extra step basically before executing that file it verifies whether the file is trusted and can be executed so how does this work so hardware has nvram
which is kind of like non-volatile storage separate from the main disk and these store UEFI variables which are kind of like key value pairs and some of them are contained certificates there are a number of them and I won't go into the details of what they mean but essentially the bootloader or kernel that you executing needs have been signed by one of these so-called trusted certificates and therefore if the kernel is replaced with something else the firmware will refuse to start it because it hasn't been signed properly the
certificate databases themselves can be populated in a number of ways one of them which is probably the most common is just that the factory installed the certificates are loaded into the NVRAM and it just works because the laptop of whatever comes preloaded with an operating system and so if you're running Windows it'll come with the Microsoft certificates and if you want you can update the certificates in the database so these databases are called authenticated variables and they require to update it you make a sort of runtime call called set variable but this update needs to be signed by specifically one of the certificates that's already in the database and so more wire can't sort of click it's it can't trick itself into being trusted by inserting its own certificates in the database unless it concerned the update in which case it could sign the bootloader anyway the third way is typically there's like a platform specific reset method so on real hardware you would say press f2 during boot and with physical access reset the certificates too or clear them for a VM typically the way I implemented it on Xen was just then the hypervisor or specifically dom0 there'd be some button that you can press or command to run and you can clear the database for a VM so if you look at how this is
implemented on real Hardware kind of the most important thing is that the code to updates that's all the set variable code which handle and firmware which handles updating those certificate databases needs to be protected from being sort of interfered with because if malware could interfere with this code and some are circumvent the checks then it would be possible to just insert your own certificates or if it could write directly to the then it's a problem so there needs to be aware of protecting the code that's running but it's kind of just yeah it runs on the same CPU that's executing the other code which you know it could be some sort of rogue device driver that's running as part of the operating system so it needs to be a way of sort of defining an extra level of privilege or execution context and on x86 processors this already exists in the form of something called system management mode or SMM for short so this is kind of something that's you can jump into and execute code from a special section of Ram called SM Ram which is hidden from the rest of the system so the sort of security sensitive part of the firmware is placed in that sm ram and the NVRAM is configured in a way that it can only be written from within an SM M so making a variable updates then requires doing an SMI and then there are traps into this system management mode and in theory it's secure at least in theory
so KVM has implemented secure boot the way the approach that they took kind of it virtualizes what real Hardware does so qmu emulates some flash memory which is the envy ram and KVM emulates system management mode for guests and it kind of implements or reuses parts of the IANA core firmware for the SMI handling and the way that it jumps into the sort of SMM parts of the firmware and so there's a interesting talk by Apollo about implementing this and KVM sir I won't get into too many details cuz I'll probably get them wrong so how
should this be implemented on then on Zen so they're kind of lots of vulnerabilities against SMM mode because it's kind of tricky the way that it's implemented and so they're lots of ways of attacking it yeah all sorts of cache attacks and the previous talk I mentioned about implementing it on KVM also details some of these attacks in additions and does not have any support for emulating SMM so implementing it would require well could introduce more bugs at least until they I and out thirdly the using emulated flash kind of limits the flexibility of how variables are stored because the code that writes the rights of the flash is stored in its well it's part of the firme which runs inside the guest so this is kind of okay for regular hardware but from VMs we want to be more flexible because you want to be able to import vm's export VM migrate them from two different hosts so it'd be useful if you could have something that was a bit more flexible so with virtualization there are kind of
already two distinct privilege levels or execution context you know broadly speaking the guest and the hypervisor so using SMM is but not really needed to create this boundary or separation so what we propose is to run a demon in dom0 which what was then would be dom0 essentially part of the hypervisor that implements the variable services outside of outside of the guest itself and then add a new module to ovm F which implements the variable services by essentially proxying them to the demon that's running in dom0 so they're about four or five different variable services that it does this for
so this means that the guest does not have direct access to the code so it doesn't need to make use of the special SM Ram it doesn't have direct as to the access to the storage so that isn't anything specifically needed for the flash emulation and it means that the variable storage can easily easily be abstracted into different backends so you could use an SQLite database or zappy database or just flat files kind of whatever you need to use to get the situation done so I'll just talk about
how this works in a little bit more detail with an example so let's suppose that operating system wants to make a update to a one of the certificate databases by adding a new certificate so it would do this by calling the set variable call which is a runtime service it's sort of a bit like a system call to the firmware or an sort of indirect function call and it would send the new data and sort of assigned authentication descriptor which is needs to be signed by one of the existing certificates in the database so this goes into the proxy module in ivmf which we write called which we call Zen variable and it finds the set variable handler there and so that basically has some memory which had set aside and it's serializes the function called parameters into this separate memory and then makes an i/o port right and to a well-known port number with the address of that memory this causes the demon in Don's area to wake up which we called Vasco D and it so so it handles the IO port right from the guest that's basically unser realises the the function call that's or it Maps the memory from the guest uncie realizes the contents of it and works out which command to run in this case it's the set variable 1 so it calls the state variable function and this then proceeds with the regular behavior of state variable and all the various authentication checks and if it's a successful call which in this case let's say it is then it stores it in the zappy database which could be anywhere for example it could be on a another host even once this has happened the response is then written back into the memory map buffer and so it BEF our success just a simple status code for this that returns from the i/o port right which then causes the guest to continue executing and Xen variable module basically uncie realises the uncie realizes the response and returns back to the operating system so there's kind of a clear separation between what happens in the half of oz' and what happens in the guest which makes it quite easy to analyze from a security perspective
so just to yeah go for that so we wrote a demon called fast or T which implements this and at the moment there's a single back-end which is the zappy database which is used on XenServer but it's kind of written in a way that makes it easy to use other backends and then there's a ov EMF module called Zen which implements this sort of proxy and but we've got it working on Zen at the moment and so you can implement secure it built and tested with both Linux and Windows guests I believe it could be used with KVM without too much difficulty due to the fact that I mean nothing in it is rarely is then specific so this could be a different approach yes mmm it's also not really a platform specific implementation so SMM is kind of tied to the x86 platform as far as I understand whereas this okay it uses an i/o port right but that the same sort of approach should be used on any platform so I've
got a demo video which I didn't want to
do it live since it seemed a bit risky but so what I'm going to do here is start a VM this is running on XenServer and it's booting up and you EFR and at
the bottom writers they console.log for fast OD which is essentially logging the runtime service request that vast OD is handling on behalf of the guest so you can see various get and set variable commands I'm just going to check that the kernel reports that it has been booted securely so Linux reports that secure boot is enabled I think it's a bit small to see the back bit the video is online if you want to look at it afterwards so what I'm going to try here is modifying the bootloader what's the firmware execute and in a way that would not ordinarily cause it to what it should still boot afterwards but because the signature is different it's going to well the firmware should refuse to boot so I've just written FOSDEM 2019 to the very first string in the program then the vm's
then restarted and if all goes well the firmware will stop and not beat the
operating system so this is a trivial example but it kind of shows what yeah if Norway tried to somehow patch the kernel and it's not very clear but that's the UVF our way of showing that it didn't be which is not exactly the greatest user experience but it's possible to then run the command manually or execute the bootloader manually and you can see it says security violation which means that a secure boot is doing its job so that
just leaves when will it be available unfortunately it's not yet been publicly released and so we intend to release it shortly and it'll be announced on the Zen mailing list so if you're interested please look out for it there and that's the end of what I've got to say are there any questions the question was how does it relate to chemo and how does it work with emu and stub domain so at least as we've implemented it it's a separate demon that's completely separate 4qe from Kimmi so then has support for they call irx servers which and you can have them in separate programs essentially so it's kind of not related at all and if Q isn't a stub domain then this demon could be anywhere else including in a stub domain as well yes yes so the question was have working code for the certificate and authentication stuff the answers yes so the demo that I showed was kind of all all working so I can just repeat what she said yeah yeah yeah that's implemented so I didn't didn't have a demo of that because it's I mean not really much to demo you mean the implementing time I mean it's it's kind of a few thousand lines I don't think it's not super intense to write kind of also developed a test fairly extensive test suite for it because it is quite complicated yeah yeah yeah yeah yeah so I mean that is kind of the disadvantage of this approach is that it has to duplicate some of the code that's already been implemented in ivmf but I mean it's not it's a few thousand lines of C code so it's not yeah well I mean it it Maps the memory but then copies it out of the it copies it out of the memory that it's not before it uses it so I don't know what you mean about how how else would it get it if it didn't matter yes ma'am so Kristen was basically house sick the question is how is the security of a study handled because it's running in Dawn's area so it's kind of an extra attack surface so at least for how we've implemented it on XenServer specifically it runs kind of sort of it with no privileges in a sort of container environment and so even if you could escape into dom0 should well it should be contained yeah and you can't really escape out of that extra Jail kind of thing it's Kristin at the back yes that would be so the Kristin was can you run the Dom's aribert in a stub domain so that would be the answers yes that would be another approach to reduce what removing any potential security risk of running it so yeah either within a jail or cut some kind of stub domain it's a separate innocent is there one bastardy for every domain the answers yes it's the separate instance kind of like the way you get a separate team you for each domain so times up you can find me afterwards if you want to ask any other questions thank you you
Loading...
Feedback

Timings

  418 ms - page object

Version

AV-Portal 3.21.3 (19e43a18c8aa08bcbdf3e35b975c18acb737c630)
hidden