From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f195.google.com ([209.85.192.195]:41448 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751599AbeEBXcd (ORCPT ); Wed, 2 May 2018 19:32:33 -0400 Received: by mail-pf0-f195.google.com with SMTP id v63so13089143pfk.8 for ; Wed, 02 May 2018 16:32:33 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics From: Andy Lutomirski In-Reply-To: Date: Wed, 2 May 2018 16:32:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2BE03B9A-B1E0-4707-8705-203F88B62A1C@amacapital.net> References: <20180502132751.05B9F401F3041@oldenburg.str.redhat.com> <248faadb-e484-806f-1485-c34a72a9ca0b@intel.com> <822a28c9-5405-68c2-11bf-0c282887466d@redhat.com> <57459C6F-C8BA-4E2D-99BA-64F35C11FC05@amacapital.net> <6286ba0a-7e09-b4ec-e31f-bd091f5940ff@redhat.com> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Dave Hansen Cc: Andy Lutomirski , Florian Weimer , Linux-MM , Linux API , linux-x86_64@vger.kernel.org, linux-arch , X86 ML , linuxram@us.ibm.com > On May 2, 2018, at 3:32 PM, Dave Hansen wrote: >=20 >> On 05/02/2018 03:22 PM, Andy Lutomirski wrote: >> That library wants other threads, signal handlers, and, in general, the >> whole rest of the process to be restricted, and that library doesn't want= >> race conditions. The problem here is that, to get this right, we either >> need the PKRU modifications to be syscalls or to take locks, and the lock= >> approach is going to be fairly gross. >=20 > I totally get the idea that a RDPKRU/WRPKRU is non-atomic and that it > can't be mixed with asynchronous WRPKRU's in that thread. >=20 > But, where do those come from in this scenario? I'm not getting the > secondary mechanism is that *makes* them unsafe. pkey_alloc() itself. If someone tries to allocate a key with a given defaul= t mode, unless there=E2=80=99s already a key that already had that value in a= ll threads or pkey_alloc() needs to asynchronously create such a key. There is a partial hack that glibc could do. DSOs could have a way to static= ally request a key (e.g. a PT_PKEY segment) and glibc could do all the pkey_= alloc() calls before any threads get created. Of course, a DSO like this can= =E2=80=99t be dlopened(). We still need a way for pkey_alloc() to update th= e value for signal delivery, but that=E2=80=99s straightforward.=