linux-kernel - Re: [PATCH 01/26] mm: asi: Make some utility functions noinstr compatible

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: <CA+i-1C3SZ4FEPJyvbrDfE-0nQtB_8L_H_i67dQb5yQ2t8KJF9Q@mail.gmail.com>
Date: Fri, 25 Oct 2024 15:21:11 +0200
From: Brendan Jackman <jackmanb@...gle.com>
To: Borislav Petkov <bp@...en8.de>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, "H. Peter Anvin" <hpa@...or.com>, 
	Andy Lutomirski <luto@...nel.org>, Peter Zijlstra <peterz@...radead.org>, 
	Sean Christopherson <seanjc@...gle.com>, Paolo Bonzini <pbonzini@...hat.com>, 
	Alexandre Chartre <alexandre.chartre@...cle.com>, Liran Alon <liran.alon@...cle.com>, 
	Jan Setje-Eilers <jan.setjeeilers@...cle.com>, Catalin Marinas <catalin.marinas@....com>, 
	Will Deacon <will@...nel.org>, Mark Rutland <mark.rutland@....com>, 
	Andrew Morton <akpm@...ux-foundation.org>, Mel Gorman <mgorman@...e.de>, 
	Lorenzo Stoakes <lstoakes@...il.com>, David Hildenbrand <david@...hat.com>, Vlastimil Babka <vbabka@...e.cz>, 
	Michal Hocko <mhocko@...nel.org>, Khalid Aziz <khalid.aziz@...cle.com>, 
	Juri Lelli <juri.lelli@...hat.com>, Vincent Guittot <vincent.guittot@...aro.org>, 
	Dietmar Eggemann <dietmar.eggemann@....com>, Steven Rostedt <rostedt@...dmis.org>, 
	Valentin Schneider <vschneid@...hat.com>, Paul Turner <pjt@...gle.com>, Reiji Watanabe <reijiw@...gle.com>, 
	Junaid Shahid <junaids@...gle.com>, Ofir Weisse <oweisse@...gle.com>, 
	Yosry Ahmed <yosryahmed@...gle.com>, Patrick Bellasi <derkling@...gle.com>, 
	KP Singh <kpsingh@...gle.com>, Alexandra Sandulescu <aesa@...gle.com>, 
	Matteo Rizzo <matteorizzo@...gle.com>, Jann Horn <jannh@...gle.com>, x86@...nel.org, 
	linux-kernel@...r.kernel.org, linux-mm@...ck.org, kvm@...r.kernel.org
Subject: Re: [PATCH 01/26] mm: asi: Make some utility functions noinstr compatible

Hey Boris,

On Fri, 25 Oct 2024 at 13:41, Borislav Petkov <bp@...en8.de> wrote:
>
> On Fri, Jul 12, 2024 at 05:00:19PM +0000, Brendan Jackman wrote:
> > +/*
> > + * Can be used for functions which themselves are not strictly noinstr, but
> > + * may be called from noinstr code.
> > + */
> > +#define inline_or_noinstr                                            \
>
> Hmm, this is confusing. So is it noinstr or is it getting inlined?

We don't care if it's getting inlined, which is kinda the point. This
annotation means "you may call this function from noinstr code". My
current understanding is that the normal noinstr annotation means
"this function fundamentally mustn't be instrumented".

So with inline_or_noinstr you get:

1. "Documentation" that the function itself doesn't have any problem
with getting traced etc.
2. Freedom for the compiler to inline or not.

> I'd expect you either always inline the small functions - as you do for some
> aleady - or mark the others noinstr. But not something in between.
>
> Why this?

Overall it's pretty likely I'm wrong about the subtlety of noinstr's
meaning. And the benefits I listed above are pretty minor. I should
have looked into this as it would have been an opportunity to reduce
the patch count of this RFC!

Maybe I'm also forgetting something more important, perhaps Junaid
will weigh in...