From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D0474C433E3 for ; Wed, 26 Aug 2020 17:08:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9E2F020737 for ; Wed, 26 Aug 2020 17:08:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9E2F020737 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 380846B0006; Wed, 26 Aug 2020 13:08:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 330146B0007; Wed, 26 Aug 2020 13:08:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1F9538D0001; Wed, 26 Aug 2020 13:08:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0195.hostedemail.com [216.40.44.195]) by kanga.kvack.org (Postfix) with ESMTP id 0AB836B0006 for ; Wed, 26 Aug 2020 13:08:52 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id B2882364B for ; Wed, 26 Aug 2020 17:08:51 +0000 (UTC) X-FDA: 77193354462.04.sheep34_00050e827066 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin04.hostedemail.com (Postfix) with ESMTP id 81AA18006962 for ; Wed, 26 Aug 2020 17:08:51 +0000 (UTC) X-HE-Tag: sheep34_00050e827066 X-Filterd-Recvd-Size: 4991 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf37.hostedemail.com (Postfix) with ESMTP for ; Wed, 26 Aug 2020 17:08:50 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C2A95101E; Wed, 26 Aug 2020 10:08:48 -0700 (PDT) Received: from arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0B85B3F68F; Wed, 26 Aug 2020 10:08:44 -0700 (PDT) Date: Wed, 26 Aug 2020 18:08:42 +0100 From: Dave Martin To: Florian Weimer Cc: "Yu, Yu-cheng" , Dave Hansen , Andy Lutomirski , X86 ML , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , LKML , "open list:DOCUMENTATION" , Linux-MM , linux-arch , Linux API , Arnd Bergmann , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , "H.J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , "Ravi V. Shankar" , Vedvyas Shanbhogue , Weijiang Yang Subject: Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack Message-ID: <20200826170841.GX6642@arm.com> References: <20200825002540.3351-1-yu-cheng.yu@intel.com> <20200825002540.3351-26-yu-cheng.yu@intel.com> <2d253891-9393-44d0-35e0-4b9a2da23cec@intel.com> <086c73d8-9b06-f074-e315-9964eb666db9@intel.com> <73c2211f-8811-2d9f-1930-1c5035e6129c@intel.com> <20200826164604.GW6642@arm.com> <87ft892vvf.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <87ft892vvf.fsf@oldenburg2.str.redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Rspamd-Queue-Id: 81AA18006962 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Aug 26, 2020 at 06:51:48PM +0200, Florian Weimer wrote: > * Dave Martin: >=20 > > On Tue, Aug 25, 2020 at 04:34:27PM -0700, Yu, Yu-cheng wrote: > >> On 8/25/2020 4:20 PM, Dave Hansen wrote: > >> >On 8/25/20 2:04 PM, Yu, Yu-cheng wrote: > >> >>>>I think this is more arch-specific.=A0 Even if it becomes a new = syscall, > >> >>>>we still need to pass the same parameters. > >> >>> > >> >>>Right, but without the copying in and out of memory. > >> >>> > >> >>Linux-api is already on the Cc list.=A0 Do we need to add more peo= ple to > >> >>get some agreements for the syscall? > >> >What kind of agreement are you looking for? I'd suggest just codin= g it > >> >up and posting the patches. Adding syscalls really is really prett= y > >> >straightforward and isn't much code at all. > >> > > >>=20 > >> Sure, I will do that. > > > > Alternatively, would a regular prctl() work here? >=20 > Is this something appliation code has to call, or just the dynamic > loader? >=20 > prctl in glibc is a variadic function, so if there's a mismatch between > the kernel/userspace syscall convention and the userspace calling > convention (for variadic functions) for specific types, it can't be mad= e > to work in a generic way. > > The loader can use inline assembly for system calls and does not have > this issue, but applications would be implcated by it. To the extent that this is a problem, libc's prctl() wrapper has to handle it already. New prctl() calls tend to demand precisely 4 arguments and require unused arguments to be 0, but this is more down to policy rather than because anything breaks otherwise. You're right that this has implications: for i386, libc probably pulls more arguments off the stack than are really there in some situations. This isn't a new problem though. There are already generic prctls with fewer than 4 args that are used on x86. Merging the actual prctl() and arch_prctl() syscalls doesn't acutally stop libc from retaining separate wrappers if they have different argument marshaling requirements in some corner cases. There might be some underlying reason by x86 has its own call and nobody else followed the same model, but I don't know what it is. Cheers ---Dave