linux-kernel - Re: [PATCH v4 03/12] arm64: Remove the ability to build a kernel without ssbd

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190215182037.GI100037@arrakis.emea.arm.com>
Date:   Fri, 15 Feb 2019 18:20:38 +0000
From:   Catalin Marinas <catalin.marinas@....com>
To:     Andre Przywara <andre.przywara@....com>
Cc:     Jeremy Linton <jeremy.linton@....com>,
        linux-arm-kernel@...ts.infradead.org, stefan.wahren@...e.com,
        mlangsdo@...hat.com, suzuki.poulose@....com, marc.zyngier@....com,
        julien.thierry@....com, will.deacon@....com,
        linux-kernel@...r.kernel.org, steven.price@....com,
        Christoffer Dall <christoffer.dall@....com>,
        kvmarm@...ts.cs.columbia.edu, ykaukab@...e.de, dave.martin@....com,
        shankerd@...eaurora.org
Subject: Re: [PATCH v4 03/12] arm64: Remove the ability to build a kernel
 without ssbd

On Wed, Jan 30, 2019 at 06:04:15PM +0000, Andre Przywara wrote:
> On Fri, 25 Jan 2019 12:07:02 -0600
> Jeremy Linton <jeremy.linton@....com> wrote:
> > Buried behind EXPERT is the ability to build a kernel without
> > SSBD, this needlessly clutters up the code as well as creates
> > the opportunity for bugs. It also removes the kernel's ability
> > to determine if the machine its running on is vulnerable.
> 
> I don't know the original motivation for this config option, typically
> they are not around for no reason.
> I see the benefit of dropping those config options, but we want to make
> sure that people don't start hacking around to remove them again.
> 
> > Since its also possible to disable it at boot time, lets remove
> > the config option.
> 
> Given the level of optimisation a compiler can do with the state being
> known at compile time, I would imagine that it's not the same (though
> probably very close).
> 
> But that's not my call, it would be good to hear some maintainer's
> opinion on this.

Having spoken to Will, we'd rather keep the config options if possible.
Even if they are behind EXPERT and default y, they come in handy when
debugging.

Can we still have the sysfs information regardless of whether the config
is enabled or not? IOW, move the #ifdefs around to always have the
detection while being able to disable the actual workarounds via config?

Are the code paths between config and cmdline disabling identical? At a
quick look I got the impression they are not exactly the same.

-- 
Catalin