linux-kernel - Re: [PATCH v2] RISC-V: Probe misaligned access speed in parallel

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]

Date:   Thu, 21 Sep 2023 09:49:02 -0700
From:   Evan Green <evan@...osinc.com>
To:     David Laight <David.Laight@...lab.com>
Cc:     Atish Patra <atishp@...shpatra.org>,
        Conor Dooley <conor@...nel.org>,
        Anup Patel <apatel@...tanamicro.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Heiko Stuebner <heiko@...ech.de>,
        Marc Zyngier <maz@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Palmer Dabbelt <palmer@...osinc.com>,
        Conor Dooley <conor.dooley@...rochip.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Jisheng Zhang <jszhang@...nel.org>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Greentime Hu <greentime.hu@...ive.com>,
        "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
        Andrew Jones <ajones@...tanamicro.com>
Subject: Re: [PATCH v2] RISC-V: Probe misaligned access speed in parallel

On Thu, Sep 21, 2023 at 9:44 AM Evan Green <evan@...osinc.com> wrote:
>
> On Thu, Sep 21, 2023 at 3:22 AM David Laight <David.Laight@...lab.com> wrote:
> >
> > ...
> > > > For probing alignment speed, you just care about running it on that
> > > > cpu. Correct ?
> > >
> > > For this we care both about not migrating to other CPUs, and also
> > > secondarily minimizing disturbances while the test is being run.
> > > Usually I equate pre-emption with migration, but in this case I think
> > > the worker threads are bound to that CPU. So I'll keep the
> > > preempt_disable/enable where it is, since it's harmless for CPUs other
> > > than 0, but useful for 0. I also like it for readability as it
> > > highlights the critical section (as a reader, "is preemption disabled"
> > > would be one of my first questions when studying this).
> >
> > You need to disable pre-emption to get any kind of meaningful answer.
> >
> > But why do you need to run the test on more than the boot cpu?
> > If you've a heterogenous mix of cpu any code that looks at the answer
> > is going to behave incorrectly unless it has also disabled pre-emption
> > or is bound to a cpu.
>
> I don't think it's safe to assume misaligned access speed is the same
> across all cores. In a big.little combination I can easily imagine the
> big cores having fast misaligned access and the slow cores not having
> it (though hopefully the slow cores don't kick it to firmware). Since
> this info is presented to usermode per-cpu, I'd like it to be correct.
>
> >
> > One obvious use of the result is to setup some static branches.
> > But that assumes all cpu are the same.
>
> Right, this could be used to set up static branches, or in an ifunc
> selector. This is why we provide pre-computed answers for "all CPUs"
> in hwprobe. If the situation I describe above did happen, code asking

Correction: Not exactly precomputed answers, but cached vDSO data
capable of quickly answering usermode queries for systems with
homogeneous CPUs.