linux-kernel - Re: [PATCH v2 04/12] tools/nolibc: crt.h: add _start

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 11 Jul 2023 00:45:43 +0800
From:   Zhangjin Wu <falcon@...ylab.org>
To:     thomas@...ch.de
Cc:     arnd@...db.de, falcon@...ylab.org, linux-kernel@...r.kernel.org,
        linux-kselftest@...r.kernel.org, w@....eu
Subject: Re: [PATCH v2 04/12] tools/nolibc: crt.h: add _start_c

Hi, Thomas

> On 2023-07-10 17:26:43+0800, Zhangjin Wu wrote:
> > > On 2023-07-08 23:29:58+0800, Zhangjin Wu wrote:
[...]
> 
> > > It also seems like a good opportunity to add some tests for
> > > argv/environment variable passing.
> > 
> > Yes, and even further, we can do more on auxv, just like musl does in
> > src/env/__libc_start_main.c, not that urgent currently:
> 
> With tests I mean nolibc-test.c to make sure we don't introduce any
> regressions.
> Only some tiny testcases to validate that argv and environ are picked
> up correctly by the startup code on all arches.
>

Thomas, seems we already have some testcases for argv, environ and auxv
currently:

    run_syscall: chmod_argv0 <-- argv[0]
		 chdir_root  <-- chdir(getenv("PWD"))
                 getpagesize <-- getauxval(AT_PAGESZ)
    run_stdlib : getenv_TERM <-- getenv

> > 
[...]
> > >
> > 
> > Ok, welcome to discuss more in this thread:
> > 
> >     https://lore.kernel.org/lkml/20230710072340.10798-1-falcon@tinylab.org/
> > 
> > and let's choose a better method as possible as we can, Just replied Willy to
> > explain more.
> 
> Will do.
> 
> > > > Signed-off-by: Zhangjin Wu <falcon@...ylab.org>
> > > > ---
> > > >  tools/include/nolibc/crt.h | 44 ++++++++++++++++++++++++++++++++++++++
> > > >  1 file changed, 44 insertions(+)
> > > > 
> > > > diff --git a/tools/include/nolibc/crt.h b/tools/include/nolibc/crt.h
> > > > index 221b7c5346ca..b269294e9664 100644
> > > > --- a/tools/include/nolibc/crt.h
> > > > +++ b/tools/include/nolibc/crt.h
> > > > @@ -13,4 +13,48 @@
> > > >  char **environ __attribute__((weak));
> > > 
> > > The old code seems to avoid putting "environ" into the global symbol
> > > namespace. Could this declaration be moved into the function like in
> > > getenv()?
> > >
> > 
> > ok, do you mean just move it to stdlib.h like this? I moved _auxv (used
> > by getauxv()) to stdlib.h too:
> 
> Nevermind, I got confused by the in-function declaration of
> "extern char **environ" inside "getenv()".
> Actually this in-function declaration doesn't do anything and can be
> dropped.
>

Yes. for nolibc application is in one-file style, let's remove it.

> > 
[...]
> > > 
> > > This will lead to conflicting declarations if the users use a different
> > > signature. I'm not (yet?) sure how to work around this.
> > >
> > 
> > Ah yes, I forgot this critical case, people may use something like:
> > 
> >     int main(void)
> >     int main(int argc, char *argv[])
> 
> > [..]
> 
> I thought about this general problem and it turns out that there is
> nothing that any libc can do to distinguish these special cases.
> So it has to be handled in the compiler and we do not have to care.

Ok.

Thanks,
Zhangjin

> 
> Thomas