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:   Thu, 12 May 2022 01:40:57 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Delyan Kratunov <delyank@...com>,
        "peterz@...radead.org" <peterz@...radead.org>
Cc:     "dietmar.eggemann@....com" <dietmar.eggemann@....com>,
        "bigeasy@...utronix.de" <bigeasy@...utronix.de>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "qais.yousef@....com" <qais.yousef@....com>,
        Delyan Kratunov <delyank@...com>,
        "andrii@...nel.org" <andrii@...nel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "adharmap@...cinc.com" <adharmap@...cinc.com>,
        "alexei.starovoitov@...il.com" <alexei.starovoitov@...il.com>,
        "andrii.nakryiko@...il.com" <andrii.nakryiko@...il.com>,
        "ast@...nel.org" <ast@...nel.org>,
        "Kenta.Tada@...y.com" <Kenta.Tada@...y.com>,
        "rdunlap@...radead.org" <rdunlap@...radead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "bristot@...hat.com" <bristot@...hat.com>,
        "ebiederm@...ssion.com" <ebiederm@...ssion.com>,
        "mingo@...nel.org" <mingo@...nel.org>,
        "rostedt@...dmis.org" <rostedt@...dmis.org>,
        "ed.tsai@...iatek.com" <ed.tsai@...iatek.com>,
        "legion@...nel.org" <legion@...nel.org>,
        "acme@...nel.org" <acme@...nel.org>,
        "u.kleine-koenig@...gutronix.de" <u.kleine-koenig@...gutronix.de>,
        "valentin.schneider@....com" <valentin.schneider@....com>,
        "juri.lelli@...hat.com" <juri.lelli@...hat.com>,
        "namhyung@...nel.org" <namhyung@...nel.org>
Subject: Re: [PATCH v2] sched/tracing: append prev_state to tp args instead

On Wed, May 11 2022 at 18:28, Delyan Kratunov wrote:
> Commit fa2c3254d7cf (sched/tracing: Don't re-read p->state when emitting
> sched_switch event, 2022-01-20) added a new prev_state argument to the
> sched_switch tracepoint, before the prev task_struct pointer.
>
> This reordering of arguments broke BPF programs that use the raw
> tracepoint (e.g. tp_btf programs). The type of the second argument has
> changed and existing programs that assume a task_struct* argument
> (e.g. for bpf_task_storage access) will now fail to verify.
>
> If we instead append the new argument to the end, all existing programs
> would continue to work and can conditionally extract the prev_state
> argument on supported kernel versions.

If we instead? ... would continue to work?

  https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#changelog
  https://www.kernel.org/doc/html/latest/process/submitting-patches.html#submittingpatches

It's not too hard to actually follow documented rules. Something like
this:

  "Undo the reordering and move the new argument last, which ensures
   that all existing programs continue to work."

Hmm?

What's worse is that the changelog is missing a clear statement that
this is a one-time change which cannot be abused to turn tracepoints
into unmodifiable ABI as you stated in:

 https://lore.kernel.org/lkml/CAEf4BzaEo+dxSRJZHQiXYrj-a3_B-eODZUxGh3HrnPjquMYFXQ@mail.gmail.com

Thanks,

        tglx



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