Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)

[Jean-Philippe Ouellet]

On Thu, Jan 18, 2018 at 3:49 PM, Vít Šesták

wrote:
> 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)

[Vít Šesták]

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)

[Lorenzo Lamas]

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)

[cooloutac]

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)

['awokd' via qubes-users]

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)

[Nik H]

On Jan 16, 2018, at 2:56 AM, Vít Šesták 
 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.

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)

['awokd' via qubes-users]

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)

[cooloutac]

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)

[Marek Marczykowski-Górecki]

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

[Ilpo Järvinen]

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.

[qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)

[Lorenzo Lamas]

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?
Then it should be made clear that the VM's will be more vulnerable to Meltdown:
"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

-- 
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/2ed7448b-7d79-479b-ba9f-85a5583bbbcf%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)

[Vít Šesták]

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.

[qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)

[Vít Šesták]

On Monday, January 15, 2018 at 2:15:34 AM UTC+1, Nik H wrote:
> 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.

Well, dom0 is a privileged domain and any administration of Xen should be done 
from it. So, dom0 terminal is probably a good start.

You will probably need to adjust Xen parameters. It depends if you have UEFI or 
legacy BIOS. You can see both variants (but you need to write something else 
than „iommu=no-igfx“) in this (otherwise unrelated) article: 
https://www.qubes-os.org/doc/intel-igfx-troubleshooting/

> I am guessing normal VMs do not have enough privileges to update microcode 
> (well... hopefully, otherwise compromised VMs could install malicious 
> microcode...)

I hope so. They are digitally signed (at least at Intel), but still…

> As a side-note, spectre does compromise the entire qubes architecture.

Not fully.

> Good that meltdown is not an issue, yes

As far as I understand, Meltdown _is_ an issue. It allows reading memory of 
whole system. It will be hopefully fixed soon.

Spectre is harder to exploit, but it will also take longer to fix it.

-- 
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/d2a3b048-0494-47d1-bc31-00802d57395d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)

[cooloutac]

On Sunday, January 14, 2018 at 12:20:48 PM UTC-5, 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
> 
> Regards,
> Vít Šesták 'v6ak'
> 
> *) Some μcode updates can be loaded even runtime, but this is not so general 
> and I don't recommend it. As far as I understand, the result of runtime 
> patching might vary on what instructions have been used before the attempt to 
> patch it, so you could end up with some race condition.

do you mean you need bios microcode update AND software fixes together to 
prevent these attacks?

Also did you notice the "20% increase in cpu utilization" they are talking 
about?   Because I feel I have had a dramatic increase in performance. I'm 
becoming skeptical about some of the information out there. 

-- 
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/01aaec7e-9e3c-4a18-b563-1c0b2044df21%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)

['awokd' via qubes-users]

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.

[qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)

[Nik H]

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
> 
> Regards,
> Vít Šesták 'v6ak'
> 
> *) Some μcode updates can be loaded even runtime, but this is not so general 
> and I don't recommend it. As far as I understand, the result of runtime 
> patching might vary on what instructions have been used before the attempt to 
> patch it, so you could end up with some race condition.


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.

I am guessing normal VMs do not have enough privileges to update microcode 
(well... hopefully, otherwise compromised VMs could install malicious 
microcode...)

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. 


-- 
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/effb5ab9-2bda-46d3-a9c1-604b1f1c1fbe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)

[Vít Šesták]

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

Regards,
Vít Šesták 'v6ak'

*) Some μcode updates can be loaded even runtime, but this is not so general 
and I don't recommend it. As far as I understand, the result of runtime 
patching might vary on what instructions have been used before the attempt to 
patch it, so you could end up with some race condition.

-- 
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/a7654f30-92d4-4386-8001-f2d731c72e65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)

[pixel fairy]

what about the cpu microcode? can a package be backported for it? or does that 
have to be done through xen?

fedora 26 has some (theoretical?) protection against meltdown, maybe qubes-4 
should update dom0 to that in the rc.

-- 
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/e166d5cb-5635-4647-8bbf-bebb463120fd%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)

[Vít Šesták]

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)

[Doug M]

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)

[Vít Šesták]

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)

