Re: git: 706f4a81a812 - main - exec: Introduce the PROC_PS_STRINGS() macro
Date: Tue, 18 Jan 2022 22:18:03 UTC
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. >> 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. -- John Baldwin