[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86: correct EFLAGS.IF in SYSENTER frame
On 16/03/18 15:04, Jan Beulich wrote: >>>> On 16.03.18 at 15:29, <andrew.cooper3@xxxxxxxxxx> wrote: >> On 16/03/18 14:13, Jan Beulich wrote: >>> Commit 9d1d31ad94 ("x86: slightly reduce Meltdown band-aid overhead") >>> moved the STI past the PUSHF. While this isn't an active problem (as we >>> force EFLAGS.IF to 1 before exiting to guest context), let's not risk >>> internal confusion by finding a PV guest frame with interrupts >>> apparently off. >>> >>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> >>> >>> --- a/xen/arch/x86/x86_64/entry.S >>> +++ b/xen/arch/x86/x86_64/entry.S >>> @@ -281,6 +281,8 @@ GLOBAL(sysenter_eflags_saved) >>> /* WARNING! `ret`, `call *`, `jmp *` not safe before this point. */ >>> >>> GET_STACK_END(bx) >>> + /* PUSHF above has saved EFLAGS.IF clear (the caller had it set). >>> */ >>> + orl $X86_EFLAGS_IF, UREGS_eflags(%rsp) >> For the sake of a single or (which would be beside a line of adjacent >> stack accesses anyway), I think it would be better to have this >> immediately after sysenter_eflags_saved. It doesn't have an impact on >> speculation safety, and can't plausibly be impacted by SMAP. > Well, I had considered that, but that'll be yet one more separate > place to NOP out later on. > >> It is perhaps not very important, but is it worth encoding this as: >> >> orb $(X86_EFLAGS_IF >> 8), UREGS_eflags+1(%rsp) >> >> We have a similar pattern when testing the interrupt flag. > Aren't back to back different size writes to the same location > recommended against? Then again, the push is a qword write > already anyway, followed by (currently) a dword write. I can > certainly do that. But let's first agree on the placement. Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> I'm not sufficiently concerned about placement to delay the patch. > >> Somewhat independently of this patch, I think we should assert that >> flags are in the expected state in the return-to-guest path, so we >> notice accidental breakage like this more easily. > Not sure - nothing was broken here afaict, we just want to play > safe. And as said the exit paths already force EFLAGS.IF to 1. It is only because of the pessimistic approach in a previous XSA fix that this isn't an XSA itself. Despite the safety net, I consider it a bug if such an assert could trip (and there are several paths we do know of which want fixing). ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |