On Wed, May 13, 2020 at 01:40:26PM +0200, Michael Kerrisk (man-pages) wrote:

Hi Dave,

On 5/13/20 1:13 PM, Dave Martin wrote:

quoted

On Wed, May 13, 2020 at 12:10:25PM +0200, Michael Kerrisk (man-pages) wrote:

quoted

Hi Dave,

On 5/12/20 6:36 PM, Dave Martin wrote:

quoted

In reality, almost every prctl interferes with assumptions that the
compiler and C library / runtime rely on.  prctl() can therefore
make userspace explode in a variety ways that are likely to be hard
to debug.

This is not obvious to the uninitiated, so add a warning.

Patch applied. But see my comments on patch 04. I may want to 
circle back on this patch later, since the wording feels a 
little strong to me (we simply must use prctl for some things, 
and not all of those things break user-space/runtime as far 
as I know). If you have some thoughts on softening the warning,
let me know.

Certainly the "if at all" can go -- this was just a suggestion
really.

Yes. Gone.

quoted

Maybe the whole thing is superfluous.  In C anything can screw up the
runtime if you try hard enough.

I think it's at least worth alerting the reader to this issue.

quoted

The background to this patch is that things like the new
PR_PAC_RESET_KEYS and PR_SVE_SET_VL are likely to crash the program, or
place a timebomb that will explode later when someone upgrades their
toolchain or links with a new version of some library.  Many existing
prctls that look equally unfriendly...

I didn't want to say nothing at all, but I didn't want to get into the
gory details either.

(Okay.)

quoted

Doing the digging to document the safety requirements of each prctl
would be a lot of work, and probably an exercise in futility anyway --
how to use a lot of prctls safely depends on the run-time environment as
much as it does on the kernel.


If you want to drop this, I'm happy to add explicit notes to just the
new arm64 prctls instead for now.

I just softened the warning a little; see below. Explicit notes for
the new arm64 prctls would certainly be welcome.

OK, that works for me.  I'll try to keep it brief.

Cheers
---Dave

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel