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

Date:   Fri, 25 Oct 2019 10:32:20 -0700
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Andrii Nakryiko <andrii.nakryiko@...il.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, 25 Oct 2019 09:53:07 -0700, Andrii Nakryiko wrote:
> On Fri, Oct 25, 2019 at 9:31 AM Jakub Kicinski 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?

I see so the on-disk format depends on the endianness of the writer?
You write it broken and therefore you can also read it broken.
And cross compilation etc. is, I presume, on the TODO list?

Got it.