Re: git: 706f4a81a812 - main - exec: Introduce the PROC_PS_STRINGS() macro

On Tue, Jan 18, 2022 at 02:18:03PM -0800, John Baldwin wrote:
> On 1/18/22 11:58 AM, Mark Johnston wrote:
> > On Tue, Jan 18, 2022 at 07:31:47AM -0800, John Baldwin wrote:
> >> On 1/17/22 1:13 PM, Mark Johnston wrote:
> >>> The branch main has been updated by markj:
> >>>
> >>> URL: https://cgit.FreeBSD.org/src/commit/?id=706f4a81a81250a326ea25914e7effe1768f1a37
> >>>
> >>> commit 706f4a81a81250a326ea25914e7effe1768f1a37
> >>> Author:     Mark Johnston <markj@FreeBSD.org>
> >>> AuthorDate: 2022-01-17 16:42:28 +0000
> >>> Commit:     Mark Johnston <markj@FreeBSD.org>
> >>> CommitDate: 2022-01-17 21:11:54 +0000
> >>>
> >>>       exec: Introduce the PROC_PS_STRINGS() macro
> >>>       
> >>>       Rather than fetching the ps_strings address directly from a process'
> >>>       sysentvec, use this macro.  With stack address randomization the
> >>>       ps_strings address is no longer fixed.
> >>>       
> >>>       Reviewed by:    kib
> >>>       MFC after:      2 weeks
> >>>       Sponsored by:   The FreeBSD Foundation
> >>>       Differential Revision:  https://reviews.freebsd.org/D33704
> >>
> >> FWIW, in CheriBSD we have a 'p_psstrings' member in struct proc that is a pointer
> >> to the ps_strings structure in user space that is set by the ABI during exec.
> > 
> > I did the exact same thing in an earlier version of the patch.  It ended
> > up being more useful to keep the stacktop address, and to derive the
> > ps_strings address from that.  I would like to MFC this as well, and
> > that'll be easier without having modified the layout of struct proc.
> 
> Ok.

As an MFCable change this seems fine.

> >> CHERI removes the need for ASLR, but due to alignment requirements of capabilities
> >> the stack is not a fixed location as its address can vary based on the size.
> > 
> > Is it possible to use PROC_PS_STRINGS() there?
> 
> Well, the other trick is that I think a more recent change from Brooks is that we
> have completely divorced the strings area (argv, envp, auxv, ps_strings, etc.) from
> the stack, so we will still need the separate pointer in CheriBSD.

This was more or less forced by CHERI bounds alignment constraints on
the stack.  It's also cleaner if the stack is only the stack, but that's
obviously not practical on existing ABIs.

-- Brooks