From: Florian Weimer <fweimer@redhat.com> To: Dave Hansen <dave.hansen@intel.com>, Ram Pai <linuxram@us.ibm.com> Cc: linux-mm <linux-mm@kvack.org>, x86@kernel.org, linux-arch <linux-arch@vger.kernel.org>, linux-x86_64@vger.kernel.org, Linux API <linux-api@vger.kernel.org> Subject: Re: pkeys: Support setting access rights for signal handlers Date: Wed, 13 Dec 2017 16:40:11 +0100 [thread overview] Message-ID: <93153ac4-70f0-9d17-37f1-97b80e468922@redhat.com> (raw) In-Reply-To: <c220f36f-c04a-50ae-3fd7-2c6245e27057@intel.com> On 12/13/2017 04:22 PM, Dave Hansen wrote: > On 12/13/2017 07:08 AM, Florian Weimer wrote: >> Okay, this model is really quite different from x86. Is there a >> good reason for the difference? > > Yes, both implementations are simple and take the "natural" behavior. > x86 changes XSAVE-controlled register values on entering a signal, so we > let them be changed (including PKRU). POWER hardware does not do this > to its PKRU-equivalent, so we do not force it to. Why? Is there a technical reason not have fully-aligned behavior? Can POWER at least implement the original PKEY_ALLOC_SETSIGNAL semantics (reset the access rights for certain keys before switching to the signal handler) in a reasonably efficient manner? At the very least, if we add a pkey_alloc flag, it should have identical behavior on both POWER and x86. So it should either reset the access rights to a fixed value (as posted) or mask out the PKRU reset on x86 (if that's even possible). In the latter case, the POWER would not even have to change if we keep saying that the default key behavior (without the flag) is undefined regarding signal handlers. > x86 didn't have to do this for *signals*. But, we kinda went on this > trajectory when we decided to clear/restore FPU state on > entering/exiting signals before XSAVE even existed. From a userspace perspective, I find this variance rather disappointing. It's particularly problematic for something like PKRU, which comes with an entire set of separately configurable keys. I implemented a per-key knob, but who says that someone else doesn't need a per-thread or per-signal knob to switch between these incompatible behaviors? What can a library assume regarding pkeys behavior if there are process-global flags that completely alter certain aspects of their behavior? > FWIW, I do *not* think we have to do this for future XSAVE states. But, > if we do that, we probably need an interface for apps to tell us which > states to save/restore and which state to set upon entering a signal > handler. That's what I was trying to get you to consider instead of > just a one-off hack to fix this for pkeys. I get that now. But for pkeys and their access rights, having this configurable at the PKRU level (as opposed the individual key level) would completely rule out any use of pkeys in the glibc dynamic linker. Thanks, Florian
WARNING: multiple messages have this Message-ID (diff)
From: Florian Weimer <fweimer@redhat.com> To: Dave Hansen <dave.hansen@intel.com>, Ram Pai <linuxram@us.ibm.com> Cc: linux-mm <linux-mm@kvack.org>, x86@kernel.org, linux-arch <linux-arch@vger.kernel.org>, linux-x86_64@vger.kernel.org, Linux API <linux-api@vger.kernel.org> Subject: Re: pkeys: Support setting access rights for signal handlers Date: Wed, 13 Dec 2017 16:40:11 +0100 [thread overview] Message-ID: <93153ac4-70f0-9d17-37f1-97b80e468922@redhat.com> (raw) In-Reply-To: <c220f36f-c04a-50ae-3fd7-2c6245e27057@intel.com> On 12/13/2017 04:22 PM, Dave Hansen wrote: > On 12/13/2017 07:08 AM, Florian Weimer wrote: >> Okay, this model is really quite different from x86. Is there a >> good reason for the difference? > > Yes, both implementations are simple and take the "natural" behavior. > x86 changes XSAVE-controlled register values on entering a signal, so we > let them be changed (including PKRU). POWER hardware does not do this > to its PKRU-equivalent, so we do not force it to. Why? Is there a technical reason not have fully-aligned behavior? Can POWER at least implement the original PKEY_ALLOC_SETSIGNAL semantics (reset the access rights for certain keys before switching to the signal handler) in a reasonably efficient manner? At the very least, if we add a pkey_alloc flag, it should have identical behavior on both POWER and x86. So it should either reset the access rights to a fixed value (as posted) or mask out the PKRU reset on x86 (if that's even possible). In the latter case, the POWER would not even have to change if we keep saying that the default key behavior (without the flag) is undefined regarding signal handlers. > x86 didn't have to do this for *signals*. But, we kinda went on this > trajectory when we decided to clear/restore FPU state on > entering/exiting signals before XSAVE even existed. From a userspace perspective, I find this variance rather disappointing. It's particularly problematic for something like PKRU, which comes with an entire set of separately configurable keys. I implemented a per-key knob, but who says that someone else doesn't need a per-thread or per-signal knob to switch between these incompatible behaviors? What can a library assume regarding pkeys behavior if there are process-global flags that completely alter certain aspects of their behavior? > FWIW, I do *not* think we have to do this for future XSAVE states. But, > if we do that, we probably need an interface for apps to tell us which > states to save/restore and which state to set upon entering a signal > handler. That's what I was trying to get you to consider instead of > just a one-off hack to fix this for pkeys. I get that now. But for pkeys and their access rights, having this configurable at the PKRU level (as opposed the individual key level) would completely rule out any use of pkeys in the glibc dynamic linker. Thanks, Florian -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2017-12-13 15:40 UTC|newest] Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-12-09 21:16 pkeys: Support setting access rights for signal handlers Florian Weimer [not found] ` <5fee976a-42d4-d469-7058-b78ad8897219-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2017-12-10 0:17 ` Dave Hansen 2017-12-10 0:17 ` Dave Hansen 2017-12-10 0:17 ` Dave Hansen 2017-12-10 6:42 ` Florian Weimer 2017-12-10 6:42 ` Florian Weimer 2017-12-11 16:13 ` Dave Hansen 2017-12-11 16:13 ` Dave Hansen 2017-12-12 23:13 ` Ram Pai 2017-12-12 23:13 ` Ram Pai 2017-12-13 2:14 ` Florian Weimer 2017-12-13 2:14 ` Florian Weimer 2017-12-13 11:35 ` Ram Pai 2017-12-13 11:35 ` Ram Pai [not found] ` <20171213113544.GG5460-LOE2q6NSToAxGrZ80giIafUQ3DHhIser@public.gmane.org> 2017-12-13 15:08 ` Florian Weimer 2017-12-13 15:08 ` Florian Weimer 2017-12-13 15:08 ` Florian Weimer 2017-12-13 15:22 ` Dave Hansen 2017-12-13 15:22 ` Dave Hansen 2017-12-13 15:40 ` Florian Weimer [this message] 2017-12-13 15:40 ` Florian Weimer 2017-12-14 0:17 ` Ram Pai 2017-12-14 0:17 ` Ram Pai 2017-12-14 11:21 ` Florian Weimer 2017-12-16 15:09 ` Ram Pai 2017-12-16 15:09 ` Ram Pai 2017-12-16 15:25 ` Florian Weimer 2017-12-16 15:25 ` Florian Weimer [not found] ` <2eba29f4-804d-b211-1293-52a567739cad-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2017-12-16 17:20 ` Ram Pai 2017-12-16 17:20 ` Ram Pai 2017-12-16 17:20 ` Ram Pai 2017-12-18 11:00 ` Florian Weimer 2017-12-18 11:00 ` 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=93153ac4-70f0-9d17-37f1-97b80e468922@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=linuxram@us.ibm.com \ --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.