Date: Mon, 12 Feb 2018 13:31:02 -0500 From: Tycho Nightingale <tychon@freebsd.org> To: Shawn Webb <shawn.webb@hardenedbsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r329162 - in head/sys/amd64/vmm: amd intel Message-ID: <ACC95F46-E805-4A4D-BA96-5EDB591E7295@freebsd.org> In-Reply-To: <20180212153700.xbmbctnjtawum76h@mutt-hbsd> References: <201802121445.w1CEjR3n082516@repo.freebsd.org> <20180212153700.xbmbctnjtawum76h@mutt-hbsd>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, > On Feb 12, 2018, at 10:37 AM, Shawn Webb <shawn.webb@hardenedbsd.org> = wrote: >=20 > On Mon, Feb 12, 2018 at 02:45:27PM +0000, Tycho Nightingale wrote: >> Author: tychon >> Date: Mon Feb 12 14:45:27 2018 >> New Revision: 329162 >> URL: https://svnweb.freebsd.org/changeset/base/329162 >>=20 >> Log: >> Provide further mitigation against CVE-2017-5715 by flushing the >> return stack buffer (RSB) upon returning from the guest. >>=20 >> This was inspired by this linux commit: >> = https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/= arch/x86/kvm?id=3D117cc7a908c83697b0b737d15ae1eb5943afe35b >>=20 >> Reviewed by: grehan >> Sponsored by: Dell EMC Isilon >> Differential Revision: https://reviews.freebsd.org/D14272 >>=20 >> Modified: >> head/sys/amd64/vmm/amd/svm_support.S >> head/sys/amd64/vmm/intel/vmcs.c >> head/sys/amd64/vmm/intel/vmx.h >> head/sys/amd64/vmm/intel/vmx_support.S >>=20 >> Modified: head/sys/amd64/vmm/amd/svm_support.S >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> --- head/sys/amd64/vmm/amd/svm_support.S Mon Feb 12 14:44:21 2018 = (r329161) >> +++ head/sys/amd64/vmm/amd/svm_support.S Mon Feb 12 14:45:27 2018 = (r329162) >> @@ -113,6 +113,23 @@ ENTRY(svm_launch) >> movq %rdi, SCTX_RDI(%rax) >> movq %rsi, SCTX_RSI(%rax) >>=20 >> + /* >> + * To prevent malicious branch target predictions from >> + * affecting the host, overwrite all entries in the RSB upon >> + * exiting a guest. >> + */ >> + mov $16, %ecx /* 16 iterations, two calls per loop */ >> + mov %rsp, %rax >> +0: call 2f /* create an RSB entry. */ >> +1: pause >> + call 1b /* capture rogue speculation. */ >> +2: call 2f /* create an RSB entry. */ >> +1: pause >> + call 1b /* capture rogue speculation. */ >> +2: sub $1, %ecx >> + jnz 0b >> + mov %rax, %rsp >> + >> /* Restore host state */ >> pop %r15 >> pop %r14 >>=20 >=20 > For amd systems, isn't use of lfence required for performance > reasons[1]? Or am I conflating two things? >=20 > 1: https://reviews.llvm.org/D41723 For what AMD calls V2 (the window of a speculative execution between = indirect branch predictions and resolution of the correct target) there = are a few mitigations cited in their white paper: = https://developer.amd.com/wp-content/resources/Managing-Speculation-on-AMD= -Processors.pdf depending on the specific code you are trying to =E2=80=9Cfix=E2=80=9D. = In my interpretation lfence is a component of several of the possible = mitigations when one wants to =E2=80=9Cfix=E2=80=9D a specific indirect = branch but does not ensure that subsequent branches will not be = speculated around. In this case we are trying to guard against the more = generic case of "entering more privileged code=E2=80=9D i.e. returning = from the guest to hypervisor aka host and protect all subsequent = indirect branches without needing to apply an lfence to them = individually. To do that, I=E2=80=99ve implemented mitigation V2-3 = where the return address predictor is filled with benign entries. Does that help? Tycho=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ACC95F46-E805-4A4D-BA96-5EDB591E7295>