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