netdev - Re: [PATCH 2/3] bpf_encoder: Translate SHN_XINDEX in symbol's st

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: <20210123185143.GA117714@krava>
Date:   Sat, 23 Jan 2021 19:51:43 +0100
From:   Jiri Olsa <jolsa@...hat.com>
To:     Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc:     Jiri Olsa <jolsa@...nel.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andriin@...com>, dwarves@...r.kernel.org,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
        Yonghong Song <yhs@...com>, Hao Luo <haoluo@...gle.com>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...omium.org>,
        Joe Lawrence <joe.lawrence@...hat.com>,
        Mark Wielaard <mjw@...hat.com>
Subject: Re: [PATCH 2/3] bpf_encoder: Translate SHN_XINDEX in symbol's
 st_shndx values

On Fri, Jan 22, 2021 at 02:55:51PM -0800, Andrii Nakryiko wrote:
> On Fri, Jan 22, 2021 at 12:47 PM Jiri Olsa <jolsa@...hat.com> wrote:
> >
> > On Thu, Jan 21, 2021 at 03:32:40PM -0800, Andrii Nakryiko wrote:
> >
> > SNIP
> >
> > > > @@ -598,9 +599,36 @@ static void collect_symbol(GElf_Sym *sym, struct funcs_layout *fl)
> > > >                 fl->mcount_stop = sym->st_value;
> > > >  }
> > > >
> > > > +static bool elf_sym__get(Elf_Data *syms, Elf_Data *syms_sec_idx_table,
> > > > +                        int id, GElf_Sym *sym, Elf32_Word *sym_sec_idx)
> > > > +{
> > > > +       if (!gelf_getsym(syms, id, sym))
> > > > +               return false;
> > > > +
> > > > +       *sym_sec_idx = sym->st_shndx;
> > > > +
> > > > +       if (sym->st_shndx == SHN_XINDEX) {
> > > > +               if (!syms_sec_idx_table)
> > > > +                       return false;
> > > > +               if (!gelf_getsymshndx(syms, syms_sec_idx_table,
> > > > +                                     id, sym, sym_sec_idx))
> > >
> > >
> > > gelf_getsymshndx() is supposed to work even for cases that don't use
> > > extended numbering, so this should work, right?
> > >
> > > if (!gelf_getsymshndx(syms, syms_sec_idx_table, id, sym, sym_sec_idx))
> > >     return false;
> > >
> >
> > it seems you're right, gelf_getsymshndx seem to work for
> > both cases, I'll check
> >
> >
> > > if (sym->st_shndx == SHN_XINDEX)
> > >   *sym_sec_idx = sym->st_shndx;
> >
> > I don't understand this..  gelf_getsymshndx will return both
> > symbol and proper index, no? also sym_sec_idx is already
> > assigned from previou call
> 
> Reading (some) implementation of gelf_getsymshndx() that I found
> online, it won't set sym_sec_idx, if the symbol *doesn't* use extended
> numbering. But it will still return symbol data. So to return the

the latest upstream code seems to set it always,
but I agree we should be careful

Mark, any insight in here? thanks

> section index in all cases, we need to check again *after* we got
> symbol, and if it's not extended, then set index manually.

hum, then we should use '!=', right?

  if (sym->st_shndx != SHN_XINDEX)
    *sym_sec_idx = sym->st_shndx;

SNIP

> > > so either
> > >
> > > for (id = 0; id < symtab->nr_syms && elf_sym__get(symtab->syms,
> > > symtab->syms_sec_idx_table, d, &sym, &sym_sec_idx); id++)
> > >
> > > or
> > >
> > > for (id = 0; id < symtab->nr_syms; id++)
> > >   if (elf_sym__get(symtab->syms, symtab->syms_sec_idx_table, d, &sym,
> > > &sym_sec_idx))
> >
> > if we go ahead with skipping symbols, this one seems good
> 
> I think skipping symbols is nicer. If ELF is totally broken, then all
> symbols are going to be ignored anyway. If it's some one-off issue for
> a specific symbol, we'll just ignore it (unfortunately, silently).

agreed, I'll use this

thanks,
jirka