From: Florian Weimer <fweimer@redhat.com> To: Andy Lutomirski <luto@kernel.org> Cc: linux-arch <linux-arch@vger.kernel.org>, Linux-MM <linux-mm@kvack.org>, Linux API <linux-api@vger.kernel.org>, X86 ML <x86@kernel.org>, linuxram@us.ibm.com, Dave Hansen <dave.hansen@intel.com>, linux-x86_64@vger.kernel.org, linuxppc-dev <linuxppc-dev@lists.ozlabs.org> Subject: Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics Date: Mon, 14 May 2018 14:01:23 +0200 [thread overview] Message-ID: <008010c1-20a1-c307-25ac-8a69d672d031@redhat.com> (raw) In-Reply-To: <CALCETrUGjN8mhOaLqGcau-pPKm9TQW8k05hZrh52prRNdC5yQQ@mail.gmail.com> On 05/09/2018 04:41 PM, Andy Lutomirski wrote: > Hmm. I can get on board with the idea that fork() / clone() / > pthread_create() are all just special cases of the idea that the thread > that*calls* them should have the right pkey values, and the latter is > already busted given our inability to asynchronously propagate the new mode > in pkey_alloc(). So let's so PKEY_ALLOC_SETSIGNAL as a starting point. Ram, any suggestions for implementing this on POWER? > One thing we could do, though: the current initual state on process > creation is all access blocked on all keys. We could change it so that > half the keys are fully blocked and half are read-only. Then we could add > a PKEY_ALLOC_STRICT or similar that allocates a key with the correct > initial state*and* does the setsignal thing. If there are no keys left > with the correct initial state, then it fails. The initial PKRU value can currently be configured by the system administrator. I fear this approach has too many moving parts to be viable. Thanks, Florian
WARNING: multiple messages have this Message-ID (diff)
From: Florian Weimer <fweimer@redhat.com> To: Andy Lutomirski <luto@kernel.org> Cc: linuxram@us.ibm.com, Dave Hansen <dave.hansen@intel.com>, Linux-MM <linux-mm@kvack.org>, Linux API <linux-api@vger.kernel.org>, linux-x86_64@vger.kernel.org, linux-arch <linux-arch@vger.kernel.org>, X86 ML <x86@kernel.org>, linuxppc-dev <linuxppc-dev@lists.ozlabs.org> Subject: Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics Date: Mon, 14 May 2018 14:01:23 +0200 [thread overview] Message-ID: <008010c1-20a1-c307-25ac-8a69d672d031@redhat.com> (raw) Message-ID: <20180514120123.xWsU9YUIAi2_47c2DDkC1bWR_CmegPi0kveGm_FI4hk@z> (raw) In-Reply-To: <CALCETrUGjN8mhOaLqGcau-pPKm9TQW8k05hZrh52prRNdC5yQQ@mail.gmail.com> On 05/09/2018 04:41 PM, Andy Lutomirski wrote: > Hmm. I can get on board with the idea that fork() / clone() / > pthread_create() are all just special cases of the idea that the thread > that*calls* them should have the right pkey values, and the latter is > already busted given our inability to asynchronously propagate the new mode > in pkey_alloc(). So let's so PKEY_ALLOC_SETSIGNAL as a starting point. Ram, any suggestions for implementing this on POWER? > One thing we could do, though: the current initual state on process > creation is all access blocked on all keys. We could change it so that > half the keys are fully blocked and half are read-only. Then we could add > a PKEY_ALLOC_STRICT or similar that allocates a key with the correct > initial state*and* does the setsignal thing. If there are no keys left > with the correct initial state, then it fails. The initial PKRU value can currently be configured by the system administrator. I fear this approach has too many moving parts to be viable. Thanks, Florian
next prev parent reply other threads:[~2018-05-14 12:01 UTC|newest] Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-05-02 13:26 [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics Florian Weimer 2018-05-02 14:30 ` Dave Hansen 2018-05-02 15:12 ` Florian Weimer 2018-05-02 15:12 ` Florian Weimer 2018-05-02 15:28 ` Dave Hansen 2018-05-02 15:28 ` Dave Hansen 2018-05-02 21:08 ` Florian Weimer 2018-05-02 22:03 ` Dave Hansen 2018-05-02 22:03 ` Dave Hansen 2018-05-07 9:47 ` Florian Weimer 2018-05-07 9:47 ` Florian Weimer 2018-05-02 17:09 ` Andy Lutomirski 2018-05-02 17:17 ` Florian Weimer 2018-05-02 17:17 ` Florian Weimer 2018-05-02 20:41 ` Andy Lutomirski 2018-05-02 21:06 ` Florian Weimer 2018-05-02 21:06 ` Florian Weimer 2018-05-02 21:23 ` Andy Lutomirski 2018-05-02 22:08 ` Dave Hansen 2018-05-02 22:22 ` Andy Lutomirski 2018-05-02 22:32 ` Dave Hansen 2018-05-02 23:32 ` Andy Lutomirski 2018-05-02 23:58 ` Dave Hansen 2018-05-02 23:58 ` Dave Hansen 2018-05-03 1:14 ` Andy Lutomirski 2018-05-03 14:42 ` Dave Hansen 2018-05-03 14:42 ` Dave Hansen 2018-05-03 14:42 ` Florian Weimer 2018-05-03 14:42 ` Florian Weimer 2018-05-03 2:10 ` Ram Pai 2018-05-03 4:05 ` Andy Lutomirski 2018-05-07 9:48 ` Florian Weimer 2018-05-08 2:49 ` Andy Lutomirski 2018-05-08 2:49 ` Andy Lutomirski 2018-05-08 12:40 ` Florian Weimer 2018-05-08 12:40 ` Florian Weimer 2018-05-09 14:41 ` Andy Lutomirski 2018-05-09 14:41 ` Andy Lutomirski 2018-05-14 12:01 ` Florian Weimer [this message] 2018-05-14 12:01 ` Florian Weimer 2018-05-14 15:32 ` Andy Lutomirski 2018-05-14 15:32 ` Andy Lutomirski 2018-05-14 15:32 ` Andy Lutomirski 2018-05-14 15:34 ` Florian Weimer 2018-05-14 15:34 ` Florian Weimer 2018-05-14 15:34 ` Florian Weimer 2018-05-16 17:01 ` Dave Hansen 2018-05-16 17:01 ` Dave Hansen 2018-05-16 17:01 ` Dave Hansen 2018-05-16 20:52 ` Ram Pai 2018-05-16 20:52 ` Ram Pai 2018-05-16 20:54 ` Andy Lutomirski 2018-05-16 20:54 ` Andy Lutomirski 2018-05-16 20:35 ` Ram Pai 2018-05-16 20:35 ` Ram Pai 2018-05-16 20:37 ` Andy Lutomirski 2018-05-16 20:37 ` Andy Lutomirski 2018-05-16 21:07 ` Ram Pai 2018-05-16 21:07 ` Ram Pai 2018-05-17 10:09 ` Florian Weimer 2018-05-17 10:09 ` Florian Weimer 2018-05-17 10:11 ` Florian Weimer 2018-05-17 10:11 ` Florian Weimer 2018-05-03 14:37 ` Florian Weimer 2018-05-02 21:12 ` Ram Pai 2018-05-02 21:12 ` Ram Pai 2018-05-02 21:18 ` Andy Lutomirski 2018-05-02 23:38 ` Ram Pai 2018-05-02 23:38 ` Ram Pai 2018-05-07 9:47 ` Florian Weimer 2018-05-07 9:47 ` Florian Weimer 2018-05-07 9:43 ` Florian Weimer
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=008010c1-20a1-c307-25ac-8a69d672d031@redhat.com \ --to=fweimer@redhat.com \ --cc=dave.hansen@intel.com \ --cc=linux-api@vger.kernel.org \ --cc=linux-arch@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-x86_64@vger.kernel.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=linuxram@us.ibm.com \ --cc=luto@kernel.org \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.