cynicalsecurity is a user on You can follow them or interact with them if you have an account anywhere in the fediverse. If you don't, you can sign up here.
cynicalsecurity @cynicalsecurity

Good Lord, the questions are not exactly worthy of the talk on SPECTRE/MELTDOWN...

· Web · 0 · 2

@phessler I am so unimpressed with the questions & answers.

@cynicalsecurity If I understand his explanation of Spectre 2 correctly, openbsd's vmm is immune.

IIUC, it depends on the guest's memory being part of the kernel (I am assuming that is true in kvm). In openbsd, the guest's memory is in the vmd user process, not the kernel.

@phessler I was thinking exactly the same… The guest memory being part of the kernel is a critical requirement for the hack to work…

I had not realised that to be perfectly honest, silly me.

@phessler @cynicalsecurity I don’t think its that simple. It is true that you can only read the memory that has mappings in the kernel but you can still extract interesting information, e.g. register values of other guests etc.

See also Udo’s (author of NOVA microkernel& former (?) Intel employe) comments on the Genode Mailing list:

@Kensan @cynicalsecurity each guest is their own process (not thread).

I think that means only normal Type 1 or Type 3 attacks can be done.

I'm not saying it is completely immune to Spectre, only I think it is for that variant.

@phessler @cynicalsecurity I am not conviced that there is a requirement for guest memory mappings to be present in the hypervisor.
I just watched the talk again an here is my "transcript":

"Also, guest memory is mapped in the hypervisor. So while the hypervisor and the guest don't share their virtual address space the hypervisor has a separate mapping of all the pages you have in the guest."

@cynicalsecurity @phessler "This means that if you can figure out where this mapping in the hypervisor is you can place guest-controlled data in memory in the hypervisor and then reference this memory from the instructions that you are transiently executing to get even more control over the execution in the hypervisor."

@phessler @cynicalsecurity It greatly simplifies the attack because you can just write the eBPF bytecode somewhere in guest memory and then directly load it as bpf instruction stream when attacking the hypervisor via __bpf_prog_run.

@cynicalsecurity @phessler However, if you find a gadget in the hypervisor then you can direct speculative execution there without having to load anything from guest memory.

@Kensan @cynicalsecurity well, openbsd doesn't _have_ ebpf. and the memory for vmd guests isn't mapped into the kernel any more than a normal userland program would be.

the normal linux rules do not apply, because it's not linux.

and yes, if you can find a gadget, then it's pretty much gameover.

@phessler @cynicalsecurity Yes, I know OpenBSD kernel and VMM are very different and I definitely did not want to insinuate something along these lines ;)
But I do not think that not having guest memory mapped means variant 2 spectre is impossible.

@cynicalsecurity Had not read this before I wrote by blurb re: Q&A. Missed opportunity!