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)

[Vít Šesták]

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)

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

[David Hobach]

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)

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

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.

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.

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.