[PATCH] mm, x86: pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics

[PATCH] mm, x86: pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics

[Florian Weimer]

[-- Attachment #1: Type: text/plain, Size: 590 bytes --]

This patch is based on the previous discussion (pkeys: Support setting 
access rights for signal handlers):

   https://marc.info/?t=151285426000001

It aligns the signal semantics of the x86 implementation with the 
upcoming POWER implementation, and defines a new flag, so that 
applications can detect which semantics the kernel uses.

A change in this area is needed to make memory protection keys usable 
for protecting the GOT in the dynamic linker.

(Feel free to replace the trigraphs in the commit message before 
committing, or to remove the program altogether.)

Thanks,
Florian

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: pkeys-signalinherit.patch --]
[-- Type: text/x-patch; name="pkeys-signalinherit.patch", Size: 0 bytes --]

[REGRESSION] testing/selftests/x86/ pkeys build failures (was: Re: [PATCH] mm, x86: pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics)

[Ingo Molnar]

* Florian Weimer <fweimer@redhat.com> wrote:

> This patch is based on the previous discussion (pkeys: Support setting
> access rights for signal handlers):
> 
>   https://marc.info/?t=151285426000001
> 
> It aligns the signal semantics of the x86 implementation with the upcoming
> POWER implementation, and defines a new flag, so that applications can
> detect which semantics the kernel uses.
> 
> A change in this area is needed to make memory protection keys usable for
> protecting the GOT in the dynamic linker.
> 
> (Feel free to replace the trigraphs in the commit message before committing,
> or to remove the program altogether.)

Could you please send patches not as MIME attachments?

Also, the protection keys testcase first need to be fixed, before we complicate 
them - for example on a pretty regular Ubuntu x86-64 installation they fail to 
build with the build errors attached further below.

On an older Fedora 23 installation, the testcases themselves don't build at all:

 fomalhaut:~/tip2/tools/testing/selftests/x86> make protection_keys
 gcc -O2 -g -std=gnu99 -pthread -Wall -no-pie    protection_keys.c   -o protection_keys
 gcc: error: unrecognized command line option a??-no-piea??
 <builtin>: recipe for target 'protection_keys' failed
 make: *** [protection_keys] Error 1

so it's one big mess at the moment that needs some love ...

Thanks,

	Ingo

==================>

triton:~/tip/tools/testing/selftests/x86> make
gcc -m32 -o /home/mingo/tip/tools/testing/selftests/x86/protection_keys_32 -O2 -g -std=gnu99 -pthread -Wall -no-pie  protection_keys.c -lrt -ldl -lm
In file included from /usr/include/signal.h:57:0,
                 from protection_keys.c:33:
protection_keys.c: In function a??signal_handlera??:
protection_keys.c:253:6: error: expected a??=a??, a??,a??, a??;a??, a??asma?? or a??__attribute__a?? before a??.a?? token
  u64 si_pkey;
      ^
protection_keys.c:253:6: error: expected expression before a??.a?? token
protection_keys.c:295:2: error: a??_sifieldsa?? undeclared (first use in this function)
  si_pkey = *si_pkey_ptr;
  ^
protection_keys.c:295:2: note: each undeclared identifier is reported only once for each function it appears in
In file included from protection_keys.c:46:0:
pkey-helpers.h: In function a??sigsafe_printfa??:
pkey-helpers.h:42:3: warning: ignoring return value of a??writea??, declared with attribute warn_unused_result [-Wunused-result]
   write(1, dprint_in_signal_buffer, len);
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
protection_keys.c: In function a??dumpita??:
protection_keys.c:419:3: warning: ignoring return value of a??writea??, declared with attribute warn_unused_result [-Wunused-result]
   write(1, buf, nr_read);
   ^~~~~~~~~~~~~~~~~~~~~~
Makefile:47: recipe for target '/home/mingo/tip/tools/testing/selftests/x86/protection_keys_32' failed

--
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>

Re: [REGRESSION] testing/selftests/x86/ pkeys build failures

[Florian Weimer]

On 01/12/2018 01:55 PM, Ingo Molnar wrote:
> 
> * Florian Weimer <fweimer@redhat.com> wrote:
> 
>> This patch is based on the previous discussion (pkeys: Support setting
>> access rights for signal handlers):
>>
>>    https://marc.info/?t=151285426000001
>>
>> It aligns the signal semantics of the x86 implementation with the upcoming
>> POWER implementation, and defines a new flag, so that applications can
>> detect which semantics the kernel uses.
>>
>> A change in this area is needed to make memory protection keys usable for
>> protecting the GOT in the dynamic linker.
>>
>> (Feel free to replace the trigraphs in the commit message before committing,
>> or to remove the program altogether.)
> 
> Could you please send patches not as MIME attachments?

