Re: [RFC] prctl: (Please do not!) Deprecate non PR_SET_MM_MAP operations

Re: [RFC] prctl: (Please do not!) Deprecate non PR_SET_MM_MAP operations

[Cyrill Gorcunov]

On Sun, May 06, 2018 at 12:01:44PM +0100, Jonathan de Boyne Pollard wrote:
...
> 
> Incidentally, it is a welcome change to see the idea that unprivileged
> processes may alter these things being introduced, as is already the case on
> (say) FreeBSD.
> 
> (I am not subscribed to linux-kernel.)

First of all, thank a lot for the feedback, Jonathan!
I'm out of office at the moment, will reply with more
details once I back.

Re: [RFC] prctl: (Please do not!) Deprecate non PR_SET_MM_MAP operations

[Cyrill Gorcunov]

On Sun, May 06, 2018 at 12:01:44PM +0100, Jonathan de Boyne Pollard wrote:
> Cyrill Gorcunov:
> 
> > Or we can simply drop it off because PR_SET_MM_MAP covers all needs, and I
> would rather prefer to do that asap.
> 
> Please do not do that, because PR_SET_MM_MAP really does not cover all
> needs.  Not by a long shot.
> 
> The use case is applications that want to affect /proc/self/cmdline and
> /proc/self/environ on the fly, for controlling what is displayed in a ps
> listing, but do not have to hand or want to deal in any of the *other*
> information that PR_SET_MM_MAP mandates.  They just want the pseudo-files to
> point to a new chunk of memory that they have allocated from their heaps and
> filled in.  They don't want to have to deal in all of the otherwise
> irrelevant stuff, of how they are loaded into memory and open file
> descriptors for executables.
> 
> * https://unix.stackexchange.com/a/438007/5132
> 
> * https://unix.stackexchange.com/a/432681/5132
> 
> You have not provided a way to read out that information, which would at
> least make a query-modify-set approach viable for such applications.  So
> please do not remove the API that works and that is in use without providing
> a usable substitute that is at least as good, which what you are proposing
> is not.  Ironically, if you replaced what you want to replace by going back
> to the original design of having start+length passed in one atomic ioctl()
> call, rather than two separate ioctl() calls for setting start and end
> individually (and the consequent hoops that applications softwares have to
> jump through when modifying to new pointer pairs, and seemingly unavoidable
> windows for outright data leaks, because they cannot read out the existing
> values and cannot even temporarily set start > end), that would be a welcome
> improvement.
> 
> Incidentally, it is a welcome change to see the idea that unprivileged
> processes may alter these things being introduced, as is already the case on
> (say) FreeBSD.
> 
> (I am not subscribed to linux-kernel.)

So eventually people use this feature outside of criu. Moreover I found that
systemd calls for PR_SET_MM_ARG_START/END (hell knows how I managed to miss
it when beeing googling for constants trying to find a user for this interface).

That said, indeed, we can't just drop it away while here are users. I'm
working on patches to bring back compat layer with the former interface.

Thanks a huge for reporting!

	Cyrill