| Message ID | 1589301419-24459-3-git-send-email-Dave.Martin@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | prctl.2 man page updates for Linux 5.6 | expand |
Hi Dave, On 5/12/20 6:36 PM, Dave Martin wrote: > 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. Cheers, Michael > Signed-off-by: Dave Martin <Dave.Martin@arm.com> > --- > man2/prctl.2 | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/man2/prctl.2 b/man2/prctl.2 > index 7932ada..a35b748 100644 > --- a/man2/prctl.2 > +++ b/man2/prctl.2 > @@ -66,6 +66,11 @@ prctl \- operations on a process or thread > manipulates various aspects of the behavior > of the calling thread or process. > .PP > +Note that careless use of > +.BR prctl () > +can confuse the userspace run-time environment, > +so these operations should be used with care (if at all). > +.PP > .BR prctl () > is called with a first argument describing what to do > (with values defined in \fI<linux/prctl.h>\fP), and further >
On Wed, May 13, 2020 at 12:10:25PM +0200, Michael Kerrisk (man-pages) wrote: > Hi Dave, > > On 5/12/20 6:36 PM, Dave Martin wrote: > > 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. Maybe the whole thing is superfluous. In C anything can screw up the runtime if you try hard enough. 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. 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. Cheers ---Dave
Hi Dave, On 5/13/20 1:13 PM, Dave Martin wrote: > On Wed, May 13, 2020 at 12:10:25PM +0200, Michael Kerrisk (man-pages) wrote: >> Hi Dave, >> >> On 5/12/20 6:36 PM, Dave Martin wrote: >>> 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. > 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. > 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.) > 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. Cheers, Michael diff --git a/man2/prctl.2 b/man2/prctl.2 index 7e78fc3c1..4e2d67345 100644 --- a/man2/prctl.2 +++ b/man2/prctl.2 @@ -66,10 +66,10 @@ prctl \- operations on a process or thread manipulates various aspects of the behavior of the calling thread or process. .PP -Note that careless use of +Note that careless use of some .BR prctl () -can confuse the user-space run-time environment, -so these operations should be used with care (if at all). +operations can confuse the user-space run-time environment, +so these operations should be used with care. .PP .BR prctl () is called with a first argument describing what to do
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: > > On Wed, May 13, 2020 at 12:10:25PM +0200, Michael Kerrisk (man-pages) wrote: > >> Hi Dave, > >> > >> On 5/12/20 6:36 PM, Dave Martin wrote: > >>> 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. > > > 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. > > > 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.) > > > 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
diff --git a/man2/prctl.2 b/man2/prctl.2 index 7932ada..a35b748 100644 --- a/man2/prctl.2 +++ b/man2/prctl.2 @@ -66,6 +66,11 @@ prctl \- operations on a process or thread manipulates various aspects of the behavior of the calling thread or process. .PP +Note that careless use of +.BR prctl () +can confuse the userspace run-time environment, +so these operations should be used with care (if at all). +.PP .BR prctl () is called with a first argument describing what to do (with values defined in \fI<linux/prctl.h>\fP), and further
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. Signed-off-by: Dave Martin <Dave.Martin@arm.com> --- man2/prctl.2 | 5 +++++ 1 file changed, 5 insertions(+)