On Thu, Jul 12, 2018 at 2:11 PM Philip Guenther <guent...@openbsd.org>

> CVSROOT:        /cvs
> Module name:    src
> Changes by:     guent...@cvs.openbsd.org        2018/07/12 08:11:11
> Modified files:
>         sys/arch/amd64/amd64: cpu.c identcpu.c locore.S machdep.c pmap.c
>                               vector.S
>         sys/arch/amd64/conf: ld.script
>         sys/arch/amd64/include: asm.h codepatch.h
> Log message:
> Reorganize the Meltdown entry and exit trampolines for syscall and
> traps so that the "mov %rax,%cr3" is followed by an infinite loop
> which is avoided because the mapping of the code being executed is
> changed.  This means the sysretq/iretq isn't even present in that
> flow of instructions in the kernel mapping, so userspace code can't
> be speculatively reached on the kernel mapping and totally eliminates
> the conditional jump over the the %cr3 change that supported CPUs
> without the Meltdown vulnerability.  The return paths were probably
> vulnerable to Spectre v1 (and v1.1/1.2) style attacks, speculatively
> executing user code post-system-call with the kernel mappings, thus
> creating cache/TLB/etc side-effects.

Damnit, I left out that since this evolves the _Meltdown_ fix with mapping
_over_ the trampoline, we're calling this the Tuna Meltover.

Because you can tuna meltover, but you can't tune a fish.
(hat tip to the author of the tunefs(8) manpage.)

Philip Guenther

Reply via email to