Date: Fri, 30 Jul 2021 16:13:13 +0000
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
>
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
>
Received on 2021-07-30 11:13:24