On 23/03/2026 7:11 pm, H. Peter Anvin wrote:
> On 2026-03-22 23:06, Lai, Yi wrote:
>> Thanks for the context and links, Xin.
>>
>> My patch is a simple, focused fix to unblock current regression in
>> 'sysret_rip'. The goal is just to ensure it doesn't falsely fail on FRED
>> systems by skipping the IDT assertion (R11==RFLAGS).
>>
>> Checking Ammar's patch series, it indeed looks like a more comprehensive
>> solution that not only handles the difference but also adds specific
>> test coverage for consistency. Is there a specific reason it didn't
>> land in the mainline kernel? If you think that is the preferred
>> direction, I would be happy to contribute to that effort
>> collaboratively.
>>
> So for what it's worth, I have used this sequence to probe for FRED, but it is
> basically probing for the effect you are truing to test for here:
>
> #include <inttypes.h>
> #include <stdbool.h>
> #include <linux/unistd.h>
>
> bool fred_is_on(void)
> {
> const uint64_t sentinel1 = 0xfeedfacedeadbeef;
> const uint64_t sentinel2 = 0xbeeffeeb1ef00d1e;
>
> register uint64_t rax asm("rax") = __NR_getppid;
> register uint64_t rcx asm("rcx") = sentinel1;
> register uint64_t r11 asm("r11") = sentinel2;
>
> asm volatile("syscall" : "+r" (rax), "+r" (rcx), "+r" (r11));
>
> return !((rcx ^ sentinel1) | (r11 ^ sentinel2));
> }
>
> -hpa
This doesn't really test whether FRED is active. It tests whether the
OS is not providing strict backwards compatibility, and I think will
malfunction when there's a hypervisor above Linux providing strict
backwards compatibility.
~Andrew
