linux-kernel - Re: Q: does force_iret() make any sense today?

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]

Date:   Wed, 18 Dec 2019 10:45:07 -0500
From:   Brian Gerst <brgerst@...il.com>
To:     Oleg Nesterov <oleg@...hat.com>
Cc:     Andy Lutomirski <luto@...nel.org>, Borislav Petkov <bp@...en8.de>,
        Ingo Molnar <mingo@...hat.com>, Peter Anvin <hpa@...or.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "the arch/x86 maintainers" <x86@...nel.org>
Subject: Re: Q: does force_iret() make any sense today?

On Wed, Dec 18, 2019 at 10:31 AM Oleg Nesterov <oleg@...hat.com> wrote:
>
> I do not pretend I understand the arch/x86/entry/ code, but it seems that
> asm does all the necessary checks and the "extra" TIF_NOTIFY_RESUME simply
> has no effect except tracehook_notify_resume() will be called for no reason?

It's a relic of a time before the more robust checks for
SYSRET/SYSEXIT were added.  The idea was to divert the syscall return
flow off the fast path.  Even if no exit work was done, the slow path
always returned with IRET.  But with all the entry rework that has
been done it is no longer needed and can be removed.

--
Brian Gerst