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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 18 Dec 2019 17:06:41 +0100
From:   Oleg Nesterov <oleg@...hat.com>
To:     Brian Gerst <brgerst@...il.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 12/18, Brian Gerst wrote:
>
> 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.

Thanks, this was my understanding. Will you make a patch?

Oleg.