netdev - Re: [PATCHv2] bpftool: Try to read btf as raw data if elf read fails

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:   Fri, 25 Oct 2019 09:53:07 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     Andrii Nakryiko <andriin@...com>, Jiri Olsa <jolsa@...nel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
        Yonghong Song <yhs@...com>, Martin Lau <kafai@...com>
Subject: Re: [PATCHv2] bpftool: Try to read btf as raw data if elf read fails

On Fri, Oct 25, 2019 at 9:31 AM Jakub Kicinski
<jakub.kicinski@...ronome.com> wrote:
>
> On Fri, 25 Oct 2019 05:01:17 +0000, Andrii Nakryiko wrote:
> > >> +static bool is_btf_raw(const char *file)
> > >> +{
> > >> +  __u16 magic = 0;
> > >> +  int fd;
> > >> +
> > >> +  fd = open(file, O_RDONLY);
> > >> +  if (fd < 0)
> > >> +          return false;
> > >> +
> > >> +  read(fd, &magic, sizeof(magic));
> > >> +  close(fd);
> > >> +  return magic == BTF_MAGIC;
> > >
> > > Isn't it suspicious to read() 2 bytes into an u16 and compare to a
> > > constant like endianness doesn't matter? Quick grep doesn't reveal
> > > BTF_MAGIC being endian-aware..
> >
> > Right now we support only loading BTF in native endianness, so I think
> > this should do. If we ever add ability to load non-native endianness,
> > then we'll have to adjust this.
>
> This doesn't do native endianness, this does LE-only. It will not work
> on BE machines.

How is this LE-only? You have 2 first bytes in BE-encoding on BE
machines and in LE-encoding on LE machines. You read those two bytes
as is into u16, then do comparison to u16. Given all of that is
supposed to be in native encoding, this will work. What am I missing?