Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751335AbdIOFyj convert rfc822-to-8bit (ORCPT ); Fri, 15 Sep 2017 01:54:39 -0400 Received: from terminus.zytor.com ([65.50.211.136]:50429 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750787AbdIOFyi (ORCPT ); Fri, 15 Sep 2017 01:54:38 -0400 Date: Thu, 14 Sep 2017 22:47:49 -0700 User-Agent: K-9 Mail for Android In-Reply-To: <20170915053155.f336vlejdql23zxu@gmail.com> References: <20170912225756.GA19364@altlinux.org> <20170914213316.GB17533@altlinux.org> <20170915053155.f336vlejdql23zxu@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Subject: Re: [PATCH] x86/asm/64: do not clear high 32 bits of syscall number when CONFIG_X86_X32=y To: Ingo Molnar , Andy Lutomirski CC: Thomas Gleixner , Ingo Molnar , X86 ML , Oleg Nesterov , Eugene Syromyatnikov , "linux-kernel@vger.kernel.org" , Linus Torvalds , Peter Zijlstra , Andrew Morton From: hpa@zytor.com Message-ID: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2384 Lines: 71 On September 14, 2017 10:31:55 PM PDT, Ingo Molnar wrote: > >* Andy Lutomirski wrote: > >> >> > 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? > >So I believe this was introduced with x32 as a 'fresh, modern syscall >ABI' >behavioral aspect, because we wanted to protect the overly complex >syscall entry >code from 'weird' input values. IIRC there was an old bug where we'd >overflow the >syscall table in certain circumstances ... > >But our new, redesigned entry code is a lot less complex, a lot more >readable and >a lot more maintainable (not to mention a lot more robust), so if >invalid RAX >values with high bits set get reliably turned into -ENOSYS or such then >I'd not >mind the patch per se either, as a general consistency improvement. > >Of course if something in x32 user-land breaks then this turns into an >ABI and we >have to reintroduce this aspect, as a quirk :-/ > >It should also improve x32 syscall performance a tiny bit, right? So >might be >worth a try on various grounds. > >( Another future advantage would be that _maybe_ we could use the high >RAX >component as an extra (64-bit only) special argument of sorts. Not that >I can > think of any such use right now. ) > >Thanks, > > Ingo If the consensus is that we should change the x86-64 ABI then we should change the x32 ABI to match, though. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.