linux-kernel - Re: [PATCH v1 01/13] perf/core: add union to struct perf_branch

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: <CABPqkBQ=9pev4=iF+JwB8DZ391GGAkFbtBidkFeOt2MPeC0hyg@mail.gmail.com>
Date:   Fri, 17 Sep 2021 09:42:39 -0700
From:   Stephane Eranian <eranian@...gle.com>
To:     Michael Ellerman <mpe@...erman.id.au>
Cc:     Madhavan Srinivasan <maddy@...ux.ibm.com>,
        Peter Zijlstra <peterz@...radead.org>,
        linux-kernel@...r.kernel.org, acme@...hat.com, jolsa@...hat.com,
        kim.phillips@....com, namhyung@...nel.org, irogers@...gle.com,
        atrajeev@...ux.vnet.ibm.com,
        Arnaldo Carvalho de Melo <acme@...nel.org>
Subject: Re: [PATCH v1 01/13] perf/core: add union to struct perf_branch_entry

On Fri, Sep 17, 2021 at 5:38 AM Michael Ellerman <mpe@...erman.id.au> wrote:
>
> Stephane Eranian <eranian@...gle.com> writes:
> > Hi,
> >
> > On Fri, Sep 17, 2021 at 12:05 AM Michael Ellerman <mpe@...erman.id.au> wrote:
> >>
> >> Stephane Eranian <eranian@...gle.com> writes:
> >> > Hi,
> >> >
> >> > Thanks for fixing this in the perf tool. But what about the struct
> >> > branch_entry in the header?
> >>
> >> I'm not sure what you mean.
> >>
> >> We can't change the order of the fields in the header, without breaking
> >> existing userspace on BE systems.
> >>
> > Ok, I think I had missed that. You are saying that the
> > #ifdef (__BIG_ENDIAN_BITFIELD) vs __LITTLE_ENDIAN_BITFIELD
> >
> > is only added to kernel-only data structures?
>
> No, we *should* have used __BIG/LITTLE_ENDIAN_BITFIELD for the uapi
> definition, but we forgot.
>
But are you suggesting it cannot be fixed?

> >> It's annoying that the bit numbers are different between LE & BE, but I
> >> think it's too late to change that.
> >>
> > I agree.
> >
> >> So nothing should change in the branch_entry definition in the header.
> >>
> >> My comment on your patch was that adding the union with val, makes it
> >> easier to misuse the bitfields, because now the values can be accessed
> >> via the bitfields and also via val, but when using val you have to know
> >> that the bit numbers differ between BE/LE.
> >>
> > Ok, I get it now. We do not need to expose val to user. This is added
> > for kernel code convenience only.
>
> Yeah. Putting the union with val in the uapi encourages userspace to
> misuse val to bypass the bitfields, and that risks causing endian bugs.
>
> > But if we keep it in kernel, that may break some other rules about
> > uapi headers.
>
> I don't follow what you mean there.
>
> We could use #ifdef __KERNEL__ in the uapi header to make the union
> kernel-only, see below, but it's pretty gross.
>
>  struct perf_branch_entry {
>         __u64   from;
>         __u64   to;
>  #ifdef __KERNEL__
>         union {
>                 __u64   val;        /* to make it easier to clear all fields */
>                 struct {
>  #endif
>                         __u64   mispred:1,  /* target mispredicted */
>                                 predicted:1,/* target predicted */
>                                 in_tx:1,    /* in transaction */
>                                 abort:1,    /* transaction abort */
>                                 cycles:16,  /* cycle count to last branch */
>                                 type:4,     /* branch type */
>                                 reserved:40;
>  #ifdef __KERNEL__
>                 };
>         };
>  #endif
>  };
>
>
> If we just do the inline I suggested we can clear the flags in a single
> source line, and the generated code seems fine too, eg:
>
> static inline void clear_perf_branch_entry_flags(struct perf_branch_entry *e)
> {
>         e->mispred = 0;
>         e->predicted = 0;
>         e->in_tx = 0;
>         e->abort = 0;
>         e->cycles = 0;
>         e->type = 0;
>         e->reserved = 0;
> }
>
Ok, let's do the inline then. That looks like a cleaner solution to me
assuming the compiler does the right thing.