linux-kernel - Re: [GIT PULL] x86/urgent for v6.3-rc7

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:   Wed, 19 Apr 2023 09:44:51 -0700
From:   Josh Poimboeuf <jpoimboe@...nel.org>
To:     Juergen Gross <jgross@...e.com>
Cc:     Borislav Petkov <bp@...en8.de>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>, x86-ml <x86@...nel.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] x86/urgent for v6.3-rc7

On Wed, Apr 19, 2023 at 06:03:53PM +0200, Juergen Gross wrote:
> > However, the only call site is in apic_intr_mode_init() which itself is
> > __init. So yeah, strictly speaking nothing wrong.
> > 
> > *IF* something calls it later, when __init is gone, then boom.
> > 
> > Dunno, maybe
> > 
> > a) track call sites too but maybe expensive and too much

That would indeed be a lot harder to do.

> > or
> > 
> > b) make those warnings debug messages in case someone wants to run objtool
> > in debug mode, feels really bored and wants to fix potential issues.

Possibly, though I suspect nobody's ever going to be that bored ;-)

> > Or someone has a better idea.
> > 
> > > Anyway, this is kind of experimental.  If any of these warnings don't
> > > turn out to be useful I could drop some or all them.
> > 
> > Right, I can certainly see potential and as said, since we're already
> > doing objtool massaging of object files, thought this should be pretty
> > easy to do. As you've shown. ;-)
> 
> What about splitting the function vectors into __init and non-init parts?
> 
> This would solve above problem automatically, as a non-init function couldn't
> deref the __init part of x86_platform.

Right, if we moved the __init parts of x86_platform out into a separate
struct x86_platform_init which is __initdata, that would solve this
particular issue rather cleanly.

Though, more generally, if we make the rule that non-init data can't
contain references to init data, that would be a much bigger patch set.

Which might end up being the reasonable thing to do, but before deciding
whether enforcing such a rule would be worth it, we might want to look
more deeply at the warnings to figure out what percentage of those (if
any) could be real bugs.

-- 
Josh