Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp667851ybh; Tue, 21 Jul 2020 05:09:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJywwvI/tdJwqkH7nPkdgVz1PMlRZMDrWbOcWii1Hh4dvkK62xEL7wqTburNCV/wXXbO1aoH X-Received: by 2002:a17:906:355b:: with SMTP id s27mr26387892eja.368.1595333373617; Tue, 21 Jul 2020 05:09:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595333373; cv=none; d=google.com; s=arc-20160816; b=iNfQZb/e+iHIvkrJqGolfH6pjRIeabgh/a3es2Gm/YhsT6hbqfs46poEYKrUyoI2dt H4jg2bbwenWTfyzQuorAeXDB18cGFjECpeWuLKN2mg+E/xuMptacDpF9SBxOxd3bzKGr B5Fuw+Ade89is+bvaDi2G0t1HeJQtz9TM6ALC4yfn8/NkJ4s3SQA9AToGYXX0VMoU/Oh XagKOTreItfC44UcSt5LEJSp+S0Y/7qpRu2UG/WAbG5DF3MDy7ym12VKI7Gr+uTDqb5i UHNc5Bb8nqKzV5qU5Xoo1xJWyYsPICgbYCwCmTXjY+eW6oi02PI+MUGcI2PD+jQ/2v18 qQaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=0qVCdXD9W7z+IXnMJBASWA0pGusxcWcdRHYKxKNuvyQ=; b=DL2Rs/1KHE2bYVXgmQopAdH34IHD2DjPMBgTgBR1iiaHARNaM0S0ABPzt6Ox4EuyQh 7+tNlNhVum0qPnKe/iDN++dfTBVpEStWzndyBhgzsaxhjlEUZ6wFA1G+/cJqtcZ86jfC bFYINwQWEwCFykTmLhPX2BotMtRtNxStByqTVoDExPd1VgVVDDgq5o9GuxIlpsmAm6RG j04PRS0HgEOPnzRwa2SfwewiPuwwdLmCzH4u67qwY0mPhF5lJQIdN2krZtTZMA5IINzG 6m6pKDI4EpPXnTxdhZViKFf+rqXkn5S7ZnGd/YvrWWCx4dLwpp+zAyy+NRqpL+rB6jEc vTTA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e5si12121695ejb.453.2020.07.21.05.09.10; Tue, 21 Jul 2020 05:09:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729786AbgGUMGv (ORCPT + 99 others); Tue, 21 Jul 2020 08:06:51 -0400 Received: from foss.arm.com ([217.140.110.172]:38418 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726919AbgGUMGv (ORCPT ); Tue, 21 Jul 2020 08:06:51 -0400 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 68636D6E; Tue, 21 Jul 2020 05:06:50 -0700 (PDT) Received: from C02TD0UTHF1T.local (unknown [10.57.3.181]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9AF633F66E; Tue, 21 Jul 2020 05:06:47 -0700 (PDT) Date: Tue, 21 Jul 2020 13:06:41 +0100 From: Mark Rutland To: Andy Lutomirski Cc: Gabriel Krisman Bertazi , Thomas Gleixner , LKML , kernel@collabora.com, Matthew Wilcox , Paul Gofman , Kees Cook , "open list:KERNEL SELFTEST FRAMEWORK" , Shuah Khan , will@kernel.org, catalin.marinas@arm.com Subject: Re: [PATCH v4 1/2] kernel: Implement selective syscall userspace redirection Message-ID: <20200721120516.GA84703@C02TD0UTHF1T.local> References: <20200716193141.4068476-1-krisman@collabora.com> <20200716193141.4068476-2-krisman@collabora.com> <87wo32j394.fsf@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 16, 2020 at 09:48:50PM -0700, Andy Lutomirski wrote: > On Thu, Jul 16, 2020 at 7:15 PM Gabriel Krisman Bertazi > wrote: > > > > Andy Lutomirski writes: > > > > > On Thu, Jul 16, 2020 at 12:31 PM Gabriel Krisman Bertazi > > > wrote: > > >> > > > > > > This is quite nice. I have a few comments, though: > > > > > > You mentioned rt_sigreturn(). Should this automatically exempt the > > > kernel-provided signal restorer on architectures (e.g. x86_32) that > > > provide one? > > > > That seems reasonable. Not sure how easy it is to do it, though. > > For better or for worse, it's currently straightforward because the code is: > > __kernel_sigreturn: > .LSTART_sigreturn: > popl %eax /* XXX does this mean it needs unwind info? */ > movl $__NR_sigreturn, %eax > SYSCALL_ENTER_KERNEL > > and SYSCALL_ENTER_KERNEL is hardwired as int $0x80. (The latter is > probably my fault, for better or for worse.) So this would change to: > > __vdso32_sigreturn_syscall: > SYSCALL_ENTER_KERNEL > > and vdso2c would wire up __vdso32_sigreturn_syscall. Then there would > be something like: > > bool arch_syscall_is_vdso_sigreturn(struct pt_regs *regs); > > and that would be that. Does anyone have an opinion as to whether > this is a good idea? Modern glibc shouldn't be using this mechanism, > I think, but I won't swear to it. On arm64 sigreturn is always through the vdso, so IIUC we'd certainly need something like this. Otherwise it'd be the user's responsibility to register the vdso sigtramp range when making the prctl, and flip the selector in each signal handler, which sounds both painful and fragile. Mark.