[RFC] .BTF section data alignment issue on s390

* [RFC] .BTF section data alignment issue on s390
@ 2020-06-11 20:50 Jiri Olsa
  2020-06-11 22:46 ` Ilya Leoshkevich
  0 siblings, 1 reply; 3+ messages in thread
From: Jiri Olsa @ 2020-06-11 20:50 UTC (permalink / raw)
  To: Ilya Leoshkevich, Heiko Carstens, Vasily Gorbik, netdev, bpf,
	Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Song Liu,
	Yonghong Song, Andrii Nakryiko, John Fastabend, KP Singh,
	Frantisek Hrbata, Yauheni Kaliuta

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

^ permalink raw reply	[flat|nested] 3+ messages in thread