netdev - [RFC] .BTF section data alignment issue on s390

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-next>] [day] [month] [year] [list]

Message-ID: <20200611205040.GA1853644@krava>
Date:   Thu, 11 Jun 2020 22:50:40 +0200
From:   Jiri Olsa <jolsa@...hat.com>
To:     Ilya Leoshkevich <iii@...ux.ibm.com>,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        Vasily Gorbik <gor@...ux.ibm.com>, netdev@...r.kernel.org,
        bpf@...r.kernel.org, Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        Andrii Nakryiko <andriin@...com>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...omium.org>,
        Frantisek Hrbata <fhrbata@...hat.com>,
        Yauheni Kaliuta <yauheni.kaliuta@...hat.com>
Subject: [RFC] .BTF section data alignment issue on s390

hi,
we're hitting a problem on s390 with BTF data alignment.

When running simple test, we're getting this message from
verifier and console:

  bpf_common.c:91: BROK: Failed verification: in-kernel BTF is malformed
  [   41.545572] BPF:Total section length too long


AFAICS it happens when .BTF section data size is not an even number ;-)

DISCLAIMER I'm quite ignorant of s390x arch details, so most likely I'm
totally wrong and perhaps missing something important and there's simple
explanation.. but here's what got me here:


... so BTF data is placed in .BTF section via linker script:

        .BTF : AT(ADDR(.BTF) - LOAD_OFFSET) {                           \
                __start_BTF = .;                                        \
                *(.BTF)                                                 \
                __stop_BTF = .;                                         \
        }


and the .BTF data size in btf_parse_vmlinux is computed as:

        btf->data_size = __stop_BTF - __start_BTF;


this computation is compiled as:

        00000000002aeb20 <btf_parse_vmlinux>:
        ...
          2aeb8a:  larl    %r1,cda3ac <__start_BTF+0x2084a8>    # loads r1 with end
          2aeb90:  larl    %r2,ad1f04 <__start_BTF>             # loads r2 with start
          2aeb96:  sgr     %r1,%r2                              # substract r1 - r2 


having following values for start/stop_BTF symbols:

        # nm ./vmlinux | grep __start_BTF
        0000000000ad1f04 R __start_BTF
        # nm ./vmlinux | grep __stop_BTF
        0000000000cda3ad R __stop_BTF

        -> the BTF data size is 0x2084a9


but as you can see the instruction that loads the 'end' symbol:

        larl    %r1,cda3ac <__start_BTF+0x2084a8>


is loading '__start_BTF + 0x2084a8', which is '__stop_BTF - 1'


>From spec it seems that larl instruction's argument must be even
number ([1] page 7-214):

        2.   For  LOAD  RELATIVE  LONG,  the  second  oper-and must be aligned
        on an integral boundary cor-responding to the operand’s size. 


I also found an older bug complaining about this issue [2]:

        ...
        larl instruction can only load even values - instructions on s390 are 2-byte
        aligned and the instruction encodes offset to the target in 2-byte units.
        ...
        The GNU BFD linker for s390 doesn't bother to check if relocations fit or are
        properly aligned. 
        ...


I tried to fix that aligning the end to even number, but then
btf_check_sec_info logic needs to be adjusted as well, and
probably other places as well.. so I decided to share this
first.. because it all seems wrong ;-)

thoughts? thanks,
jirka


[1] http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr008.pdf
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=18960