Re: [qubes-devel] Re: GVT-g Discussion

[Ivan Kardykov]

On 2020-01-02 15:26, Kardykov Ivan wrote:
> bump thread
> 
> On Friday, November 22, 2019 at 5:02:14 AM UTC-5, Dylanger Daly wrote:
> 
> Will the Qubes team consider enabling the use of GVT-g so we can
> enjoy hardware accelerated graphics?
> 
> After upgrading to DDR4 Memory I've noticed a significant increase
> in performance, I assume this is because of the many, many memory
> copies taking place, GVT-g should lighten the load.
> 
> -- 
> 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/f608a18f-15e2-4ad1-94b3-da7ae8b1c553%40googlegroups.com
> .

Sorry for that bumping, but looks like my posts stuck at moderate or
spam checks.. So my message was about GVT-g.

We have some success with adaptation Intel gtv-g technology to Qubes OS.
At now it is rather proof of concept state, but it probably could help
to test guivm features and discuss of applicability in practice.

In this [1] repository we placed specs and patches to build core Qubes
components with ability to run and work with GPU accelerated VM. We
oriented to Fedora 29 dom0 and Xen 4.12 versions with plans of 4.1
compatibility. Now it is up to Fedora 31 and Xen 4.13 and we will get to
this versions in some time.

We made and adapted patches to xen, kernel, libvirt, qemu to dom0 and
xorg dummy driver to guest environment. Our work mostly based on Intel
[2][3] and XenServer [4] public repositories.

The most controversial question is probably running qemu without any
restrictions, but there are several ways to improve it.

At now it works with some issues and limitations, most of them described
in repository readme. We have tested it on Lenovo X1 gen5/gen6 and T480
laptops with KabyLake/KabyLake R chipsets.

[1] https://github.com/tabit-pro/tabit-qubes-repo
[2] https://github.com/intel/gvt-linux
[3] https://github.com/intel/igvtg-qemu
[4] https://github.com/xenserver/xen.pg.git


Regards,
Ivan Kardykov

-- 
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/9ffc85a2-9b21-b126-bfbb-831ebad2d7ed%40tabit.pro.


signature.asc
Description: OpenPGP digital signature

[qubes-devel] Qubes OS 4.0.2 has been released!

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Qubes Community,

We're pleased to announce the release of Qubes 4.0.2! This is the second
stable point release of Qubes 4.0. It includes many updates over the
initial 4.0 release, in particular:

- - All 4.0 dom0 updates to date
- - Fedora 30 TemplateVM
- - Debian 10 TemplateVM
- - Whonix 15 Gateway and Workstation TemplateVMs
- - Linux kernel 4.19 by default

Qubes 4.0.2 is available on the Downloads page:

https://www.qubes-os.org/downloads/


What is a point release?
- 

A point release does not designate a separate, new version of Qubes OS.
Rather, it designates its respective major or minor release (in this
case, 4.0) inclusive of all updates up to a certain point. Installing
Qubes 4.0 and fully updating it results in the same system as installing
Qubes 4.0.2.


What should I do?
- -

If you installed Qubes 4.0 or 4.0.1 and have fully updated, then your
system is already equivalent to a Qubes 4.0.2 installation. [1] No
further action is required.

Similarly, if you're currently using a Qubes 4.0.2 release candidate
(4.0.2-rc1, 4.0.2-rc2, or 4.0.2-rc3), and your system is fully updated,
then your system is equivalent to a 4.0.2 stable installation, and no
additional action is needed. [1]

Regardless of your current OS, if you wish to install (or reinstall)
Qubes 4.0 for any reason, then the 4.0.2 ISO makes this more convenient
and secure, since it bundles all Qubes 4.0 updates to date.

