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
| ||
|
Message-ID: <CALCETrUsMq1W5QMOux4FEjoc2nYuzTePqBKxdy--PvQ+SxzwYQ@mail.gmail.com> Date: Thu, 14 Sep 2017 14:38:24 -0700 From: Andy Lutomirski <luto@...nel.org> To: Andy Lutomirski <luto@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, "H. Peter Anvin" <hpa@...or.com>, X86 ML <x86@...nel.org>, Oleg Nesterov <oleg@...hat.com>, Eugene Syromyatnikov <evgsyr@...il.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: Re: [PATCH] x86/asm/64: do not clear high 32 bits of syscall number when CONFIG_X86_X32=y On Thu, Sep 14, 2017 at 2:33 PM, Dmitry V. Levin <ldv@...linux.org> wrote: > On Thu, Sep 14, 2017 at 02:05:04PM -0700, Andy Lutomirski wrote: >> On Tue, Sep 12, 2017 at 3:57 PM, Dmitry V. Levin wrote: >> > Before this change, CONFIG_X86_X32=y fastpath behaviour was different >> > from slowpath: >> > >> > $ gcc -xc -Wall -O2 - <<'EOF' >> > #include <unistd.h> >> > #include <asm/unistd.h> >> > int main(void) { >> > unsigned long nr = ~0xffffffffUL | __NR_exit; >> > return !!syscall(nr, 42, 1, 2, 3, 4, 5); >> > } >> > EOF >> > $ ./a.out; echo \$?=$? >> > $?=42 >> > $ strace -enone ./a.out >> > syscall_18446744069414584380(0x2a, 0x1, 0x2, 0x3, 0x4, 0x5) = -1 (errno 38) >> > +++ exited with 1 +++ >> > >> > This change syncs CONFIG_X86_X32=y fastpath behaviour with the case >> > when CONFIG_X86_X32 is not enabled. >> >> Do you see real brokenness here, or is it just weird? > > It's definitely broken. A syscall should be either valid or invalid > regardless of implementation peculiarities like fastpath vs slowpath. > >> > Fixes: fca460f95e92 ("x32: Handle the x32 system call flag") >> > Cc: stable@...r.kernel.org >> > Signed-off-by: Dmitry V. Levin <ldv@...linux.org> >> > --- >> > arch/x86/entry/entry_64.S | 8 +++----- >> > 1 file changed, 3 insertions(+), 5 deletions(-) >> > >> > diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S >> > index 4916725..3bab6af 100644 >> > --- a/arch/x86/entry/entry_64.S >> > +++ b/arch/x86/entry/entry_64.S >> > @@ -185,12 +185,10 @@ entry_SYSCALL_64_fastpath: >> > */ >> > TRACE_IRQS_ON >> > ENABLE_INTERRUPTS(CLBR_NONE) >> > -#if __SYSCALL_MASK == ~0 >> > - cmpq $__NR_syscall_max, %rax >> > -#else >> > - andl $__SYSCALL_MASK, %eax >> > - cmpl $__NR_syscall_max, %eax >> > +#if __SYSCALL_MASK != ~0 >> > + andq $__SYSCALL_MASK, %rax >> > #endif >> > + cmpq $__NR_syscall_max, %rax >> >> I don't know much about x32 userspace, but there's an argument that >> the high bits *should* be masked off if the x32 bit is set. > > Why? Because it always worked that way. That being said, I'd be okay with applying your patch and seeing whether anything breaks. Ingo? > > > -- > ldv
Powered by blists - more mailing lists