On Mon, 2018-02-12 at 11:29 +0530, afzal mohammed wrote: > Hi, > > On Sun, Feb 11, 2018 at 11:19:10AM -0800, tip-bot for David Woodhouse wrote: > > > > > x86/speculation: Use IBRS if available before calling into firmware > > > > Retpoline means the kernel is safe because it has no indirect branches. > > But firmware isn't, so use IBRS for firmware calls if it's available. > > afaui, so only retpoline means still mitigation not enough. > > Also David W has mentioned [1] that even with retpoline, IBPB is also > required (except Sky Lake). Retpoline is sufficient to protect the *kernel*, which is the biggest target. (Except on Skylake, where IBRS is the only full mitigation and people are still working trying to come up with a "good enough" mitigation that isn't IBRS.) On all CPUs, you need IBPB to protect userspace processes from each other, although since it's slow we don't actually *do* that for every context switch; only when switching to non-dumpable processes. That IBPB requirement for protecting userspace is true even on the next generation of CPUs with the "Enhanced IBRS" (IBRS_ALL) feature. It only goes away in CPUs which are even *further* in the future, when Intel manage to fix it completely in hardware. They haven't even documented the feature bit they're going to advertise to indicate that fix yet! > If IBPB & IBRS is not supported by ucode, shouldn't the below indicate > some thing on the lines of Mitigation not enough ? > > > > > - return sprintf(buf, "%s%s%s\n", spectre_v2_strings[spectre_v2_enabled], > > + return sprintf(buf, "%s%s%s%s\n", spectre_v2_strings[spectre_v2_enabled], > > boot_cpu_has(X86_FEATURE_USE_IBPB) ? ", IBPB" : "", > > + boot_cpu_has(X86_FEATURE_USE_IBRS_FW) ? ", IBRS_FW" : "", > > spectre_v2_module_string()); > On 4.16-rc1, w/ GCC 7.3.0, > > /sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI > /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: __user pointer sanitization > /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic retpoline > > Here for the user (at least for me), it is not clear whether the > mitigation is enough. In the present system (Ivy Bridge), as ucode > update is not available, IBPB is not printed along with > "spectre_v2:Mitigation", so unless i am missing something, till then > this system should be considered vulnerable, but for a user not > familiar with details of the issue, it cannot be deduced. > > Perhaps an additional status field [OKAY,PARTIAL] to Mitigation in > sysfs might be helpful. All these changes are in the air for me, this > is from a user perspective, sorry if my feedback seems idiotic. Given that we only do it for non-dumpable processes, it's *always* going to be only partial. (Although I think Thomas was looking at a command line option to make that happen on every context switch?) And on Skylake the current plan is that strictly speaking it would also be partial. I understand the concern, but I'm not sure that there's much we can do to improve it. If it says "Mitigation:" that's generally OK, and if it says anything else, it's not.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
|