linux-kernel - Re: [PATCH v2] kheaders: Follow symlinks to source files.

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]

Message-ID: <CAABy=s17M5Xu_LhfrzP3vton9AK7n30PB9Hm3Z7iAHS+H5WxcA@mail.gmail.com>
Date:   Tue, 2 May 2023 15:16:38 -0700
From:   Yifan Hong <elsk@...gle.com>
To:     Masahiro Yamada <masahiroy@...nel.org>
Cc:     Nicolas Schier <nicolas@...sle.eu>,
        Thomas Weißschuh <linux@...ssschuh.net>,
        Matthias Maennich <maennich@...gle.com>,
        Daniel Mentz <danielmentz@...gle.com>, kernel-team@...roid.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] kheaders: Follow symlinks to source files.

On Mon, Apr 24, 2023 at 11:32 AM Yifan Hong <elsk@...gle.com> wrote:
>
> On Sun, Apr 23, 2023 at 4:53 AM Masahiro Yamada <masahiroy@...nel.org> wrote:
> >
> > On Thu, Apr 20, 2023 at 10:01 AM Yifan Hong <elsk@...gle.com> wrote:
> > >
> > > When the kernel is built inside a sandbox container,
> > > a forest of symlinks to the source files may be
> > > created in the container. In this case, the generated
> > > kheaders.tar.xz should follow these symlinks
> > > to access the source files, instead of packing
> > > the symlinks themselves.
> > >
> > > Signed-off-by: Yifan Hong <elsk@...gle.com>
> > > Reviewed-by: Matthias Maennich <maennich@...gle.com>
> >
> >
> >
> > Please teach me how to reproduce your problem.
>
> Thanks for your reply. When I say "container", I mean a forest of
> symlinks that point to the original source files. Here are the steps I
> do to mimic the sandbox that the container program creates.
>
> On an x86 machine, I have a linux tree checkout at /mnt/sdb/linux, and
> an empty directory at /mnt/sdb/linux2. Then I **created this fake
> sandbox** in /mnt/sdb/linux2 by doing:
> ```
> $ cd /mnt/sdb/linux
> $ find . -type d -exec mkdir -p /mnt/sdb/linux2/{} \;
> $ find . -type f -exec ln -sf /mnt/sdb/linux/{} /mnt/sdb/linux2/{} \;
> ```
>
> Then, I cross compile an arm64 kernel with tinyconfig. Here are the
> steps I take:
> ```
> export ARCH=arm64
> export SUBARCH=arm
> export CROSS_COMPILE=/home/elsk/toolchains/aarch64--glibc--stable-2022.08-1/bin/aarch64-linux-
> # downloaded from https://toolchains.bootlin.com/
> make tinyconfig; make menuconfig # then select CONFIG_SYSFS and CONFIG_IKHEADERS
> make -j64
> ```
>
> This will show that kheaders_data.tar.xz contains the symlinks, e.g. in my case:
> ```
> $ tar tvf ./kernel/kheaders_data.tar.xz | head
> [...]
> lrwxrwxrwx 0/0               0 2023-04-24 11:19
> ./arch/arm64/include/asm/acenv.h ->
> /mnt/sdb/linux/./arch/arm64/include/asm/acenv.h
> ```
>
> However, the issue for me is that these symlinks are no longer useful
> under sysfs when I am booting the kernel on the target arm64 machine,
> because it is a different machine (arm64) than the machine (x86) where
> I compiled this kernel.
>
> >
> >
> >
> > I built the kernel inside a container,
> > but I do not see any difference.
> >
> >
> >
> > We have some symbolic links in include/,
> > but those reference relative paths.
> > How building the kernel in a container
> > makes a difference?
>
> Please see above; the container contains a forest of symlinks pointing
> to the original source tree. Then `make` is executed in that container
> directory.
>
> >
> >
> > masahiro@...c2c958b53:/tmp/foo$ tar Jxf kheaders_data.tar.xz
> > masahiro@...c2c958b53:/tmp/foo$ find . -type l
> > ./include/dt-bindings/clock/qcom,dispcc-sm8350.h
> > ./include/dt-bindings/clock/qcom,dispcc-sm8150.h
> > ./include/dt-bindings/input/linux-event-codes.h
> > masahiro@...c2c958b53:/tmp/foo$ find . -type l | xargs ls -l
> > lrwxrwxrwx 1 masahiro masahiro 20 Apr 23 11:47
> > ./include/dt-bindings/clock/qcom,dispcc-sm8150.h ->
> > qcom,dispcc-sm8250.h
> > lrwxrwxrwx 1 masahiro masahiro 20 Apr 23 11:47
> > ./include/dt-bindings/clock/qcom,dispcc-sm8350.h ->
> > qcom,dispcc-sm8250.h
> > lrwxrwxrwx 1 masahiro masahiro 36 Apr 23 11:47
> > ./include/dt-bindings/input/linux-event-codes.h ->
> > ../../uapi/linux/input-event-codes.h
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > ---
> > >  kernel/gen_kheaders.sh | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/kernel/gen_kheaders.sh b/kernel/gen_kheaders.sh
> > > index 1ef9a87511f5..70a75a9a7535 100755
> > > --- a/kernel/gen_kheaders.sh
> > > +++ b/kernel/gen_kheaders.sh
> > > @@ -87,7 +87,7 @@ find $cpio_dir -type f -print0 |
> > >  # pre-sorted, as --sort=name might not be available.
> > >  find $cpio_dir -printf "./%P\n" | LC_ALL=C sort | \
> > >      tar "${KBUILD_BUILD_TIMESTAMP:+--mtime=$KBUILD_BUILD_TIMESTAMP}" \
> > > -    --owner=0 --group=0 --numeric-owner --no-recursion \
> > > +    --owner=0 --group=0 --numeric-owner --no-recursion --dereference \
> > >      -I $XZ -cf $tarfile -C $cpio_dir/ -T - > /dev/null
> > >
> > >  echo $headers_md5 > kernel/kheaders.md5
> > > --
> > > 2.40.0.634.g4ca3ef3211-goog
> > >
> >
> >
> > --
> > Best Regards
> > Masahiro Yamada
> >
> > --
> > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@...roid.com.
> >

Gently nagging. Is there anything I need to fix or do to improve this
patch so it may be accepted? Thank you!