Re: [qubes-users] XSA-273 - Impact on Qubes?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2018-08-25 16:50, Rusty Bird wrote: > Rob Fisher: >> I'm wondering when we can expect information on the impact of XSA-273 (1) on >> Qubes R4? > > I'd guess early next month: > https://groups.google.com/d/msg/qubes-users/Isn_hko7tQs/PcqIuUleEQAJ > We have now published QSB #43: L1 Terminal Fault speculative side channel (XSA-273). https://www.qubes-os.org/news/2018/09/02/qsb-43/ - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAluLW+AACgkQ203TvDlQ MDCCTBAAxhupcI68/IIuEKKCV8uoYM9Q9DKUxW70b99nh+HgFuVpbqMZJ87PeH4B d+z9rc7DQkPCoiW4hycCChOPyR6k7ZwPpPvD5FbuCXO63LboCD8lIoXSDKL4h6YV C7DPmjFx8HQPqF7jP30erbHegc7lr13t7tSAdS8ITVXfEV06JWrCilMRFTlwT0Ov 5jlpp9JHyQcgkITxuCokdPISJJk3F5GLDQ4YofU8i1FyeT8UvEHIStZhAT6WNMm5 laGq/QdYcw1Ma9yCbXZ0ElJD9VWEysEbxn1t70ulqQHYJNQrwM0uRlO+Jxd5JdgI w7HpEo1IPFuT28mh4x2NpQ7gTFMsN3hbgcMjlglBbYyPXZ6QwdOLOPp73f0pAAlC WBHhmFozOh2zb9XUGkj9yziDvLHyEIFckn+Z1u9CBITTgEMW1nvfzDZvSTwb5be9 L9EouciQ80xUWerp8AFx1OwnKk5teZrk1PxPY0CSIsNeVxhlgsBHSPxOfbbtkWOb iwxkrndspP5zqSDJmPMl2T/0pdQOh2fGx6T2hPluWb7/Xep02Jz9J+Ra+ZZ7YWRG p+PJWmPhrIagQ34AEBRPBrJjJ0XplBjBRBv850Goioz6e3Y++hKAGqCCqPYxVGeY T6mUTj6Ksw/Kvh8+l8roCnKj/Z7V66Ikvw6WdYNQyTMAR32YSOQ= =LIKN -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b74d7348-8691-4895-4e38-12b83a08c3dd%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Is Qubes vulnerable to CVE-2018-3620?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2018-08-15 03:58, Andrew David Wong wrote: > On 2018-08-14 21:38, Sphere wrote: >> CVE-2018-3646 in particular is alarming: >> "The third flaw, CVE-2018-3646, has a CVSS Base Score of 7.1 and enables bad >> actors to attack virtual machines (VM), via virtualization software and >> Virtual Machine Monitors (VMMs) running on Intel processors. A malicious >> guest VM could infer the values of data in the VMM’s memory." > >> Could potentially allow Untrusted VMs to attack safe VMs but I don't know >> for sure whether or not Qubes mitigates this. > > > CVE-2018-3620 and CVE-2018-3646 are XSA-273 [1], which was released > yesterday without embargo. We won't have an official statement about > whether or how this affects Qubes until the Qubes Security Team (QST) > has had a chance to assess it. Both members of the QST are currently out > of the office (completely offline, one on sabbatical and one on > vacation), with one scheduled to return at the end of the month, so > that's probably the earliest we'll know. > > XSAs 268-273 were all publicly released on 2018-08-14. 268-272 went > through the normal predisclosure process, so the QST was able to > evaluate them before they left. Consequently, we've published official > statements regarding XSAs 268-272. [2][3] By contrast, XSA-273 skipped > predisclosure, so the QST didn't get a chance to see it before they > left. > > [1] https://xenbits.xen.org/xsa/advisory-273.html > [2] https://www.qubes-os.org/news/2018/08/14/qsb-42/ > [3] > https://www.qubes-os.org/news/2018/08/14/xsa-268-269-271-272-qubes-not-affected/ > Update: We have now published QSB #43: L1 Terminal Fault speculative side channel (XSA-273). https://www.qubes-os.org/news/2018/09/02/qsb-43/ - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAluLW44ACgkQ203TvDlQ MDAuKw/+K8hQn8Arav4WmYMD2r4CAuA+qQvWtNcD02fGy9M9ojDWaEkot4C410At zEAyjyACP36VjwtoTA0mqEv8ZPm9k18ImIzGBB8ZwUPuWMcQ+idVmu6yDAtEXT/K BD4LtSBYpfyMvvMLHuIIAx7UJ0+ABw+hiteYU0o1gp3O/uNfIfYWd/q1t3jLta9C PbBDjmLPLGcrtFZbv2x+thM8W4Hvjt7XGz6J5fm7avmOTlcpBVgybr7wyVQ5L1mB A66Ffi9+bpa1XgA/j5V2BMrXMG9gWkrYrqDr/CvCiX637oVmkg7NUDWc91NixGiT 5mfXTxjWjD8eX3/KVUPVJLm88EzBmXWAlKMgfRkx44y0cx8JEEVHNF9HcWesnNuU WtIFvUSr+mUhKETrw4sMj+tNWyEoZT75x5jS01wRmamzTF9MLUhcnYmoFnaPGaVA /pidkBToovi/fCp8VwHhcPMay2pKXs3hzZ3WdUxORPiN3h5wppvn80L4gdu7urcI braAtALRDBLzddw6p1WzhgC23tF6fRJP5zt6l6JZKY7abVXOrnUnWhyXdl/i5tXD czBgm1qaO1pFGG8bMPw4FSkQ7muqeetmyChUHNjqASdMji2GL7UJpd+GKBbFhr8D k3WOr8TR+RDxyb4FuLAlVNZvFNNFqA2wa6edUxRg5kjCKBCi02k= =riDr -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/39a93d60-62af-8ed8-8d7a-55c86d3b1570%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] QSB #43: L1 Terminal Fault speculative side channel (XSA-273)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear Qubes Community, We have just published Qubes Security Bulletin (QSB) #43: L1 Terminal Fault speculative side channel (XSA-273). The text of this QSB is reproduced below. This QSB and its accompanying signatures will always be available in the Qubes Security Pack (qubes-secpack). View QSB #43 in the qubes-secpack: https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-043-2018.txt Learn about the qubes-secpack, including how to obtain, verify, and read it: https://www.qubes-os.org/security/pack/ View all past QSBs: https://www.qubes-os.org/security/bulletins/ View XSA-273 in the XSA Tracker: https://www.qubes-os.org/security/xsa/#273 ``` ---===[ Qubes Security Bulletin #43 ]===--- 2018-09-02 L1 Terminal Fault speculative side channel (XSA-273) Summary On 2018-08-14, the Xen Security Team published Xen Security Advisory 273 (CVE-2018-3620,CVE-2018-3646 / XSA-273) [1] with the following description: | In x86 nomenclature, a Terminal Fault is a pagetable walk which aborts | due to the page being not present (e.g. paged out to disk), or because | of reserved bits being set. | | Architecturally, such a memory access will result in a page fault | exception, but some processors will speculatively compute the physical | address and issue an L1D lookup. If data resides in the L1D cache, it | may be forwarded to dependent instructions, and may be leaked via a side | channel. | | Furthermore: | * SGX protections are not applied | * EPT guest to host translations are not applied | * SMM protections are not applied | | This issue is split into multiple CVEs depending on circumstance. The | CVEs which apply to Xen are: | * CVE-2018-3620 - Operating Systems and SMM | * CVE-2018-3646 - Hypervisors | | For more details, see: | https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00161.html | | An attacker can potentially read arbitrary host RAM. This includes data | belonging to Xen, data belonging to other guests, and data belonging to | different security contexts within the same guest. | | An attacker could be a guest kernel (which can manipulate the pagetables | directly), or could be guest userspace either directly (e.g. with | mprotect() or similar system call) or indirectly (by gaming the guest | kernel's paging subsystem). This is yet another CPU hardware bug related to speculative execution. Only Intel processors are affected. Impact of mitigations on Qubes OS == Qubes OS 3.2 - - Part of the mitigation is to disable hyper-threading. This halves the number of CPU cores that the system sees compared to having hyper-threading enabled, thus reducing system performance. This mitigation is needed only when running HVM qubes (or PVH, but PVH is not available in Qubes OS 3.2 anyway). However, we believe there is a risk that similar issues will be discovered in the future, and that having hyper-threading disabled may mitigate those issues, as it does this one. Therefore, we recommend that most users leave hyper-threading disabled regardless of whether they use HVM qubes. If you decide that you are willing to accept the risks of enabling hyper-threading, you can do so by following the instructions below. The instructions differ depending on whether you use EFI or legacy boot. How to re-enable hyper-threading with EFI boot: 1. Change `smt=off` to `smt=on` in `/boot/efi/EFI/qubes/xen.cfg` in dom0. 2. Save your change to the file. 3. Reboot dom0. How to re-enable hyper-threading with legacy boot: 1. Change `smt=off` to `smt=on` in `/etc/default/grub` in dom0. 2. Save your change to the file. 3. Run `sudo grub2-mkconfig -o /boot/grub2/grub.cfg` in dom0. 4. Reboot dom0. Qubes OS 4.0 - - Part of the mitigation is to disable hyper-threading. This halves the number of CPU cores that the system sees compared to having hyper-threading enabled, thus reducing system performance. Since Qubes OS 4.0 uses both PVH and HVM qubes, it is _not_ safe to re-enable hyper-threading. If you have previously modified the number of virtual CPUs assigned to any qube (the "vcpus" property), it may be necessary to adjust this value in order to account for reduced system performance. In addition, if you use any PV qubes (which is discouraged for security reasons), it is necessary to update their kernels to a version that contains L1TF mitigations. Otherwise, they may crash when using swap, which is part of the L1TF mitigation and (partially) due to the intentional [2] lack of shadow paging support in Qubes OS 4.0. If the kernel is provided by dom0 (the "kernel" property), we provide updated kernel packages (see the "Patching" section below). If the kernel is used from within the VM (using pvgrub), use the VM's appropriate distribution update channel. Alternatively, to avoid crashing, you can disable swap in
[qubes-users] Android Studio AVD emulate
Recently I downloaded and configured the android studio and as it turns out, AVD has problems with the emulate because he does not want to emulate the image of the android system. Any ideas? When writing an android application, I need to emulate this system so that I can see how my code works. My guess is that this problem is because avm wants to emulate in emulated machine and hence the confusion. How would you do it? In the worst case, what websites do you recommend for this type of emulation and code testing? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2128121794.9234.1535808095795%40ichabod.co-bxl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes-R4.0 : missing argument to qvm-create
Le 31/08/2018 à 19:51, Ivan Mitev a écrit : > > On 08/31/2018 08:42 PM, GDRUB wrote: >> Le 31/08/2018 à 14:43, GDRUB a écrit : >>> Le 31/08/2018 à 13:33, brendan.h...@gmail.com a écrit : On Thursday, August 30, 2018 at 4:43:42 PM UTC-4, GDRUB wrote: > Thank you for those explanations. > > However, Windows 10 fails with error code : 0xc225 "a required > device isn't connected or can't be accessed". > > win10.raw = 96.6 GB > > How to fix this error ? > > > Le 30/08/2018 à 11:58, Ivan Mitev a écrit : >> On 08/30/2018 11:10 AM, gd...@gmail.com wrote: >>> Hi, >>> >>> I'm trying to run the following command: >>> >>> $ qemu-img convert -O raw *.vmdk win10.raw >>> $ qvm-run --pass-io untrusted 'cat "/media/user/externalhd/win10.raw"' >>> > /home/user/win10-root.img >>> $ qvm-create --hvm win10 --label red --mem=4096 --root-move-from >>> /home/user/win10-root.img >>> >>> qvm-create: error: unrecognized arguments: --hvm --mem=4096 >>> >>> Source : https://www.qubes-os.org/doc/hvm/ >> You're using 3.2 commands, see the "R4.0: ..." paragraph below in the >> doc. >> >> The following command should do the trick: >> >> qvm-create win10 \ >> --class StandaloneVM \ >> --property virt_mode=hvm \ >> --property kernel='' \ >> --label=red \ >> --property memory=4096 \ >> --property maxmen=4096 \ >> --root-move-from /home/user/win10-root.img >> >> >> >>> How to create a new PVH instead of HVM in Dom0 with the root image from >>> R4.0 ? >>> >>> Thank you so much for your help. >>> >>> Best regards. >>> I think the issue of > 10GB images being truncated via ---root-copy-from during create still exists. See this Issue is still open in the tracker: https://github.com/QubesOS/qubes-issues/issues/3422 You'll likely need to qvm-create w/o the root-copy-from, then qvm-grow-root, then copy the image to the right volume listed in /dev/mapper. See this thread (and choose commands wisely!): https://groups.google.com/forum/#!topic/qubes-users/vBk-jjvoeT0 Brendan Your solution worked like a charm. I still have some difficulty with two issues : 1) in the panel of Qubes Manager, state indicator is yellow - something's not ok. That's troubling to me. 2) to get Windows HVM into real full screen mode. The procedure is carried out correctly (https://www.qubes-os.org/doc/full-screen-mode/) but Fullscreen stays grayed out into windows bar -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0e07510d-3573-55dd-c363-d0fffaf1d0dd%40gmail.com. For more options, visit https://groups.google.com/d/optout.
