Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
On Thu, Jan 18, 2018 at 3:49 PM, Vít Šestákwrote: > On Thursday, January 18, 2018 at 7:00:42 PM UTC+1, Nik H wrote: >> On Jan 16, 2018, at 2:56 AM, Vít Šesták <…@v6ak.com> wrote: >> > >> > * If an application does not mitigate Spectre and attacker finds useful >> > entry point, attacker can read memory of the application (but nothing >> > more). >> > * If VM kernel does not mitigate Spectre and attacker finds useful entry >> > point, attacker can probably read memory of whole VM (but other VMs are >> > not affected). >> > * If Xen does not mitigate Spectre and attacker finds useful entry point, >> > attacker can probably read memory of whole system. >> >> Can you explain why you think that Spectre can't escape the container (VM)? >> It seems that is the main issue, Spectre escapes the container. > > It depends on what you mean by VM escape. Sure, both Meltdown and Spectre are > about reading memory that should not be accessible. From your description > below, I believe you have confused those two. > > The reason why Spectre is much harder to actually exploit than Meltdown: For > Meltdown, you just use your own code to read the memory. With Spectre, you > have to use (and find!) a victim's code to perform innocently-looking > operations. > > Meltdown allows attacker to read any address in her address space. That's not > always whole physical address space, but in case of Xen PV x64 domains, it is > the case. > > Spectre allows to read the memory in a different way. Imagine the _victim_ > has code like this: > > if((i > 0) &&(i < a_length)) { > return a[i]; > } else { > return NULL; // or any other error code > } > > This looks like a perfect code that prevents overreads and underreads. But an > attempt to overread/underread will affect cache. Fortunatelly, such simple > code is not much useful. The attacker rather needs something like this: > foo[bar[index]]. Even with all the proper bounds checks (that will cause the > code not to execute in traditional sense), attacker might try to perform > overflow/underflow by using index variable out of range. But CPU might try to > execute the branch speculatively (because the condition is usually > satisfied), which can cause a read of arbitrary out-of-bounds bar[index]. The > read of the value would be probably benign on its own, but then, it tries to > load data from foo array based on this value, which might cause cache fetch > depending on value of bar[index]. The attacker has not won yet, she has to > determine what part of memory was loaded into cache. This can be done using > timing attack. > > Another interesting part of Spectre is branch target injection. I remember > some double fetch vulnerability that can cause bad jump due to race condition > (TOCTOU issue). With Spectre, attacker can try to abuse this for bad > speculative jump even if there is no race condition possible. > > But my main point is that for Spectre attack, the fact that nobody has cared > about that when writing the software is not enough for successful > exploitation. Actually, one needs to find a suitable code that processes some > attacker's input in a suitable way. Moreover, the attacker needs some precise > measurement, so passing some malicious input to some queue in order to be > processed by code that can trigger speculative out-of-bounds read can be > impractical. > >> I read the whitepaper and what Spectre is doing is, it's accessing memory it >> should not have access to, and then uses a few simple tricks to extract the >> data it should not have access to. This happens on a processor level so any >> bounds checks that are outside the CPU core will not prevent that. > > That's true for both Spectre and Meltdown. But the fact that bounds checks > aren't enough does not mean that those attack cannot be mitigated in software > elsehow. > >> Given the nature of the attack, I do not think that hardware virtualization >> would stop this attack. > > If this is about Spectre, you are right, hardware virtualization does not > stop it on its own. For Meltdown, the situation is a bit different: Hardware > virtualization makes the VM not to have the address outside the VM mapped in > its address space. Trying to access the memory outside the VM is not > prevented by bounds check, it is prevented by the simple fact that they have > no address. Note that this AFAIU does not prevent attacking VM's kernel from > VM's process, it just prevents attacking hypervisor from VM. > > >> I found various snippets of information hinting at this as well, but again, >> I'd be happy to be wrong! But, if I am right, then qubes isolation is >> compromised. > > Well, you are mostly right. But maybe we should divide it to base system > (e.g., Xen and dom0) and single VMs. > > The base system is unfortunately affected by Meltdown, because it mostly does > not use hardware
Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
On Thursday, January 18, 2018 at 2:06:08 AM UTC+1, Marek Marczykowski-Górecki wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Sun, Jan 14, 2018 at 03:24:04AM -0800, Vít Šesták wrote: > > But it could be useful to use 32-bit stubdoms for those reasons. They do > > rather I/O-bound work (=> minimal performance penalty) and they don't need > > so much memory to utilize more than 32-bit pointers. (Also, using 32-bit > > pointers can make a minor performance gain.) > > … > > It is possible to use 32-bit stubdom on a 64-bit system? > > That's interesting idea. Simon, what do you think about it? > I've tried to implement this kind of protection and I'd like to report my failure achieve the result. Someone might be more successful. After all, I am not much experienced with Xen internals (I mostly configure Xen through Qubes). I've found there is a gzipped ELF with ioemu stubdom. Maybe replacing it with a 32b one could do the trick. But I am not sure if it is enough, maybe this would just result in a 32-bit code running in 64-bit PV domain, which is not what we want. (I am not even sure how to check it.) I haven't found any relevant configuration where I could configure the stubdomain mode. But I've decided to try to compile the stubdom and to try it. I've checked out the code and switched to 4.6.6 tag. The code looks promising, some parts seem to be ready for x86_32, despite the fact that it is no longer supported platform for Xen itself. I however have failed the compilation itself, regardless of the target architecture. I have tried debian-9. I needed few additional packages to pass ./configure, that's OK. (I won't name them, because you might miss different packages and because the error messages are pretty clear.) There seem to be some new warnings in GCC that make the compilation to fail, so I had to adjust tools/Rules.mk by adding line `CFLAGS += -Wno-misleading-indentation -Wno-unused-function`. This shifts me to another problem: command `./configure --enable-stubdom --disable-tools --disable-xen --disable-docs --host=x86_64 && make` results in the following error message I am unable to resolve: … make -C seabios-dir all make[6]: Entering directory '/home/user/xen/tools/firmware/seabios-dir-remote' Compile checking out/src/stacks.o src/stacks.c: Assembler messages: src/stacks.c:635: Error: found '(', expected: ')' src/stacks.c:635: Error: junk `(%ebp))' after expression src/stacks.c:636: Warning: indirect call without `*' … Regards, Vít Šesták 'v6ak' -- 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/72d9be30-473b-4840-a240-f29bea8a47ef%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
On Wednesday, January 17, 2018 at 10:29:18 PM UTC+1, Ilpo Järvinen wrote: > On Wed, 17 Jan 2018, Lorenzo Lamas wrote: > > > On Thursday, January 11, 2018 at 3:57:50 PM UTC+1, Andrew David Wong wrote: > > > ## Qubes 3.2 > > > > > > For Qubes 3.2, we plan to release an update that will make almost all > > > VMs run in a fully-virtualized mode. Specifically, we plan to backport > > > PVH support from Qubes 4.0 and enable it for all VMs without PCI > > > devices. After this update, all VMs that previously ran in PV mode (and > > > that do not have PCI devices) will subsequently run in PVH mode, with > > > the exception of stub domains. Any HVMs will continue to run in HVM > > > mode. > > > > Is this the shim-based approach from XSA-254? > > No, it won't be a shim-based approach (see also the Marek's mail in this > thread). > > > Then it should be made clear that the VM's will be more vulnerable to > > Meltdown: > > Even if shims would be used, that "more" claim is false as Meltdown > against the host hypervisor from PVs that are currently used in R3.2 > expose both host and also the guest through the host hypervisor (its > memory). With shims only the guest is still vulnerable, this time through > the intermediate xen instance running in the HVM/PVH encapsulating the PV > guest. Clearly it's "less" vulnerable rather than "more". > > Qubes has been trying to migrate away from PVs altogether (rather than > e.g., placing PVs into those shims) due to PV vulnerabilities in general. > In fact, even before these HW vulnerabilities were discovered, the process > towards PVH was ongoing which is why R4.0 rcs as is are much better > protected already. These vulnerabilities only accelerated this process. > There will be, unfortunately, be one limitation to this migration still > due to PCI passthrough: VMs with PCI devices need to remain PV (or their > stubdoms in R4.0). > > > "Note this shim-based approach prevents attacks on the host, but leaves > > the guest vulnerable to Meltdown attacks by its own unprivileged > > processes; this is true even if the guest OS has KPTI or similar > > Meltdown mitigation." > > https://xenbits.xen.org/xsa/xsa254/README.which-shim > > Also, note that one of the fundamental assumption with Qubes security > model is that the VMs _will get compromised_ (regardless of HW exploits). > What Qubes aims to protect against is escalation from a compromised VM > to host or to another VM. > > > -- > i. Thank you for clarifying this. -- 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/f08a8a34-859b-4cbe-b8aa-aa9f54e15f5e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
On Thursday, January 18, 2018 at 7:00:42 PM UTC+1, Nik H wrote: > On Jan 16, 2018, at 2:56 AM, Vít Šesták <…@v6ak.com> wrote: > > > > * If an application does not mitigate Spectre and attacker finds useful > > entry point, attacker can read memory of the application (but nothing more). > > * If VM kernel does not mitigate Spectre and attacker finds useful entry > > point, attacker can probably read memory of whole VM (but other VMs are not > > affected). > > * If Xen does not mitigate Spectre and attacker finds useful entry point, > > attacker can probably read memory of whole system. > > Can you explain why you think that Spectre can't escape the container (VM)? > It seems that is the main issue, Spectre escapes the container. It depends on what you mean by VM escape. Sure, both Meltdown and Spectre are about reading memory that should not be accessible. From your description below, I believe you have confused those two. The reason why Spectre is much harder to actually exploit than Meltdown: For Meltdown, you just use your own code to read the memory. With Spectre, you have to use (and find!) a victim's code to perform innocently-looking operations. Meltdown allows attacker to read any address in her address space. That's not always whole physical address space, but in case of Xen PV x64 domains, it is the case. Spectre allows to read the memory in a different way. Imagine the _victim_ has code like this: if((i > 0) &&(i < a_length)) { return a[i]; } else { return NULL; // or any other error code } This looks like a perfect code that prevents overreads and underreads. But an attempt to overread/underread will affect cache. Fortunatelly, such simple code is not much useful. The attacker rather needs something like this: foo[bar[index]]. Even with all the proper bounds checks (that will cause the code not to execute in traditional sense), attacker might try to perform overflow/underflow by using index variable out of range. But CPU might try to execute the branch speculatively (because the condition is usually satisfied), which can cause a read of arbitrary out-of-bounds bar[index]. The read of the value would be probably benign on its own, but then, it tries to load data from foo array based on this value, which might cause cache fetch depending on value of bar[index]. The attacker has not won yet, she has to determine what part of memory was loaded into cache. This can be done using timing attack. Another interesting part of Spectre is branch target injection. I remember some double fetch vulnerability that can cause bad jump due to race condition (TOCTOU issue). With Spectre, attacker can try to abuse this for bad speculative jump even if there is no race condition possible. But my main point is that for Spectre attack, the fact that nobody has cared about that when writing the software is not enough for successful exploitation. Actually, one needs to find a suitable code that processes some attacker's input in a suitable way. Moreover, the attacker needs some precise measurement, so passing some malicious input to some queue in order to be processed by code that can trigger speculative out-of-bounds read can be impractical. > I read the whitepaper and what Spectre is doing is, it's accessing memory it > should not have access to, and then uses a few simple tricks to extract the > data it should not have access to. This happens on a processor level so any > bounds checks that are outside the CPU core will not prevent that. That's true for both Spectre and Meltdown. But the fact that bounds checks aren't enough does not mean that those attack cannot be mitigated in software elsehow. > Given the nature of the attack, I do not think that hardware virtualization > would stop this attack. If this is about Spectre, you are right, hardware virtualization does not stop it on its own. For Meltdown, the situation is a bit different: Hardware virtualization makes the VM not to have the address outside the VM mapped in its address space. Trying to access the memory outside the VM is not prevented by bounds check, it is prevented by the simple fact that they have no address. Note that this AFAIU does not prevent attacking VM's kernel from VM's process, it just prevents attacking hypervisor from VM. > I found various snippets of information hinting at this as well, but again, > I'd be happy to be wrong! But, if I am right, then qubes isolation is > compromised. Well, you are mostly right. But maybe we should divide it to base system (e.g., Xen and dom0) and single VMs. The base system is unfortunately affected by Meltdown, because it mostly does not use hardware virtualization. (Qubes 4 is quite better there, but still not perfect.) It might be also vulnerable to Spectre attacks, but I am not sure if they are practical. Single VMs might be vulnerable to both (unless patched). Meltdown vulnerability is usually not much an issue there,
Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
On Thursday, January 18, 2018 at 12:20:49 PM UTC-5, David Hobach wrote: > On 01/18/2018 04:04 PM, cooloutac wrote: > > SO it doesn't look like 4th or 5th generation boards are going to get a > > bios patch. IS the bios patch nescessary? > > Meltdown can be patched on Kernel and/or Hypervisor level with a > performance loss by doing in the Kernel what should be done by the CPU. > It also seems that Qubes 4 isn't affected in certain virtualisation > modes, see the QSB & XSA. > > It might be possible to patch Spectre 1 & 2 in limited ways as well, but > there are only ideas out yet, see > https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/ > > So the Microcode patches would be the proper way to do it and even there > it seems to be hard if I recall the Spectre paper correctly, but the > Open Source community attempts to implement (partial) mitigations anyway. > > > Or Should we just assume our desktop pc's are about as secure as android > > phones now? Are they no good after a year or two? I joke that real > > security costs alot of money because when firmware gets compromised nothing > > you can do but replace the pc.But if you have to buy a new mobo and pc > > every year or two to stay up to date that is a sad future for most people. OHH so thats why people say there is a performance loss, in other words if your vendor doesn't patch the bios? because I got a huge increase in performance with my board that got patched. So i'm having a hard time believing all the hype about it. And so yes I'm reading that the Qubes team is working to make some changes even to 3.2, which is great news. But I wasn't sure if they are able to address all the problems. I guess a performance loss because lack of vendor support, is better then no mitigations at all. If this is even the case, I'm still skeptical. -- 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/30159d48-6ecf-4b30-a4a2-60bec7f545ec%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
On Thu, January 18, 2018 6:00 pm, Nik H wrote: > Reasoning: The entire point of HW virtualization is to have very fast and > seamless context switching so that if I have 10 different VMs running, > the processor does not lose performance from that. So you keep caches, > and you keep speculatively executing what you believe to be the correct > branch of an if statement. HW virtualization vs. software seems to have > been implemented mainly to improve performance, and not to improve > security/isolation. > > I found various snippets of information hinting at this as well, but > again, I'd be happy to be wrong! But, if I am right, then qubes isolation > is compromised. This is the feeling I got too wrt Spectre, but it's hard to find facts on it. Maybe if we could look at what the virtualization opcodes are doing at a microcode level... -- 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/ce9c9392f0cd7a73fc766ebfecc47906.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
On Jan 16, 2018, at 2:56 AM, Vít Šestákwrote: > > * If an application does not mitigate Spectre and attacker finds useful entry > point, attacker can read memory of the application (but nothing more). > * If VM kernel does not mitigate Spectre and attacker finds useful entry > point, attacker can probably read memory of whole VM (but other VMs are not > affected). > * If Xen does not mitigate Spectre and attacker finds useful entry point, > attacker can probably read memory of whole system. Can you explain why you think that Spectre can't escape the container (VM)? It seems that is the main issue, Spectre escapes the container. I read the whitepaper and what Spectre is doing is, it's accessing memory it should not have access to, and then uses a few simple tricks to extract the data it should not have access to. This happens on a processor level so any bounds checks that are outside the CPU core will not prevent that. Given the nature of the attack, I do not think that hardware virtualization would stop this attack. Reasoning: If HW Virtualization was doing privilege checks on memory access in speculatively executed code, it would severely impact or completely remove the performance gains from speculative execution. I would be *very* happy to be wrong about that so if you have info to the contrary, please let me know. Here's how spectre works (conceptual - the existing sample implementations are just that, examples): - Trick the CPU into doing something it shouldn't to, like in our case access another VM's memory. - This memory access happens in a speculative execution, which is built for speed and doesn't have time to check whether or not I actually have the right to access this memory. - Speculative execution continues, and I load some of my own data into the processor, but which data depends on the value of the byte I read in the previous step. - The CPU realizes I didn't have access, and reverts register states - The CPU does not, however, remove my data from the cache - I can then use cache timing to figure out *what part* of my own data was cached - Once I know what part of my data was cached, I know the value of the byte that I read illegally. If Hardware virtualization were to protect against this attack, it would need to either have bounds checks inside the processor core, or flush caches whenever different VMs run, all of which would severely impact performance. So I don't think they do it. Reasoning: The entire point of HW virtualization is to have very fast and seamless context switching so that if I have 10 different VMs running, the processor does not lose performance from that. So you keep caches, and you keep speculatively executing what you believe to be the correct branch of an if statement. HW virtualization vs. software seems to have been implemented mainly to improve performance, and not to improve security/isolation. I found various snippets of information hinting at this as well, but again, I'd be happy to be wrong! But, if I am right, then qubes isolation is compromised. Sorry this got a bit long. -- 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/A0271FCD-6100-4839-BEF1-1A46540EE9B5%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
On 01/18/2018 04:04 PM, cooloutac wrote: SO it doesn't look like 4th or 5th generation boards are going to get a bios patch. IS the bios patch nescessary? Meltdown can be patched on Kernel and/or Hypervisor level with a performance loss by doing in the Kernel what should be done by the CPU. It also seems that Qubes 4 isn't affected in certain virtualisation modes, see the QSB & XSA. It might be possible to patch Spectre 1 & 2 in limited ways as well, but there are only ideas out yet, see https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/ So the Microcode patches would be the proper way to do it and even there it seems to be hard if I recall the Spectre paper correctly, but the Open Source community attempts to implement (partial) mitigations anyway. Or Should we just assume our desktop pc's are about as secure as android phones now? Are they no good after a year or two? I joke that real security costs alot of money because when firmware gets compromised nothing you can do but replace the pc.But if you have to buy a new mobo and pc every year or two to stay up to date that is a sad future for most people. -- 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/dd2a791d-4519-c05f-3119-e50f917f180c%40hackingthe.net. For more options, visit https://groups.google.com/d/optout. smime.p7s Description: S/MIME Cryptographic Signature
Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
On Thu, January 18, 2018 3:04 pm, cooloutac wrote: > But if you have to buy a new > mobo and pc every year or two to stay up to date that is a sad future for > most people. Most people, but not the Intel board members and stockholders! -- 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/6102c7a277fcbf7f6b901e6c91b6b791.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
SO it doesn't look like 4th or 5th generation boards are going to get a bios patch. IS the bios patch nescessary? Or Should we just assume our desktop pc's are about as secure as android phones now? Are they no good after a year or two? I joke that real security costs alot of money because when firmware gets compromised nothing you can do but replace the pc.But if you have to buy a new mobo and pc every year or two to stay up to date that is a sad future for most people. -- 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/dfa0ab2f-a7fd-4911-a820-e7a3e92b2e8c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Jan 14, 2018 at 03:24:04AM -0800, Vít Šesták wrote: > Good point, I forgot this one. of course, it would, but I am not sure if > Qubes is ready for that. > > But it could be useful to use 32-bit stubdoms for those reasons. They do > rather I/O-bound work (=> minimal performance penalty) and they don't need so > much memory to utilize more than 32-bit pointers. (Also, using 32-bit > pointers can make a minor performance gain.) > > On other VMs than stubdoms, it is not so easily deployable, because user > might have some 64-bit only software there. At least, it is impossible to > deploy it automatically (via update) without breaking anything. > > It is possible to use 32-bit stubdom on a 64-bit system? That's interesting idea. Simon, what do you think about it? - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlpf8uUACgkQ24/THMrX 1yxZbgf/SFCNG6DfWSgriXHlfmNR/eOI6Bdzr+6EpI7rA5AjSu+wERZbFMBFDg0I M5SKJUiKBexC96eUDktrG3wQnEhJ9aJHGFlQ/8jBSCx023yWpFYCtvKgjYlYEUjE 2J32lEvcT0Mv2e/7OouWO9w3oeJD+Qg189naRuKXZKJkF3B9z4iu7eTP9QePFbSg 6QEN3QHpHBZTfkufYJHuqdMyoZ0XiXaYnFBJQ83hsJSSllP1liCA0mKXLHoo+pD2 L/mVT/4Z337EiCdg/zYHoksWALr3I7rxbvRgzEmIyx6c1YbVZR3qfzYWe6VpPXjb uW5/rt/XqSX5g+MaJLX/S78dOEeT2g== =GqGk -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/20180118010541.GD12450%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
On Wed, 17 Jan 2018, Lorenzo Lamas wrote: > On Thursday, January 11, 2018 at 3:57:50 PM UTC+1, Andrew David Wong wrote: > > ## Qubes 3.2 > > > > For Qubes 3.2, we plan to release an update that will make almost all > > VMs run in a fully-virtualized mode. Specifically, we plan to backport > > PVH support from Qubes 4.0 and enable it for all VMs without PCI > > devices. After this update, all VMs that previously ran in PV mode (and > > that do not have PCI devices) will subsequently run in PVH mode, with > > the exception of stub domains. Any HVMs will continue to run in HVM > > mode. > > Is this the shim-based approach from XSA-254? No, it won't be a shim-based approach (see also the Marek's mail in this thread). > Then it should be made clear that the VM's will be more vulnerable to > Meltdown: Even if shims would be used, that "more" claim is false as Meltdown against the host hypervisor from PVs that are currently used in R3.2 expose both host and also the guest through the host hypervisor (its memory). With shims only the guest is still vulnerable, this time through the intermediate xen instance running in the HVM/PVH encapsulating the PV guest. Clearly it's "less" vulnerable rather than "more". Qubes has been trying to migrate away from PVs altogether (rather than e.g., placing PVs into those shims) due to PV vulnerabilities in general. In fact, even before these HW vulnerabilities were discovered, the process towards PVH was ongoing which is why R4.0 rcs as is are much better protected already. These vulnerabilities only accelerated this process. There will be, unfortunately, be one limitation to this migration still due to PCI passthrough: VMs with PCI devices need to remain PV (or their stubdoms in R4.0). > "Note this shim-based approach prevents attacks on the host, but leaves > the guest vulnerable to Meltdown attacks by its own unprivileged > processes; this is true even if the guest OS has KPTI or similar > Meltdown mitigation." > https://xenbits.xen.org/xsa/xsa254/README.which-shim Also, note that one of the fundamental assumption with Qubes security model is that the VMs _will get compromised_ (regardless of HW exploits). What Qubes aims to protect against is escalation from a compromised VM to host or to another VM. -- i. -- 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/alpine.DEB.2.20.1801172252250.29076%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
On Monday, January 15, 2018 at 12:57:09 PM UTC+1, awokd wrote: > It matters a bit because Spectre is harder to exploit than Meltdown. IIUR, > Qubes' design allowed it to constrict Meltdown to a single VM Not in PV, which are primary type of VM in 3.2. > I'm still > somewhat unclear on how Spectre operates under hardware virtualization but > you're right, it needs to be fixed. As far as I understand, Spectre can read the memory available of victim. That is: * If an application does not mitigate Spectre and attacker finds useful entry point, attacker can read memory of the application (but nothing more). * If VM kernel does not mitigate Spectre and attacker finds useful entry point, attacker can probably read memory of whole VM (but other VMs are not affected). * If Xen does not mitigate Spectre and attacker finds useful entry point, attacker can probably read memory of whole system. Please note that: * Attacker needs a suitable entry point. It might be difficult to find it. * All code needs to be recompiled in order to mitigate Spectre. It is not binary that you are/aren't protected. Some parts of system might be protected at the same time when others aren't. * Lowlevel components might need additional work because of assembly code. * Microcode update is needed only for some variants of patches. But retpoline might be preferred for both performance reasons and not need of microcode update. Regards, Vít Šesták 'v6ak' -- 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/cb5afe86-bd1a--8bb8-4bc875eeab2d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
On Mon, January 15, 2018 1:15 am, Nik H wrote: > On Monday, January 15, 2018 at 12:20:48 AM UTC+7, Vít Šesták wrote: > >> As far as I understand it, microcode update cannot fix it. It just >> brings some new instructions that can be used for Spectre fix. (But >> they don't help on their own.) >> >> You can try to update your BIOS if it is well supported by your vendor. >> Mine is. >> >> >> Alternatively, you can try to update microcode via Xen. (In fact, the >> new microcode is loaded on every boot, because CPU has no persistent >> storage for that. It should be loaded in early stage of boot.*) Xen has >> some documentation, it would be probably enough to use some Linux >> package and add something like “ucode=scan” to Xen parameters: >> https://wiki.xenproject.org/wiki/XenParavirtOps/microcode_update > > Thanks, this is good info. I found instructions to update microcode in > linux - seems very simple. Xen instructions seem simple as well but where > do I enter this? In the Dom0 terminal? I am a bit unclear as to how Dom0 > and Xen interact. If you're referring to the "ucode=scan" addition to the bootloader; yes, you'd enter those from dom0. > As a side-note, spectre does compromise the entire qubes architecture. I > know, nobody was thinking about these things, so no shame in that. But > one of the main premises in qubes is that VMs are isolated from each > other, and that is no longer the case as long as spectre is out there. > Good that meltdown is not an issue, yes, but doesn't really matter, > weakest link and all that. It matters a bit because Spectre is harder to exploit than Meltdown. IIUR, Qubes' design allowed it to constrict Meltdown to a single VM versus other OS designs where that would give access to the entire system. I'm still somewhat unclear on how Spectre operates under hardware virtualization but you're right, it needs to be fixed. -- 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/79d8c47ca62d358458e6850a36a74686.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
Good point, I forgot this one. of course, it would, but I am not sure if Qubes is ready for that. But it could be useful to use 32-bit stubdoms for those reasons. They do rather I/O-bound work (=> minimal performance penalty) and they don't need so much memory to utilize more than 32-bit pointers. (Also, using 32-bit pointers can make a minor performance gain.) On other VMs than stubdoms, it is not so easily deployable, because user might have some 64-bit only software there. At least, it is impossible to deploy it automatically (via update) without breaking anything. It is possible to use 32-bit stubdom on a 64-bit system? Regards, Vít Šesták 'v6ak' -- 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/4e004690-cbab-4742-b625-0d583159dde1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
On Saturday, January 13, 2018 at 10:50:11 AM UTC-8, Vít Šesták wrote: > I have one more idea: The Vixen patch could be useful for VMs with PCI > devices. Memory balooning is not supported there anyway. QEMU in dom0 looks > ugly, but this case is a bit different: AFAIU, the attacker can directly talk > to QEMU if and only if she has escaped from PV. Maybe it is not nice, but it > is not that bad either. > > With Qubes 3.2, I believe this can be a clean win. Compared to the proposal > (focusing on VMs with PCI devices only): > > * It fixes the Meltdown. The proposal does not address it for those VMs. > * Attacker can try to break out from both PV and then from HVM or (more > likely) from PV and then pwn QEMU. This is arguably harder than breaking > directly from PV. > > With Qubes 4.0 (still focusing on VMs with PCI devices only), it is still > probably an improvement: > * If attacker can pwn QEMU (but not PV), she can with the current proposal > read the whole memory using Meltdown. With Vixen, QEMU vulnerability is > probably not enough for Meltdown. > * If attacker can escape from PV (but not QEMU), she can do pretty nothing. > Well, with Vixen, she can read the content of the container, but I don't > think this is a serious issue. > * If attacker can both escape from PV and attack QEMU, you are doomed in > either case. > * Theoretically: If attacker can escape from HVM, you are better protected > with Vixen (because attacker needs to escape from PV first). > * If there are some vulnerabilities that do not allow full VM escape, you are > probably still better protected with Vixen. Qemu in dom0 runs as an ordinary > process (so attacks like buffer overread have quite limited impact) and it is > the same case for PV. > > Have I missed something? > > I don't say that Qubes should go this way. Maybe there are better ways to > achieve some goals (especially for 4.0+). I am just saying that QEMU in dom0 > – however horrible it looks – might be acceptable in this special case. > > Regards, > Vít Šesták 'v6ak' Would using a 32-bit PV provide any additional protection for Xen? -- 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/19b6e545-01ba-4851-be9e-3361341a0ae2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
On Saturday, January 13, 2018 at 1:19:18 PM UTC+1, Vincent Adultman wrote: > IIUC this still seems fairly awful from a usability perspective if we think > of the added cognitive load of watching what is running when and remembering > or making choices on what to close / restart when (I'm reading between the > lines and guessing this has had something to do with decision on > reintroduction of Qubes manager?). It is just temporary countermeasure. Actually, Qubes was not designed with Meldown in mind. In fact, no OS was. The countermeasures are rather the best we can do until it gets fixed than something that shoul be smooth and user friendly. IMHO it is just a coincidence that Qubes Manager was reintroduced those days. Regards, Vít Šesták 'v6ak' -- 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/70f0d6e1-39bc-4a33-9d74-cac9fd4da1e2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
I have one more idea: The Vixen patch could be useful for VMs with PCI devices. Memory balooning is not supported there anyway. QEMU in dom0 looks ugly, but this case is a bit different: AFAIU, the attacker can directly talk to QEMU if and only if she has escaped from PV. Maybe it is not nice, but it is not that bad either. With Qubes 3.2, I believe this can be a clean win. Compared to the proposal (focusing on VMs with PCI devices only): * It fixes the Meltdown. The proposal does not address it for those VMs. * Attacker can try to break out from both PV and then from HVM or (more likely) from PV and then pwn QEMU. This is arguably harder than breaking directly from PV. With Qubes 4.0 (still focusing on VMs with PCI devices only), it is still probably an improvement: * If attacker can pwn QEMU (but not PV), she can with the current proposal read the whole memory using Meltdown. With Vixen, QEMU vulnerability is probably not enough for Meltdown. * If attacker can escape from PV (but not QEMU), she can do pretty nothing. Well, with Vixen, she can read the content of the container, but I don't think this is a serious issue. * If attacker can both escape from PV and attack QEMU, you are doomed in either case. * Theoretically: If attacker can escape from HVM, you are better protected with Vixen (because attacker needs to escape from PV first). * If there are some vulnerabilities that do not allow full VM escape, you are probably still better protected with Vixen. Qemu in dom0 runs as an ordinary process (so attacks like buffer overread have quite limited impact) and it is the same case for PV. Have I missed something? I don't say that Qubes should go this way. Maybe there are better ways to achieve some goals (especially for 4.0+). I am just saying that QEMU in dom0 – however horrible it looks – might be acceptable in this special case. Regards, Vít Šesták 'v6ak' -- 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/f51baeff-52eb-4d65-bfb7-7c15a3a0e102%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
On Friday, January 12, 2018 at 5:24:25 AM UTC-5, haaber wrote: > >> > >> so people saying the intel meltdown bios patch slows performance. I got > >> an increase in performance lmao. probably depends on os though. > > > > but also in my particular case they also addressed other bugs, but intel > > pushed the bios patch for meltdown, so worth a check from your boards > > manufacturer site. > > > When I download the (in my case with HP a win exe) BIOS update file, it > contains the "real" bios update (the .BIN file) and some other crap. The > only way to avoid tampered downloads seems to download it several times, > via tor and some other independent sources & to compare them. I guess > you all do that? > > HP does not seem to deliver pgp signatures afaik. But they do ship some > signature files. Is someone aware of how checking these manually? Bernhard comparing with tor is all I do too. You can also update the HP bios from a usb without using windows if you prefer. https://support.hp.com/us-en/document/c00042629 -- 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/a466d935-9c00-4cd3-806c-65953caa79bb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
>> Only running VMs are vulnerable >> >> Since Qubes OS is a memory-hungry system, it seems that an attacker >> would only be able to steal secrets from VMs running concurrently with >> the attacking VM. This is because any pages from shutdown VMs will >> typically very quickly get allocated to other, running VMs and get wiped >> as part of this procedure. IIUC this still seems fairly awful from a usability perspective if we think of the added cognitive load of watching what is running when and remembering or making choices on what to close / restart when (I'm reading between the lines and guessing this has had something to do with decision on reintroduction of Qubes manager?). sys-net is considered to be likely / easily compromised (such that there seems some real utility in making it a dispvm under 4). However, it will also be running for most users in most everyday cases for long periods. A common use case for open at one time for me for internet banking might be at minimum sys-net, sys-firewall, sys-usb, vault and a dispvm (as shitty banks here often loading things off marketing or even advertising network domains changing fairly regularly). If we're saying that in an ideal situation, sys-net and sys-usb (if it has had any untrusted devices attached to it) are started clean else the secrets vault is at risk, that seems to remain a very serious problem. The other approach seems to be to store the banking secrets in a banking vm, and do the browsing as well from there. Some sensitive tasks can no doubt be done with sys-net shut down, but by no means all. If we're considering that this will be the case for quite some time(?) due to Xen approach, do we need to offer some sort of recipe situation for vm-start (where I can ensure my "red" vms are shut down or cycled before my vault is started for example). I try to pay my Qubes dues by offering assistance in IRC, and I'm anticipating here the sort of user willing to put effort into thinking about how they need to partition their domains, and maybe even write some custom rules / scripts but after that needs the system not to overly get in the way of day to day tasks / require constant tinkering. Vince -- 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/y4JzRn90_0mDNiNrt3Hq_kPJY6KbTxstTz8z2KvR_8ORlcJ7thJC0zOZupxxEuewcc3TnhVx5Rrz400I1B6XLy9BYjNVHinu4kNHFRn7dIU%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
> There are two shims: PV-in-HVM aka Vixen and PV-in-PVH aka Comet. Both have limitations making them incompatible (or at least suboptimal) in Qubes Marek, thanks for the clarification. So, IIUC, Vixien's shim is no-go and Comet's shim would do the same (but at higher cost) as migration to PVH where possible. Now, your solution looks like a reasonable tradeoff. > Indeed, the table is about generic/default VMs. If one choose HVM, it will have PV stubdomain, regardless of Qubes version. We'll clarify this. The problem is not just when explicitly requesting HVM (while not explicitly stated, I can understand it is not about that), it seem to be inaccurate even about the default VM types. As far as I know, PVH For Qubes 4, it seems OK, we got rid of some stubdoms. In Qubes 3.2, currently no stubdoms are used for such VMs, but you have PV in the table. For 3.2+ for VMs with PCI devices, you also have noted that there is PV stubdom, but there is AFAIU no stubdom. > ## Only running VMs are vulnerable > > Since Qubes OS is a memory-hungry system, it seems that an attacker > would only be able to steal secrets from VMs running concurrently with > the attacking VM. This is because any pages from shutdown VMs will > typically very quickly get allocated to other, running VMs and get wiped > as part of this procedure. It depends. In fact, not letting more-trusted-VMs and less-trusted-VMs run together (as advised) makes Qubes less memory hungry. On a system with something like 32 GiB of RAM, this can lead to having much spare memory. I have upgraded to 32 GiB after realizing that I'd like to have slightly more than 16 GiB and maybe it would be better to have two the same modules. As a result, I have much spare memory now. IIUC, the memory is usually not overwritten until it is assigned to another VM, so the data are at risk even after shutdown. For this reason, I've created a BrickVM whose purpose is just to allocate unneeded memory. Unfortunately, the VM does not take much memory even if it could, so I have decided to run about twenty or thirty DVMs for this purpose. (OK, I could run something memory-intensive in the BrickVM, but running many DVMs (or closing them if needed) seems to be easier.) -- 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/6dab89ca-8b43-4066-bc59-99a08608c7bc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2018-01-12 04:24, haaber wrote: >>> >>> so people saying the intel meltdown bios patch slows >>> performance. I got an increase in performance lmao. probably >>> depends on os though. >> >> but also in my particular case they also addressed other bugs, >> but intel pushed the bios patch for meltdown, so worth a check >> from your boards manufacturer site. >> > When I download the (in my case with HP a win exe) BIOS update > file, it contains the "real" bios update (the .BIN file) and some > other crap. The only way to avoid tampered downloads seems to > download it several times, via tor and some other independent > sources & to compare them. I guess you all do that? > Yes, that's what I do. You can also upload the file to Virus Total (or similar). - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpZfKYACgkQ203TvDlQ MDBwdw/+L3xxP48xEHGI+cd7mw2lw/twXnCz/G0zOcfrUCtdayPLicn921rAcqss WwZeQGHBSn+ff+CWr7HRtnqn9DLWgVu4kYR+JE9tldf33wSKDJJFwRb0XXoeos2m oOjOKmMRwYWS2d5VpKLjPmTi8If9dCQvUiH3Ru7XwrarINivZYrLPYTruEZ9joNg V8cXDuSxgsz853/J9srroFRH/52q7EzW5fW/AGutkh7XrV4Ru4KaEpP2EEKLM0// VUDBmsO/MrMu2Fsah8b6ypK65hpug5ewG/sx8bSW/O0kFjHzc8zCaffYDtyjt7z5 ezQpFj2XW08Z32nSkTgoXHi/PF07Tmkb5soYYpFfwe8DgaOdOdBfSnTja18d8E65 fjeVrnJANIIy/41oDK6oSlugXWrG50CDflznVCz48W01cX2XAXHifl3ScxT0KTr+ pUqNHWPpdVudp9KP25AFPYbQ5XxBpw07ak4xZC4XbCuNmG6KzPriRs8ncT704pDN ethh1DViRyeF53xKW/FZS+zktRH2dmkbwVZvdJjtPAo2KnznVgpnMskW/2H6Y0VS +Pt5f0YYihEM4Gb0+EB8rGMKLP6s1xMaQilki19VLkY0xVlQ6MT7cSEYP3Y5BIjG tN3Nl2Rv458u4PnACCZnJtYFNxhQxfQUhCAC7JtXIbfh1T1+uJU= =7yAc -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/6ae8c0fe-d8b4-5bc4-83b9-ae1ea5e95fc9%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
>> >> so people saying the intel meltdown bios patch slows performance. I got an >> increase in performance lmao. probably depends on os though. > > but also in my particular case they also addressed other bugs, but intel > pushed the bios patch for meltdown, so worth a check from your boards > manufacturer site. > When I download the (in my case with HP a win exe) BIOS update file, it contains the "real" bios update (the .BIN file) and some other crap. The only way to avoid tampered downloads seems to download it several times, via tor and some other independent sources & to compare them. I guess you all do that? HP does not seem to deliver pgp signatures afaik. But they do ship some signature files. Is someone aware of how checking these manually? Bernhard -- 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/6d0c435f-6926-55ae-f5f3-39f5ee38%40web.de. For more options, visit https://groups.google.com/d/optout.