So now more than 3 years have passed. Researchers have release a whitepaper
on attacking SEV, and AMD released SEV-ES in response. Is SEV on Qubes any
closer?
On Wednesday, August 31, 2016 at 3:34:30 PM UTC+2, Joanna Rutkowska wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Fri, Aug 19, 2016 at 11:58:18AM -0700, kev27 wrote:
> > > Secure Encrypted Virtualization (SEV) integrates main memory
> encryption
> > > capabilities with the existing AMD-V virtualization architecture to
> support
> > > encrypted virtual machines. Encrypting virtual machines can help
> protect
> > > them not only from physical threats but also from other virtual
> machines or
> > > even the hypervisor itself. SEV thus represents a new virtualization
> > > security paradigm that is particularly applicable to cloud computing
> where
> > > virtual machines need not fully trust the hypervisor and administrator
> of
> > > their host system.
> >
> >
> http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf
>
> >
> > https://support.amd.com/TechDocs/55766_SEV-KM%20API_Spec.pdf
> >
>
> Thanks for the pointers. Next time I suggest to send such stuff to
> qubes-devel ;)
>
> > Is this something Qubes OS could work with in the future to improve its
> security on AMD Zen chips? Maybe something to keep an eye on.
>
> Maybe. For either SGX or SEV to make sense for Qubes OS (i.e. a desktop
> OS) it
> would need to allow some form of protected HID/video from/to the
> SGX/SEV-protected VM. Currently none of these technologies seem to support
> this.
> Specifically the white paper you referenced explicitly states:
>
> > One important consideration for an SEV-enabled guest is that DMA into
> guest
> > encrypted memory is not allowed by the SEV hardware for security
> reasons. All
> > DMA, whether from a real hardware or a HV emulated device, must occur to
> > shared guest memory. The guest OS can therefore choose to allocate
> memory
> > pages for DMA as shared (C-bit clear), or may copy data to/from a
> special
> > buffer (aka “bounce buffer”) for DMA purposes. Some operating systems
> have
> > existing support for bounce buffers which may be used for this purpose,
> such
> > as the swiotlb Linux functionality.
>
> It's thinkable that the IOMMU could transparently decrypt DMAs (from
> select)
> devices, allowing communication between these devices (XHCI, GPU) and the
> protected guest, without the hypervisor being able to sniff or inject the
> data
> (e.g. the actual keystrokes, framebuffers). Let's hope they do that one
> day.
>
> Cheers,
> joanna.
> -BEGIN PGP SIGNATURE-
>
> iQIcBAEBCAAGBQJXxtzVAAoJEDOT2L8N3GcYSiYQAL69fzVC4PVInuGNeXPPkhN0
> qr8ahmRzDCZECi/b26fqfWZ/GrW9sf569m0cVT8VImL3Ki0gvV2WPcqiCypNjX6E
> dMQKKnPmkNAbTpKFtv6IIDsC3PxdtvGjcLXSr/R123DLNpbN2/IN5MvrrYCEhfDz
> CpI6YuSzWLwLAEk/MoEfm3Dk+ninRsLY+2bt0YVwfTj2X7/Q+p0VPCY2ImtL1h3k
> OhvYCtIKkMTAvrY4t0gV9Ndm3UNxHAHslZkl9Kcj6Gqp/mkC1GXCK1KemolCcLQE
> MvW9NUlhscpVYYIBmExnQPOPLb8eyD1DqxiZC0FaJz/UxQUCHhLaX6RCqr4MHqQX
> ytPPeNXW/Q3jgfgNewVslbwEOkehWWZgATKuHRMB6W3d/dXtcct7DDSBcqk8pCTr
> jn5Bq55zjylMvRE46seIFR4T4lRNVGsSeKe90N5ouO31v51q9fLAUWoEvF6/4rKA
> d8m/OrbtZf9DFCCXIsVXdTVI6fDzBDKAZSZOlgSpDTiApZyTfOZox6K2rPXO3RuN
> cI3Wf36aCH6gDMJciDOMbWMa2Gf5NxjJJhZ+PXDiqTxIJlf8yzLu2nAvEcGv3XIh
> EWQL6sKNxb4xFgRYCZn4Ekl8vBy9/0rYqpxdhSclg9BX5vJGhrCb6XxHfY6yjRJl
> ToSrhIQPHr1JUZfCqcDv
> =JJWX
> -END PGP SIGNATURE-
>
Seems to be implemented now: "Support for hardware devices (network,
storage, graphics cards) to access encrypted pages seamlessly through DMA.¨
https://www.servethehome.com/amd-epyc-7002-series-rome-delivers-a-knockout/4/
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/565c03bc-f076-436a-9526-d5e25707d185%40googlegroups.com.
