[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y88bhrDoPw5tOyKu@biznet-home.integral.gnuweeb.org>
Date: Tue, 24 Jan 2023 06:43:02 +0700
From: Ammar Faizi <ammarfaizi2@...weeb.org>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Dave Hansen <dave.hansen@...el.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Xin Li <xin3.li@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Peter Zijlstra <peterz@...radead.org>,
x86 Mailing List <x86@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: the x86 sysret_rip test fails on the Intel FRED architecture
On Mon, Jan 23, 2023 at 11:43:35AM -0800, H. Peter Anvin wrote:
> Good spotting. %rax needs to be marked clobbered, too.
Yeah, that 'syscall' variable should be using a "+a" constraint.
But anyway, I found something wrong with this. I was playing with your
code and I found it failed to assert that %r11 == rflags_sentinel on a
non-FRED system. It happens because "popf" doesn't set the %rflags
to the expected value.
I tried to simplify it like this:
pushq $0x200893
popf # This popf sets %rflags to 0x200a93, not to 0x200893.
pushf
popq %r11
# Now %r11 == 0x200a93,
# but the expected value is %r11 == 0x200893.
Looking into their bits:
(gdb) p/t 0x200893
$1 = 1000000000100010010011
(gdb) p/t 0x200a93
$2 = 1000000000101010010011
Align them to spot differences:
0x200893 = 0b1000000000100010010011
0x200a93 = 0b1000000000101010010011
^
Or just xor them to find the differences:
(gdb) p/x 0x200893 ^ 0x200a93
$3 = 0x200
** Checks my Intel SDM cheat sheets. **
Then, I was like "Oh, that's (1 << 9) a.k.a. IF. Of course we can't
change rflags[IF] from userspace!!!".
In short, we can't use 0x200893 as the rflags_sentinel value because it
clears the interrupt flag.
--
Ammar Faizi
Powered by blists - more mailing lists