linux-kernel - Re: [RFC PATCH v5 1/2] selftests/x86: sysret

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: <A7DAB159-7C02-412D-9CFB-5C3C3760DECB@zytor.com>
Date:   Wed, 25 Jan 2023 02:17:41 -0800
From:   "H. Peter Anvin" <hpa@...or.com>
To:     Ammar Faizi <ammarfaizi2@...weeb.org>
CC:     Xin Li <xin3.li@...el.com>, Dave Hansen <dave.hansen@...el.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andrew Cooper <Andrew.Cooper3@...rix.com>,
        Brian Gerst <brgerst@...il.com>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Shuah Khan <shuah@...nel.org>, Ingo Molnar <mingo@...nel.org>,
        Andy Lutomirski <luto@...nel.org>,
        x86 Mailing List <x86@...nel.org>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Linux Kselftest Mailing List 
        <linux-kselftest@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v5 1/2] selftests/x86: sysret_rip: Handle syscall in a FRED system

On January 25, 2023 1:57:15 AM PST, Ammar Faizi <ammarfaizi2@...weeb.org> wrote:
>On Wed, Jan 25, 2023 at 12:39:26AM -0800, H. Peter Anvin wrote:
>> >   	/* Set IP and CX to match so that SYSRET can happen. */
>> >   	ctx->uc_mcontext.gregs[REG_RIP] = rip;
>> >   	ctx->uc_mcontext.gregs[REG_RCX] = rip;
>> 
>> It would be interesting to have the syscall handler try both with and
>> without this (so it would end up doing both IRET and SYSCALL on legacy.)
>> Perhaps SIGUSR1 versus SIGUSR2...
>
>Just to clarify this more so I am sure I understand it correctly.
>
>Did you mean to have the same signal handler without modifiying
>'REG_RCX' but still change 'REG_RIP'?
>
>IOW, we want to only *remove*:
>
>   ctx->uc_mcontext.gregs[REG_RCX] = rip;
>
>and *keep*:
>
>   ctx->uc_mcontext.gregs[REG_RIP] = rip;
>
>for the SIGUSR2 handler. Thus, inside the entry64 we will jump to the
>iret path because %rcx != %r11 upon rt_sigreturn()?
>

I guess it would depend on what they "normally" are. My #1 impulse would be to leave them both unchanged.