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  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:   Thu, 11 May 2017 16:44:07 -0700
From:   Linus Torvalds <>
To:     Thomas Garnier <>
Cc:     Greg KH <>, Ingo Molnar <>,
        Kees Cook <>,
        Daniel Micay <>,
        Martin Schwidefsky <>,
        Heiko Carstens <>,
        Dave Hansen <>,
        Arnd Bergmann <>,
        Thomas Gleixner <>,
        David Howells <>,
        René Nyffenegger <>,
        Andrew Morton <>,
        "Paul E . McKenney" <>,
        "Eric W . Biederman" <>,
        Oleg Nesterov <>,
        Pavel Tikhomirov <>,
        Ingo Molnar <>,
        "H . Peter Anvin" <>,
        Andy Lutomirski <>,
        Paolo Bonzini <>,
        Rik van Riel <>,
        Josh Poimboeuf <>,
        Borislav Petkov <>,
        Brian Gerst <>,
        "Kirill A . Shutemov" <>,
        Christian Borntraeger <>,
        Russell King <>,
        Will Deacon <>,
        Catalin Marinas <>,
        Mark Rutland <>,
        James Morse <>,
        linux-s390 <>,
        LKML <>,
        Linux API <>,
        "the arch/x86 maintainers" <>,
        Kernel Hardening <>,
        Peter Zijlstra <>,
        Al Viro <>
Subject: Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address
 limit before returning to user-mode

On Thu, May 11, 2017 at 4:17 PM, Thomas Garnier <> wrote:
> Ingo: Do you want the change as-is? Would you like it to be optional?
> What do you think?

I'm not ingo, but I don't like that patch. It's in the wrong place -
that system call return code is too timing-critical to add address
limit checks.

Now what I think you *could* do is:

 - make "set_fs()" actually set a work flag in the current thread flags

 - do the test in the slow-path (syscall_return_slowpath).

Yes, yes, that ends up being architecture-specific, but it's fairly simple.

And it only slows down the system calls that actually use "set_fs()".
Sure, it will slow those down a fair amount, but they are hopefully a
small subset of all cases.

How does that sound to people?  Thats' where we currently do that

            WARN(irqs_disabled(), "syscall %ld left IRQs disabled",

check too, which is a fairly similar issue.


Powered by blists - more mailing lists