I suspect you could exploit some of how the elf bin format loading works to find it in a way that works with aslr. Just using inline asm to get the stack pointer in main and then looking at the end of that page could work too (I don't think you'll consume more than 4k of stack before main starts)

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Charlie Barto <Charles.Barto_at_[hidden]>
Sent: Friday, July 30, 2021 9:13:13 AM
To: Tom Honermann <tom_at_[hidden]>; Corentin Jabot <corentinjabot_at_[hidden]>
Cc: SG16 <sg16_at_[hidden]>; Thiago Macieira <thiago_at_[hidden]>
Subject: Re: [SG16] A UTF-8 environment specification; an alternative to assuming UTF-8 based on choice of literal encoding

I think the code should look something like:
Char* argv_and_envp_end=(char*)((1ull<<47ull)-4096) if you don't have aslr turned on

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Tom Honermann <tom_at_[hidden]>
Sent: Friday, July 30, 2021 9:08:29 AM
To: Corentin Jabot <corentinjabot_at_[hidden]>
Cc: SG16 <sg16_at_[hidden]>; Charlie Barto <Charles.Barto_at_[hidden]>; Thiago Macieira <thiago_at_[hidden]>
Subject: Re: [SG16] A UTF-8 environment specification; an alternative to assuming UTF-8 based on choice of literal encoding

On 7/30/21 12:02 PM, Corentin Jabot wrote:


On Fri, Jul 30, 2021 at 5:41 PM Tom Honermann <tom_at_[hidden]<mailto:tom_at_[hidden]>> wrote:
On 7/30/21 10:56 AM, Thiago Macieira via SG16 wrote:
> On Thursday, 29 July 2021 19:11:03 PDT Charlie Barto wrote:
>> If such functionality were to be added it would be neat if the linux
>> implementations worked even if procfs were not mounted (such as when the
>> process is init) unless I'm mistaken fetching the command line through proc
>> for your own process is making like two system calls to de-reference a
>> pointer into your own address space.
> Going off-topic here, but correcting the above.
> Procfs is not required for one's own command-line and environment in any Unix
> I know of. They are duplicated in Linux's /proc, but they are added to the
> process' virtual address space just above the stack (and below the auxv).

True today, but I suspect their location is subject to change (though
probably unlikely).

Is there a straight forward way to determine their location in memory?

Do we need to?

It seems like a robust (yet painful) solution would be to ask the language below (c folks) to make this happen
(When glibc calls main it can put argv in a global)

I only asked because I needed this functionality in the past (10+ years ago) and never found a good solution for Linux. Most of the other OSs I needed a solution for did expose these in global variables (z/OS was another notable exception; I never was able to get a properly delimited argv there other than from main()).

Tom.



Tom.

>
> Trivia: if you modify that area, the /proc files also change, allowing you to
> change the name presented in ps and similar tools.
>
> $ ps -o pid,command -Cfile.so
> PID COMMAND
> 4873 file.so [kdeinit5] file local:/run/user/1000/klauncherdAEtky.1.slave-
> socket local:/run/user/1000/kded5hvkirU.1.slave-socket
> 4874 file.so [kdeinit5] file local:/run/user/1000/klauncherdAEtky.1.slave-
> socket local:/run/user/1000/kded5FwKgfB.2.slave-socket
>