My mail infrastructure corrupts patches not sent as attachments, sorry.

> Also, the protection keys testcase first need to be fixed, before we complicate
> them - for example on a pretty regular Ubuntu x86-64 installation they fail to
> build with the build errors attached further below.

I can fix things up so that they build on Fedora 26, Debian stretch, and 
Red Hat Enterprise Linux 7.  Would that be sufficient?

Fedora 23 is out of support and I'd prefer not invest any work into it.

Note that I find it strange to make this a precondition for even looking 
at the patch.

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>

Re: [REGRESSION] testing/selftests/x86/ pkeys build failures (was: Re: [PATCH] mm, x86: pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics)

[Ingo Molnar]

* Ingo Molnar <mingo@kernel.org> wrote:

> Also, the protection keys testcase first need to be fixed, before we complicate 
> them - for example on a pretty regular Ubuntu x86-64 installation they fail to 
> build with the build errors attached further below.
> 
> On an older Fedora 23 installation, the testcases themselves don't build at all:

The Ubuntu build failure seems to have gone away after a 'make clean', what 
remains is an ugly build warning:

triton:~/tip/tools/testing/selftests/x86> make
gcc -m32 -o /home/mingo/tip/tools/testing/selftests/x86/protection_keys_32 -O2 -g -std=gnu99 -pthread -Wall -no-pie  protection_keys.c -lrt -ldl -lm
protection_keys.c: In function a??dumpita??:
protection_keys.c:419:3: warning: ignoring return value of a??writea??, declared with attribute warn_unused_result [-Wunused-result]
   write(1, buf, nr_read);
   ^~~~~~~~~~~~~~~~~~~~~~
gcc -m64 -o /home/mingo/tip/tools/testing/selftests/x86/protection_keys_64 -O2 -g -std=gnu99 -pthread -Wall -no-pie  protection_keys.c -lrt -ldl
protection_keys.c: In function a??dumpita??:
protection_keys.c:419:3: warning: ignoring return value of a??writea??, declared with attribute warn_unused_result [-Wunused-result]
   write(1, buf, nr_read);
   ^~~~~~~~~~~~~~~~~~~~~~

If this build warning and the Fedora build failure is fixed we can apply your 
patch too I think.

Thanks,

	Ingo

--
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>

Re: [REGRESSION] testing/selftests/x86/ pkeys build failures

[Ingo Molnar]

* Florian Weimer <fweimer@redhat.com> wrote:

> On 01/12/2018 01:55 PM, Ingo Molnar wrote:
> > 
> > * Florian Weimer <fweimer@redhat.com> wrote:
> > 
> > > This patch is based on the previous discussion (pkeys: Support setting
> > > access rights for signal handlers):
> > > 
> > >    https://marc.info/?t=151285426000001
> > > 
> > > It aligns the signal semantics of the x86 implementation with the upcoming
> > > POWER implementation, and defines a new flag, so that applications can
> > > detect which semantics the kernel uses.
> > > 
> > > A change in this area is needed to make memory protection keys usable for
> > > protecting the GOT in the dynamic linker.
> > > 
> > > (Feel free to replace the trigraphs in the commit message before committing,
> > > or to remove the program altogether.)
> > 
> > Could you please send patches not as MIME attachments?
> 
> My mail infrastructure corrupts patches not sent as attachments, sorry.

Your headers suggest the following mail client:

  User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
        Thunderbird/52.5.0

Have you seen the suggestions in Documentation/process/email-clients.rst, which 
lists a handful of Thunderbird tips:

  Thunderbird (GUI)
  *****************

  Thunderbird is an Outlook clone that likes to mangle text, but there are ways
  to coerce it into behaving.

?

> > Also, the protection keys testcase first need to be fixed, before we complicate
> > them - for example on a pretty regular Ubuntu x86-64 installation they fail to
> > build with the build errors attached further below.
> 
> I can fix things up so that they build on Fedora 26, Debian stretch, and Red
> Hat Enterprise Linux 7.  Would that be sufficient?

Yeah, I think so.

> Fedora 23 is out of support and I'd prefer not invest any work into it.
> 
> Note that I find it strange to make this a precondition for even looking at
> the patch.

I wanted to try the patch to give review feedback, but found these annoyances. 
It's customary to make new features dependent on the cleanliness of the underlying 
code.

Thanks,

	Ingo

--
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>