From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx3-rdu2.redhat.com ([66.187.233.73]:42758 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750954AbeECOmf (ORCPT ); Thu, 3 May 2018 10:42:35 -0400 Subject: Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics 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> <2BE03B9A-B1E0-4707-8705-203F88B62A1C@amacapital.net> From: Florian Weimer Message-ID: <63f948aa-17fe-9879-fbbc-7f2351e31028@redhat.com> Date: Thu, 3 May 2018 16:42:32 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: Andy Lutomirski , Dave Hansen Cc: Andy Lutomirski , Linux-MM , Linux API , linux-x86_64@vger.kernel.org, linux-arch , X86 ML , linuxram@us.ibm.com On 05/03/2018 03:14 AM, Andy Lutomirski wrote: > No, I’m saying that all threads should get the*requested* access. If I’m protecting the GOT, I want all threads to get RO access. If I’m writing a crypto library, I probably want all threads to have no access. If I’m writing a database, I probably want all threads to get RO by default. If I’m writing some doodad to sandbox some carefully constructed code, I might want all threads to have full access by default. Just a clarification: This key allocation issue is *not* a blocker for anything related to a safer GOT, or any other use of memory protection keys by the C implementation itself. I agree that there could be application issues if threads are created early, but solving this issue in a general way appears to be quite costly. Thanks, Florian From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-f200.google.com (mail-qt0-f200.google.com [209.85.216.200]) by kanga.kvack.org (Postfix) with ESMTP id 541C26B000C for ; Thu, 3 May 2018 10:42:36 -0400 (EDT) Received: by mail-qt0-f200.google.com with SMTP id t24-v6so13363628qtn.7 for ; Thu, 03 May 2018 07:42:36 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com. [66.187.233.73]) by mx.google.com with ESMTPS id o15-v6si10600095qta.339.2018.05.03.07.42.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 May 2018 07:42:35 -0700 (PDT) Subject: Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics 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> <2BE03B9A-B1E0-4707-8705-203F88B62A1C@amacapital.net> From: Florian Weimer Message-ID: <63f948aa-17fe-9879-fbbc-7f2351e31028@redhat.com> Date: Thu, 3 May 2018 16:42:32 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: owner-linux-mm@kvack.org List-ID: To: Andy Lutomirski , Dave Hansen Cc: Andy Lutomirski , Linux-MM , Linux API , linux-x86_64@vger.kernel.org, linux-arch , X86 ML , linuxram@us.ibm.com On 05/03/2018 03:14 AM, Andy Lutomirski wrote: > No, Ia??m saying that all threads should get the*requested* access. If Ia??m protecting the GOT, I want all threads to get RO access. If Ia??m writing a crypto library, I probably want all threads to have no access. If Ia??m writing a database, I probably want all threads to get RO by default. If Ia??m writing some doodad to sandbox some carefully constructed code, I might want all threads to have full access by default. Just a clarification: This key allocation issue is *not* a blocker for anything related to a safer GOT, or any other use of memory protection keys by the C implementation itself. I agree that there could be application issues if threads are created early, but solving this issue in a general way appears to be quite costly. Thanks, Florian