*Note:* At 4.5 GiB, the Qubes 4.0.2 ISO will not fit on a single-layer
DVD (for the technical details underlying this, please see issue
#5367). [2] Instead, we recommend copying the ISO onto a sufficiently
large USB drive. [3] However, if you would prefer to use optical media,
we suggest selecting a dual-layer DVD or Blu-ray disc.

Thank you to all the release candidate users for testing this release
and reporting issues! [4]


[1] https://www.qubes-os.org/doc/updating-qubes-os/
[2] https://github.com/QubesOS/qubes-issues/issues/5367
[3] 
https://www.qubes-os.org/doc/installation-guide/#copying-the-iso-onto-the-installation-medium
[4] https://www.qubes-os.org/doc/reporting-bugs/

This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2020/01/02/qubes-4-0-2/

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAl4OpQ8ACgkQ203TvDlQ
MDDQMhAAwtmOkAou4r0goWfBWNjrNey3nS+WjHm4VC9tRIkmGJ7Y7J5yIcGUbVzh
Zsk3vQsSx9kzjAreFFmqjS27XMEjf8PB0ZKBWA8OTjymqXeMfCoFfXpjKsDEXnOi
roRIYvHgk3NqDwUsJ+u9cDfYWka1lgoQB7Rn6iLaFd35ukSu1hJGZHeAZHst6VBh
g0EA8hq/ESTe3mfs8sdLpaO9c1ldH/rwmhBbJYpnKJ/Q+3MF7eX/hbenKSBtLjRN
Qd0QJW4aVjE5ZfryB6pJgga2JsMAF/1zJz0sjtdey4L+bkP2LkWrwvNM4z7rf+d+
0svS+9bg0jAreP5gHHUC6s2N+q3kYl4oPYTJjxOfnd3qJgtqQXnSAJ8/IMWHNtKR
KNK4I7ylo24FuUAZ36JP43eRXEAbKpjpIwcI3Fch2MWLRu+rRmRyv9ROEKSX8XqF
bi6cKR8os1t1hUmoqm7k5k/au7cW8WTJ3uGOiwFUiMhVZ5dmGDUkhVF8rIngi3qu
Zl6lomhI4nXTlguwdpJPnDbnEZAgYKLLgyV4mazrFgcp4zCZpgVSzwxtzC4v6yCb
BUcSnUvXpVHesrLLObs14ruwcMe5hRJCtaLk1fPwL6mdW/rPTGoqm2TCSWLQfQaF
z0ldcBo27v3QmvqO8fpNYDTLfadXocou8E4zrMutCIZCUoA6a2Q=
=K5j1
-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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/50fdc3be-b208-2f04-1868-c530633cff5b%40qubes-os.org.

Re: [qubes-devel] Re: GVT-g Discussion

['Dylanger Daly' via qubes-devel]

 My bad, I accidentally replied directly to Demi

Hey Ivan,

This is fantastic work! I'll test this out today, I think this will help 
with Firefox's WebRender engine, meaning much less CPU spikes, and reduced 
wattage when I have like 2 Firefox Tabs open.
Not to mention watching YouTube.

Demi you make some valid Security points, however one major GPU activity is 
WebRender (Web Content being rendered within the iGPU)
It's also my understanding Marek mentioned R4.1 would support GVT-g.

I would love to see an approach similar to Genode as well, I just don't 
think it will happen, I'm almost certain GVT-g will be used.

Cheers!

*Demi Replied with*

> Hey Ivan,
> 
> This is fantastic work! I'll test this out today, I think this will help
> with Firefox's WebRender engine, meaning much less CPU spikes, and reduced
> wattage when I have like 2 Firefox Tabs open.
> Not to mention watching YouTube.
> 
> Demi you make some valid Security points, however one major GPU activity 
is
> WebRender (Web Content being rendered within the iGPU)
> It's also my understanding Marek mentioned R4.1 would support GVT-g.
> 
> I would love to see an approach similar to Genode as well, I just don't
> think it will happen, I'm almost certain GVT-g will be used.
> 
> Cheers!

Regarding WebRender: My personal approach (and recommendation) is to
just accept the higher power consumption.  If you can’t, a separate
computer is probably your best option.  The trend in QubesOS is to
emulate more devices (such as audio hardware), and rely on QEMU being
sandboxed for security.

GVT-g may be supported in QubesOS at some point, but not until it
doesn’t require unsandboxed QEMU.  Honestly, I consider QEMU
being in stubdoms to be one of QubesOS’s main selling points.
Especially since dom0 is so out of date that there is almost certain
to be a trivially-exploitable vulnerability there.

Sincerely,

Demi

-- 
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/4e5e8079-8aba-4c9f-95c1-7d119db418eb%40googlegroups.com.

Re: [qubes-devel] Re: GVT-g Discussion

[Demi M. Obenour]

On 2020-01-02 15:33, Kardykov Ivan wrote:
> Sorry for that bumping, but looks like my posts from work domain (tabit.pro) 
> stucked at moderate or
> spam checks.. So my message was about GVT-g.
> 
> We have some success with adaptation Intel gtv-g technology to Qubes OS.
> At now it is rather proof of concept state, but it probably could help
> to test guivm features and discuss of applicability in practice.
> 
> In this [1] repository we placed specs and patches to build core Qubes
> components with ability to run and work with GPU accelerated VM. We
> oriented to Fedora 29 dom0 and Xen 4.12 versions with plans of 4.1
> compatibility. Now it is up to Fedora 31 and Xen 4.13 and we will get to
> this versions in some time.
> 
> We made and adapted patches to xen, kernel, libvirt, qemu to dom0 and
> xorg dummy driver to guest environment. Our work mostly based on Intel
> [2][3] and XenServer [4] public repositories.
> 
> The most controversial question is probably running qemu without any
> restrictions, but there are several ways to improve it.

As Marek has stated before, this is a non-starter.  QEMU is not
considered trusted.  Xen’s attack surface is already too high.

The approach I would like to see is a paravirtualized approach
similar to Genode’s: a small (<10K SLOC), auditable (ideally
formally verified) driver running in dom0 and/or its own domain that
communicates with a paravirtualized driver in the VMs.  Any needed
emulation is done in the stubdomain.  This is likely to be difficult
for many reasons, but is the only way that I see can hardware
accelerated graphics being secure enough for Qubes with commodity
hardware.  If you are willing to pay literally thousands of dollars
for server-grade GPUs, then SR-IOV and friends become options, which
make secure hardware acceleration much easier.  However, those are
far too expensive for virtually all Qubes users.  In particular,
they are far more expensive than just buying another computer for
graphics-intensive activities.

The main activities I know of that need hardware-accelerated graphics,
and which a Qubes user is likely to want to partake in, are gaming
and GPGPU.  Video games, in particular, should be considered completely
untrusted, and so need to be walled off as tightly as possible.

Sincerely,

Demi

-- 
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/430e381e-7118-5660-38b5-9db65399b02d%40gmail.com.


signature.asc
Description: OpenPGP digital signature

[qubes-devel] Re: GVT-g Discussion

[Kardykov Ivan]

On Thursday, January 2, 2020 at 3:26:54 PM UTC-5, Kardykov Ivan wrote:
>
> bump thread
>
> On Friday, November 22, 2019 at 5:02:14 AM UTC-5, Dylanger Daly wrote:
>>
>> Will the Qubes team consider enabling the use of GVT-g so we can enjoy 
>> hardware accelerated graphics?
>>
>> After upgrading to DDR4 Memory I've noticed a significant increase in 
>> performance, I assume this is because of the many, many memory copies 
>> taking place, GVT-g should lighten the load.
>>
>
Sorry for that bumping, but looks like my posts from work domain (tabit.pro) 
stucked at moderate or
spam checks.. So my message was about GVT-g.

We have some success with adaptation Intel gtv-g technology to Qubes OS.
At now it is rather proof of concept state, but it probably could help
to test guivm features and discuss of applicability in practice.

In this [1] repository we placed specs and patches to build core Qubes
components with ability to run and work with GPU accelerated VM. We
oriented to Fedora 29 dom0 and Xen 4.12 versions with plans of 4.1
compatibility. Now it is up to Fedora 31 and Xen 4.13 and we will get to
this versions in some time.

We made and adapted patches to xen, kernel, libvirt, qemu to dom0 and
xorg dummy driver to guest environment. Our work mostly based on Intel
[2][3] and XenServer [4] public repositories.

The most controversial question is probably running qemu without any
restrictions, but there are several ways to improve it.

At now it works with some issues and limitations, most of them described
in repository readme. We have tested it on Lenovo X1 gen5/gen6 and T480
laptops with KabyLake/KabyLake R chipsets.

[1] https://github.com/tabit-pro/tabit-qubes-repo
[2] https://github.com/intel/gvt-linux
[3] https://github.com/intel/igvtg-qemu
[4] https://github.com/xenserver/xen.pg.git


Regards,
Ivan Kardykov
tabit.pro

 

-- 
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/d36c7519-82b8-40ca-b2dd-b24c023bc7b7%40googlegroups.com.

[qubes-devel] Re: GVT-g Discussion

[Kardykov Ivan]

bump thread

On Friday, November 22, 2019 at 5:02:14 AM UTC-5, Dylanger Daly wrote:
>
> Will the Qubes team consider enabling the use of GVT-g so we can enjoy 
> hardware accelerated graphics?
>
> After upgrading to DDR4 Memory I've noticed a significant increase in 
> performance, I assume this is because of the many, many memory copies 
> taking place, GVT-g should lighten the load.
>

-- 
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/f608a18f-15e2-4ad1-94b3-da7ae8b1c553%40googlegroups.com.

[qubes-devel] Re: [qubes-users] AMD Zen Secure Encrypted Virtualization (SEV)

[Lorenzo Lamas]

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.