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]
Message-ID: <CAEf4BzY5o3rR3HXBPORm4NkX4SzDGTQ24p+TMmY8hxyb9+dN2g@mail.gmail.com>
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?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