All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@amacapital.net>
To: Florian Weimer <fweimer@redhat.com>
Cc: Dave Hansen <dave.hansen@intel.com>,
	linux-mm@kvack.org, linux-api@vger.kernel.org,
	linux-x86_64@vger.kernel.org, linux-arch@vger.kernel.org,
	x86@kernel.org, linuxram@us.ibm.com
Subject: Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
Date: Wed, 2 May 2018 10:09:40 -0700	[thread overview]
Message-ID: <57459C6F-C8BA-4E2D-99BA-64F35C11FC05@amacapital.net> (raw)
In-Reply-To: <822a28c9-5405-68c2-11bf-0c282887466d@redhat.com>



> On May 2, 2018, at 8:12 AM, Florian Weimer <fweimer@redhat.com> wrote:
> 
>> On 05/02/2018 04:30 PM, Dave Hansen wrote:
>>> On 05/02/2018 06:26 AM, Florian Weimer wrote:
>>> pkeys support for IBM POWER intends to inherited the access rights of
>>> the current thread in signal handlers.  The advantage is that this
>>> preserves access to memory regions associated with non-default keys,
>>> enabling additional usage scenarios for memory protection keys which
>>> currently do not work on x86 due to the unconditional reset to the
>>> (configurable) default key in signal handlers.
>> What's the usage scenario that does not work?
> 
> Here's what I want to do:
> 
> Nick Clifton wrote a binutils patch which puts the .got.plt section on separate pages.  We allocate a protection key for it, assign it to all such sections in the process image, and change the access rights of the main thread to disallow writes via that key during process startup.  In _dl_fixup, we enable write access to the GOT, update the GOT entry, and then disable it again.
> 
> This way, we have a pretty safe form of lazy binding, without having to resort to BIND_NOW.
> 
> With the current kernel behavior on x86, we cannot do that because signal handlers revert to the default (deny) access rights, so the GOT turns inaccessible.

Dave is right: the current behavior was my request, and I still think it’s correct.  The whole point is that, even if something nasty happens like a SIGALRM handler hitting in the middle of _dl_fixup, the SIGALRM handler is preventing from accidentally writing to the protected memory.  When SIGALRM returns, PKRU should get restored

Another way of looking at this is that the kernel would like to approximate what the ISA behavior *should* have been: the whole sequence “modify PKRU; access memory; restore PKRU” should be as atomic as possible.

Florian, what is the actual problematic sequence of events?

—Andy

  parent reply	other threads:[~2018-05-02 17:09 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 [this message]
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
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=57459C6F-C8BA-4E2D-99BA-64F35C11FC05@amacapital.net \
    --to=luto@amacapital.net \
    --cc=dave.hansen@intel.com \
    --cc=fweimer@redhat.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: link
Be 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.