On Tue, 2018-01-23 at 10:12 -0600, Tom Lendacky wrote: > > >> +.macro UNRESTRICT_IB_SPEC > >> + ALTERNATIVE "jmp .Lskip_\@", "", X86_FEATURE_IBRS > >> + PUSH_MSR_REGS > >> + WRMSR_ASM $MSR_IA32_SPEC_CTRL, $0, $0 > > > I think you should be writing 2, not 0, since I'm reasonably > confident that we want STIBP on. Can you explain why you're writing > 0? > > Do we want to talk about STIBP in general? Should it be (yet another) > boot option to enable or disable? If there is STIBP support without > IBRS support, it could be a set and forget at boot time. We haven't got patches which enable STIBP in general. The kernel itself is safe either way with retpoline, or because IBRS implies STIBP too (that is, there's no difference between writing 1 and 3). So STIBP is purely about protecting userspace processes from one another, and VM guests from one another, when they run on HT siblings. There's an argument that there are so many other information leaks between HT siblings that we might not care. Especially as it's hard to *tell* when you're scheduling, whether you trust all the processes (or guests) on your HT siblings right now... let alone later when scheduling another process if you need to *now* set STIBP on a sibling which is no longer save from this process now running. I'm not sure we want to set STIBP *unconditionally* either because of the performance implications. For IBRS we had an answer and it was just ugly. For STIBP we don't actually have an answer for "how do we use this?". Do we?
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
