linux-kernel - Re: the x86 sysret_rip test fails on the Intel FRED architecture

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <18B5DB6D-AEBD-4A67-A7B3-CE64940819B7@zytor.com>
Date:   Fri, 20 Jan 2023 20:59:58 -0800
From:   "H. Peter Anvin" <hpa@...or.com>
To:     Dave Hansen <dave.hansen@...el.com>,
        "Li, Xin3" <xin3.li@...el.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>
CC:     "x86@...nel.org" <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: the x86 sysret_rip test fails on the Intel FRED architecture

On January 20, 2023 9:45:26 AM PST, Dave Hansen <dave.hansen@...el.com> wrote:
>On 1/19/23 23:49, Li, Xin3 wrote:
>> The x86 sysret_rip test has the following assertion:
>> 
>>         /* R11 and EFLAGS should already match. */
>>         assert(ctx->uc_mcontext.gregs[REG_EFL] ==
>>                ctx->uc_mcontext.gregs[REG_R11]);
>> 
>> This is being tested to avoid kernel state leak due to sysret vs iret,
>> but that on FRED r11 is *always* preserved, and the test just fails.
>
>Let's figure out the reason that FRED acts differently, first.  Right
>now, the SDM says:
>
>	SYSCALL also saves RFLAGS into R11
>
>so that behavior of SYSCALL _looks_ architectural to me.  Was this
>change in SYSCALL behavior with FRED intentional?
>
>If not intentional, it might be something that can still be fixed.  If
>it is intentional and is going to be with us for a while we have a few
>options.  If userspace is _really_ depending on this behavior, we could
>just clobber r11 ourselves in the FRED entry path.  If not, we can
>remove the assertion in the selftest.

We can't clobber it in the FRED entry path, since it is common for all events, but we could do it in the syscall dispatch.

However, it doesn't seem to make sense to do so to me. The current behavior is much more of an artifact than desired behavior.