netdev - RE: BTF compatibility issue across builds

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:   Wed, 16 Feb 2022 08:48:46 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Yonghong Song' <yhs@...com>, Shung-Hsi Yu <shung-hsi.yu@...e.com>
CC:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Connor O'Brien <connoro@...gle.com>,
        Michal Suchánek <msuchanek@...e.de>,
        bpf <bpf@...r.kernel.org>,
        Network Development <netdev@...r.kernel.org>,
        Andrii Nakryiko <andrii@...nel.org>,
        "Daniel Borkmann" <daniel@...earbox.net>,
        Alexei Starovoitov <ast@...nel.org>
Subject: RE: BTF compatibility issue across builds

From: Yonghong Song
> Sent: 15 February 2022 17:47
...
> > Let me try take a jab at it. Say here's a hypothetical BTF for a kernel
> > module which only type information for `struct something *`:
> >
> >    [5] PTR '(anon)' type_id=4
> >
> > Which is built upon the follow base BTF:
> >
> >    [1] INT 'unsigned char' size=1 bits_offset=0 nr_bits=8 encoding=(none)
> >    [2] PTR '(anon)' type_id=3
> >    [3] STRUCT 'list_head' size=16 vlen=2
> >          'next' type_id=2 bits_offset=0
> >          'prev' type_id=2 bits_offset=64
> >    [4] STRUCT 'something' size=2 vlen=2
> >          'locked' type_id=1 bits_offset=0
> >          'pending' type_id=1 bits_offset=8
> >
> > Due to the situation mentioned in the beginning of the thread, the *runtime*
> > kernel have a different base BTF, in this case type IDs are offset by 1 due
> > to an additional typedef entry:
> >
> >    [1] TYPEDEF 'u8' type_id=1
> >    [2] INT 'unsigned char' size=1 bits_offset=0 nr_bits=8 encoding=(none)
> >    [3] PTR '(anon)' type_id=3
> >    [4] STRUCT 'list_head' size=16 vlen=2
> >          'next' type_id=2 bits_offset=0
> >          'prev' type_id=2 bits_offset=64
> >    [5] STRUCT 'something' size=2 vlen=2
> >          'locked' type_id=1 bits_offset=0
> >          'pending' type_id=1 bits_offset=8
> >
> > Then when loading the BTF on kernel module on the runtime, the kernel will
> > mistakenly interprets "PTR '(anon)' type_id=4" as `struct list_head *`
> > rather than `struct something *`.
> >
> > Does this should possible? (at least theoretically)
> 
> Thanks for explanation. Yes, from BTF type resolution point of view,
> yes it is possible.

This looks so much like the old 'shared library function number'
ordinals from pre-SYSV and early windows shared libraries.
There is a good reason why it isn't done that way any more.

Has someone re-invented the square wheel??

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)