linux-kernel - Re: [PATCH v2 5/5] x86,vdso: Create .build-id links for unstripped vdso 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]

Date:   Thu, 25 Apr 2019 20:41:10 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     Andy Lutomirski <luto@...capital.net>,
        Andy Lutomirski <luto@...nel.org>
Cc:     Josh Boyer <jwboyer@...oraproject.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        "Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 5/5] x86,vdso: Create .build-id links for unstripped
 vdso files

Hi Andy,

On Sat, Jun 21, 2014 at 4:23 AM Andy Lutomirski <luto@...capital.net> wrote:
>
> With this change, doing 'make vdso_install' and telling gdb:
>
> set debug-file-directory /lib/modules/KVER/vdso
>
> will enable vdso debugging with symbols.  This is useful for
> testing, but kernel RPM builds will probably want to manually delete
> these symlinks or otherwise do something sensible when they strip
> the vdso/*.so files.
>
> If ld does not support --build-id, then the symlinks will not be
> created.
>
> Note that kernel packagers that use vdso_install may need to adjust
> their packaging scripts to accomdate this change.  For example,
> Fedora's scripts create build-id symlinks themselves in a different
> location, so the spec should probably be updated to remove the
> symlinks created by make vdso_install.
>
> Signed-off-by: Andy Lutomirski <luto@...capital.net>
> ---

I was looking into this, but
I am not familiar enough with this area.


Could you tell me how it works?


I use Ubuntu 18.04 LTS.
Luckily, it has build-id symlinks by default,
so I should be able to test it easily.



masahiro@pug:~$ uname -r
4.15.0-47-generic
masahiro@pug:~$ cd /lib/modules/4.15.0-47-generic/vdso/
masahiro@pug:/lib/modules/4.15.0-47-generic/vdso$ file vdso64.so
vdso64.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
dynamically linked,
BuildID[sha1]=d742540fb9ded5c3650dbe9ae20c0f39e386464c, with
debug_info, not stripped
masahiro@pug:/lib/modules/4.15.0-47-generic/vdso$ ls -l
.build-id/d7/42540fb9ded5c3650dbe9ae20c0f39e386464c.debug
lrwxrwxrwx 1 root root 15 Mar 13 13:37
.build-id/d7/42540fb9ded5c3650dbe9ae20c0f39e386464c.debug ->
../../vdso64.so


I dumped the vdso embedded in the kernel,
and I confirmed its build-id matches
to the one of unstripped vdso.


So, I expect the vdso with symbol info will be automatically loaded
by setting debug-file-directory to /lib/modules/4.15.0-47-generic/vdso.
Am I right?

If it works as expected, how should it look like?

I started gdb like this:

$ gdb date

Then, I did:

(gdb) set debug-file-directory
/usr/lib/debug:/lib/modules/4.15.0-47-generic/vdso
(gdb) show debug-file-directory
The directory where separate debug symbols are searched for is
"/usr/lib/debug:/lib/modules/4.15.0-47-generic/vdso".
(gdb) run


The list of shared library looks like follows:


(gdb) info sharedlibrary
>From                To                  Syms Read   Shared Object Library
0x00007ffff7dd5f10  0x00007ffff7df4b20  Yes         /lib64/ld-linux-x86-64.so.2
0x00007ffff7a052d0  0x00007ffff7b7dc3c  Yes
/lib/x86_64-linux-gnu/libc.so.6
                                        No          linux-vdso.so.1



The first two shared objects shows "Yes" because debug info
is available under /usr/lib/debug/lib/x86_64-linux-gnu/
and associated by .gnu_debuglink.


linux-vdso.so.1 shows "No".
Does it mean no symbol was included ?


Thank you.

Masahiro Yamada




>  arch/x86/vdso/Makefile | 16 +++++++++++++---
>  1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/vdso/Makefile b/arch/x86/vdso/Makefile
> index 2c1ca98..68a15c4 100644
> --- a/arch/x86/vdso/Makefile
> +++ b/arch/x86/vdso/Makefile
> @@ -169,14 +169,24 @@ quiet_cmd_vdso = VDSO    $@
>                  sh $(srctree)/$(src)/checkundef.sh '$(NM)' '$@'
>
>  VDSO_LDFLAGS = -fPIC -shared $(call cc-ldoption, -Wl$(comma)--hash-style=sysv) \
> -       -Wl,-Bsymbolic $(LTO_CFLAGS)
> +       $(call cc-ldoption, -Wl$(comma)--build-id) -Wl,-Bsymbolic $(LTO_CFLAGS)
>  GCOV_PROFILE := n
>
>  #
> -# Install the unstripped copies of vdso*.so.
> +# Install the unstripped copies of vdso*.so.  If our toolchain supports
> +# build-id, install .build-id links as well.
>  #
>  quiet_cmd_vdso_install = INSTALL $(@:install_%=%)
> -      cmd_vdso_install = cp $< $(MODLIB)/vdso/$(@:install_%=%)
> +define cmd_vdso_install
> +       cp $< "$(MODLIB)/vdso/$(@:install_%=%)"; \
> +       if readelf -n $< |grep -q 'Build ID'; then \
> +         buildid=`readelf -n $< |grep 'Build ID' |sed -e 's/^.*Build ID: \(.*\)$$/\1/'`; \
> +         first=`echo $$buildid | cut -b-2`; \
> +         last=`echo $$buildid | cut -b3-`; \
> +         mkdir -p "$(MODLIB)/vdso/.build-id/$$first"; \
> +         ln -sf "../../$(@:install_%=%)" "$(MODLIB)/vdso/.build-id/$$first/$$last.debug"; \
> +       fi
> +endef
>
>  vdso_img_insttargets := $(vdso_img_sodbg:%.dbg=install_%)
>
> --
> 1.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



-- 
Best Regards
Masahiro Yamada