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.

[qubes-users] Re: Qubes Manager is coming back in Qubes 4.0-rc4!

[Nik H]

Great news, thank you!

-- 
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/9a3deef1-d0cb-489c-8590-e07e04eeb5db%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)

[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: Duplicate MAC address error

[Nik H]

On Friday, December 22, 2017 at 5:34:41 PM UTC+7, Reynir Björnsson wrote:
> Hi,
> 
> On Tuesday, 19 December 2017 09:39:37 UTC+1, Kushal Das  wrote:
> > Hi,
> > 
> > My Qubes 4.0rc3 (updated) is showing error for sys-net vm saying it
> > has a duplicate mac address for the NIC. This error message came
> > before (on the fresh install), and was fixed in a few reboots. But,
> > now I could not make it work for the last few days :(
> > 
> > Any tips how to solve this? I could not find any duplicate NIC value
> > in the /var/lib/qubes/qubes.xml file.
> > 
> > 
> > Kushal
> > -- 
> > Staff, Freedom of the Press Foundation
> > CPython Core Developer
> > Director, Python Software Foundation
> > https://kushaldas.in
> 
> It may be a coincidence, but when it happened to me I got sys-net running by 
> shutting down sys-whonix first. I've since disabled sys-whonix and haven't 
> had the issue again, although I haven't been rebooting much since.
> 
> - Reynir

I had the same thing happen; I shut down whonix, that didn't work. Then I also 
shut down sys-firewall; then I could once again start sys-net. Thanks for the 
tip!

-- 
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/e58a0fa7-93dd-4982-b101-26d44fb30976%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] How to copy-paste into Terminal from global clipboard?

[Nik H]

This may be a silly question but I've been unable to figure it out: I quite 
often want to paste something from a browser into a Terminal in a different vm.

Global, secure copy / paste is Ctrl-Shift-c / Ctrl-Shift-v

In a Terminal window, these shortcuts are mapped to normal copy paste, rather 
than inter-vm copy pasting so it doesn't work out of the box.

I then changed the global copy paste shortcut to use the windows key. It's 
explained elsewhere but it means changing guid.conf and adding Mod4-c and 
Mod4-v for secure copy paste.

This works great (well - after restart)! I tested it in various apps, it does 
what it should.

However, it still doesn't work on the Terminal application. For whatever 
reason, Windows-C just types a C and the same for V. Global keyboard shortcuts 
seem to be ignored while Terminal is active.

Anybody have an idea how to solve this? Thanks!

-- 
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/4782698b-c89a-4f40-8db8-ca5a99ba1a7c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.