[Vít Šesták]

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)

[cooloutac]

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)

['Vincent Adultman' via qubes-users]

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

[Vít Šesták]

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

[Andrew David Wong]

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

[haaber]

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

[qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)

[cooloutac]

On Thursday, January 11, 2018 at 10:26:53 PM UTC-5, cooloutac wrote:
> On Thursday, January 11, 2018 at 9:57:50 AM UTC-5, Andrew David Wong wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > Dear Qubes Community,
> > 
> > We have just published Qubes Security Bulletin (QSB) #37:
> > Information leaks due to processor speculative execution bugs.
> > 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 #37 in the qubes-secpack:
> > 
> > 
> > 
> > Learn about the qubes-secpack, including how to obtain, verify, and
> > read it:
> > 
> > 
> > 
> > View all past QSBs:
> > 
> > 
> > 
> > View XSA-254 in the XSA Tracker:
> > 
> > 
> > 
> > ```
> >  ---===[ Qubes Security Bulletin #37 ]===---
> > 
> >January 11, 2018
> > 
> > 
> > Information leaks due to processor speculative execution bugs
> > 
> > Summary
> > 
> > 
> > On the night of January 3, two independent groups of researchers
> > announced the results of their months-long work into abusing modern
> > processors' so-called speculative mode to leak secrets from the system's
> > privileged memory [1][2][3][4]. As a response, the Xen Security Team
> > published Xen Security Advisory 254 [5]. The Xen Security Team did _not_
> > previously share information about these problems via their (non-public)
> > security pre-disclosure list, of which the Qubes Security Team is a
> > member.
> > 
> > In the limited time we've had to analyze the issue, we've come to the
> > following conclusions about the practical impact on Qubes OS users and
> > possible remedies. We'll also share a plan to address the issues in a
> > more systematic way in the coming weeks.
> > 
> > Practical impact and limiting factors for Qubes users
> > ==
> > 
> > ## Fully virtualized VMs offer significant protection against Meltdown
> > 
> > Meltdown, the most reliable attack of the three discussed, cannot be
> > exploited _from_ a fully-virtualized (i.e. HVM or PVH) VM. It does not
> > matter whether the _target_ VM (i.e. the one from which the attacker
> > wants to steal secrets) is fully-virtualized. In Qubes 3.x, all VMs are
> > para-virtualized (PV) by default, though users can choose to create
> > fully-virtualized VMs.  PV VMs do not protect against the Meltdown
> > attack. In Qubes 4.0, almost all VMs are fully-virtualized by default
> > and thus offer protection. However, the fully-virtualized VMs in Qubes
> > 3.2 and in release candidates 1-3 of Qubes 4.0 still rely on PV-based
> > "stub domains", making it possible for an attacker who can chain another
> > exploit for qemu to attempt the Meltdown attack.
> > 
> > ## Virtualization makes at least one variant of Spectre seem difficult
> > 
> > Of the two Spectre variants, it _seems_ that at least one of them might
> > be significantly harder to exploit under Xen than under monolithic
> > systems because there are significantly fewer options for the attacker
> > to interact with the hypervisor.
> > 
> > ## All attacks are read-only
> > 
> > It's important to stress that these attacks allow only _reading_ memory,
> > not modifying it. This means that an attacker cannot use Spectre or
> > Meltdown to plant any backdoors or otherwise compromise the system in
> > any persistent way.  Thanks to the Qubes OS template mechanism, which is
> > used by default for all user and system qubes (AppVMs and ServiceVMs),
> > simply restarting a VM should bring it back to a good known state for
> > most attacks, wiping out the potential attacking code in the
> > TemplateBasedVM (unless an attacker found a way to put triggers within
> > the user's home directory; please see [8] for more discussion).
> > 
> > ## 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.
> > 
> > ## PGP and other cryptographic keys are at risk
> > 
> > For VMs that happen to be running concurrently with the attacking VM, it
> > seems possible that these attacks might allow the attacker to steal
> > cryptographic keys, including private PGP keys.
> > 
> > ## Disk encryption and screenlocker passwords are at risk
> > 
> > There is one VM that is always running concurrently with other VMs: the
> > AdminVM (dom0). This VM contains at least two important user secrets:
> > 
> >  - The disk (LUKS) encryption key (and likely the 

[qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)

[cooloutac]

On Thursday, January 11, 2018 at 9:57:50 AM UTC-5, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Dear Qubes Community,
> 
> We have just published Qubes Security Bulletin (QSB) #37:
> Information leaks due to processor speculative execution bugs.
> 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 #37 in the qubes-secpack:
> 
> 
> 
> Learn about the qubes-secpack, including how to obtain, verify, and
> read it:
> 
> 
> 
> View all past QSBs:
> 
> 
> 
> View XSA-254 in the XSA Tracker:
> 
> 
> 
> ```
>  ---===[ Qubes Security Bulletin #37 ]===---
> 
>January 11, 2018
> 
> 
> Information leaks due to processor speculative execution bugs
> 
> Summary
> 
> 
> On the night of January 3, two independent groups of researchers
> announced the results of their months-long work into abusing modern
> processors' so-called speculative mode to leak secrets from the system's
> privileged memory [1][2][3][4]. As a response, the Xen Security Team
> published Xen Security Advisory 254 [5]. The Xen Security Team did _not_
> previously share information about these problems via their (non-public)
> security pre-disclosure list, of which the Qubes Security Team is a
> member.
> 
> In the limited time we've had to analyze the issue, we've come to the
> following conclusions about the practical impact on Qubes OS users and
> possible remedies. We'll also share a plan to address the issues in a
> more systematic way in the coming weeks.
> 
> Practical impact and limiting factors for Qubes users
> ==
> 
> ## Fully virtualized VMs offer significant protection against Meltdown
> 
> Meltdown, the most reliable attack of the three discussed, cannot be
> exploited _from_ a fully-virtualized (i.e. HVM or PVH) VM. It does not
> matter whether the _target_ VM (i.e. the one from which the attacker
> wants to steal secrets) is fully-virtualized. In Qubes 3.x, all VMs are
> para-virtualized (PV) by default, though users can choose to create
> fully-virtualized VMs.  PV VMs do not protect against the Meltdown
> attack. In Qubes 4.0, almost all VMs are fully-virtualized by default
> and thus offer protection. However, the fully-virtualized VMs in Qubes
> 3.2 and in release candidates 1-3 of Qubes 4.0 still rely on PV-based
> "stub domains", making it possible for an attacker who can chain another
> exploit for qemu to attempt the Meltdown attack.
> 
> ## Virtualization makes at least one variant of Spectre seem difficult
> 
> Of the two Spectre variants, it _seems_ that at least one of them might
> be significantly harder to exploit under Xen than under monolithic
> systems because there are significantly fewer options for the attacker
> to interact with the hypervisor.
> 
> ## All attacks are read-only
> 
> It's important to stress that these attacks allow only _reading_ memory,
> not modifying it. This means that an attacker cannot use Spectre or
> Meltdown to plant any backdoors or otherwise compromise the system in
> any persistent way.  Thanks to the Qubes OS template mechanism, which is
> used by default for all user and system qubes (AppVMs and ServiceVMs),
> simply restarting a VM should bring it back to a good known state for
> most attacks, wiping out the potential attacking code in the
> TemplateBasedVM (unless an attacker found a way to put triggers within
> the user's home directory; please see [8] for more discussion).
> 
> ## 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.
> 
> ## PGP and other cryptographic keys are at risk
> 
> For VMs that happen to be running concurrently with the attacking VM, it
> seems possible that these attacks might allow the attacker to steal
> cryptographic keys, including private PGP keys.
> 
> ## Disk encryption and screenlocker passwords are at risk
> 
> There is one VM that is always running concurrently with other VMs: the
> AdminVM (dom0). This VM contains at least two important user secrets:
> 
>  - The disk (LUKS) encryption key (and likely the passphrase)
>  - The screenlocker passphrase
> 
> In order to make use of these secrets, however, the attacker would have
> to conduct a physical attack on the user's computer (e.g. steal the
> laptop physically). Users who use the same passphrase to encrypt their
> backups may also be affected.