linux-kernel - Re: [PATCH 0/3] syscalls: clean up stub naming convention

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] [day] [month] [year] [list]

Date:   Mon, 9 Apr 2018 12:13:50 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     Dominik Brodowski <linux@...inikbrodowski.net>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Andi Kleen <ak@...ux.intel.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Andy Lutomirski <luto@...nel.org>,
        Brian Gerst <brgerst@...il.com>,
        Denys Vlasenko <dvlasenk@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        Maninder Singh <maninder1.s@...sung.com>,
        Arnd Bergmann <arnd@...db.de>,
        linux-arch <linux-arch@...r.kernel.org>
Subject: Re: [PATCH 0/3] syscalls: clean up stub naming convention

On Sun, Apr 8, 2018 at 11:39 PM, Ingo Molnar <mingo@...nel.org> wrote:
>
> I see - so it's _not_ the same function call signature, but a wrapper with a
> sign-extended version, which is fair and useful. So on architectures where this
> matters there's type conversion and active code generated.

Exactly. Some architectures have that as part of their ABI.

On Powerpc, for example, when you pass an "int" argument, the ABI
specifies that you have to sign-extend the register in the caller to
64 bits.

And the generated code actually depends on that behavior, in that
maybe it first tests the 32 bit value, but then _uses_ the full 64
bits, knowing that the caller sign-extended it properly.

This is a problem with the system call interface, since the caller
isn't a trusted entity, and user space could pass an "int" value with
the high bits set to something that _isn't_ the sign-extended thing,
so then the compiler generates unsafe code.

On x86, this never happens, since x86 doesn't have that "hidden higher
bits matter" ABI model. So that part of the wrapper will be a complete
no-op. But some other architectures depend on it.

               Linus