[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qubes-devel
Subject:    [qubes-devel] Re: [qubes-users] AMD Zen Secure Encrypted Virtualization (SEV)
From:       Joanna Rutkowska <joanna () invisiblethingslab ! com>
Date:       2016-08-31 13:34:14
Message-ID: 20160831133413.GA20414 () work-mutt
[Download RAW message or body]

-----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-----

-- 
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+unsubscribe@googlegroups.com. To post to this group, \
send email to qubes-devel@googlegroups.com. To view this discussion on the web visit \
https://groups.google.com/d/msgid/qubes-devel/20160831133413.GA20414%40work-mutt. For \
more options, visit https://groups.google.com/d/optout.


[prev in list] [next in list] [prev in thread] [next in thread]