AMD Zen Secure Encrypted Virtualization (SEV)

[kev27]

> 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

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.

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Sounds very interesting! This reminds me of what Joanna has written about
Intel SGX.[1][2][3] FWIW, however, Joanna has also said:

"We don't have much experience with AMD: neither research- nor testing-wise.
Right now we have no resources to get acquainted."[4]

I imagine that could be relevant to this.


[1] http://blog.invisiblethings.org/2013/08/30/thoughts-on-intels-
upcoming-software.html
[2] http://blog.invisiblethings.org/2013/09/23/thoughts-on-intels-
upcoming-software.html
[3] http://blog.invisiblethings.org/papers/2015/x86_harmful.pdf
[4] https://twitter.com/rootkovska/status/756052459752128512

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXt2GHAAoJENtN07w5UDAwLuQP/3IkhRVoHpTogM4u5hUpzig+
ni7T69i8FQ5cfbqRQKZa60TY4TAwaWUUKMyAOkUb8gnO9NEFOXHspV8S4kowWq3C
j1OvVrq/DjucsqTchcwVo1x6K+WJsES+Bn92B253YCfmRllYNsGf7Zeolcd0uyVE
6w6qSkWuoPTjOmdXCHWBllreDh2LlVvgL3FF7207TLRTEjV8BGPFndFzZ8NfNGSx
6F4Ss7X/WLi0XmA3asJXofOr9piOM3D86sy6W8yK8q1OosbO+WQFAlVrtruoh6FZ
WBhurvmix2Yj9TGOyFvdTBDG+ctybBrA3VatwJT7pcjIZvSKp6BW6h9P7rGAg+af
AvW+UKJFsPD72meS3jyrKNICbz+tAajHCAL4eVF9wltS/zighuWBoIpAugOwxHWu
rIfdN9hmtkPtG7uc/IeJP5utq9GpsbcuN3BjB79dPRrAqGrylriHa4hUGPloSutO
OmXyq9YQW2C+FxLLFcAlfenxZZh1Umg+APPN0IqDjfBdKUS3oOYKJIP0YO0SDJYF
CIZcQRiTs0O/JuKfqGddMU5QzzdWJx5Z2mVV2oTp5ed2sjl1KYYWLAg0gc73mSYB
jcyWeeFvOJiz3csoBobOTh4eLBXJXd/Nzskki5WxOl6qYB7xSi4Vle1qnOels4vz
2NgLEVxsaJGJSZvJ72FJ
=uIAV
-----END PGP SIGNATURE-----

[kev27]

Well, by the time enough people have Zen machines, it would've passed 2-3 years anyway. So this was more of a heads-up. I understand there's a lack of resources for a project such as Qubes OS, but Intel's monopoly with regular consumers is bad enough and no need to make it worse with Intel exclusivity for Qubes.

Perhaps in a few years Qubes will have the resources to support AMD machines, too. Or if there's a new Librem-like partnership between Qubes and some other OEM, the Qubes team can encourage the use of AMD Zen instead. That would mean they get funded for researching AMD's architecture, and at the same time gain enough knowledge for working for AMD chips.

[J. Eppler]

Hello,

till now the argument of Qubes OS was that there are no laptops with AMD CPU's or APU's which Qubes OS can run on.

Qubes OS primary focus is on laptops and than on workstations.

Qubes OS uses Xen to isolate "qubes" (vms) from each other. Xen can run on AMD, Intel, ARM and other platforms. Therefor Qubes itself is not dependent on the hardware itself. Qubes depends on certain virtualization extensions like Second Level Address Translation (SLAT), CPU virtualization extension and IO-Virtualization (IOMMU). AMD has all those virtualization features. So, in theory Qubes OS could run on AMD chips.

The problem till now was that AMD was not producing any hardware which was able to compete with Intel's quasi mono pole. This changed with this weeks AMD Zen announcement. The next question is: when does AMD Zen CPU's will appear in laptops?

The next question is, will AMD offer SEV support for consumer CPU's?

[kev27]

I thought I read somewhere that Qubes is moving to hardware-enabled virtualization, though? Zen laptops were supposed to arrive first half of 2017, but I think they got delayed to second half of 2017 now. So yeah, it will be a while until enough people have these. But a Qubes/OEM partnership could still make them relevant sooner. I don't know if ZEV will be in all consumer chips, but considering SGX is in Skylake+ now, I would hope so. AMD does seem to target this at "cloud companies" in their paper, though...I'm sure we'll find out more about it by early next year.

[Benson Muite]

> Well, by the time enough people have Zen machines, it would've passed 2-3 years anyway. So this was more of a heads-up. I understand there's a lack of resources for a project such as Qubes OS, but Intel's monopoly with regular consumers is bad enough and no need to make it worse with Intel exclusivity for Qubes.
>
> Perhaps in a few years Qubes will have the resources to support AMD machines, too. Or if there's a new Librem-like partnership between Qubes and some other OEM, the Qubes team can encourage the use of AMD Zen instead. That would mean they get funded for researching AMD's architecture, and at the same time gain enough knowledge for working for AMD chips.
>

This would be an interesting addition. If might be willing to help with
Qubes on Zen machines please let me know.

[132094781094378109432780914327091432780]

Hello,

AMD optimized Code, which runs well under Debian and will perform also on a QubesOS machine, will be highly appreciated.

Today I run Qubes under AMD, all seems fine, but complex and long Mathematica calculations seems very strange time-dependend sometimes slow and even don't work well (long-floating point math). The reference was an Intel W8 infrastructure (the same program was here right).

To test some hardware is quite simple, calculate Pi for 30 million digits - there should be only one answer.

Mathematica code is AMD and Intel optimized and I would appreciate, if it will run on both systems with the full intended speed, like it should.

Kind Regards

[Joanna Rutkowska]

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

[Lorenzo Lamas]

Has there been any progress with this? Researchers managed to bypass the encryption, but afaik this is fixed with SEV-ES(Secure Encrypted Virtualization-Encrypted State).