linux-kernel - Re: [PATCH 4.19 36/55] drivers/net/b44: Change to non-atomic bit operations on pwol

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]

Message-ID: <20200131214419.GA19569@agluck-desk2.amr.corp.intel.com>
Date:   Fri, 31 Jan 2020 13:44:19 -0800
From:   "Luck, Tony" <tony.luck@...el.com>
To:     Pavel Machek <pavel@...x.de>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Fenghua Yu <fenghua.yu@...el.com>,
        "David S. Miller" <davem@...emloft.net>,
        Sasha Levin <sashal@...nel.org>
Subject: Re: [PATCH 4.19 36/55] drivers/net/b44: Change to non-atomic bit
 operations on pwol_mask

On Fri, Jan 31, 2020 at 01:57:31PM +0100, Pavel Machek wrote:
> And I wonder if this is even good idea for mainline. x86 architecture
> is here for long time, and I doubt Intel is going to break it like
> this. Do you have documentation pointer? 

Intel isn't breaking this legacy behaviour. But it is building h/w that
allows s/w to opt-in to a mode that will generate an #AC trap for
a split lock.  One such processor ("Icelake") is already shipping.

Some Linux use cases (real-time) really, really want to avoid the cost
of a split-lock.  There's a patch in TIP that will enable this #AC on
split-lock mode on processors that support it.

Thus it's a good idea to clean up any places in the kernel that will
cause #AC when that mode is enabled. I think mainline should be
taking any patches for split lock cleanup.

Stable is a different question.  The patch to enable the #AC should
not be backported to stable. So the only way an old kernel would hit
this would be if the BIOS enabled the #AC. Really that should only
happen on a system where the developers have validated that the
entire software stack has been checked for split locks.

Is net/b44 a device that is still being included on current systems?
Or is it a legacy device that has been superceeded by something else?
If there isn't going to be a b44 on an Icelake or newer system, then
perhaps we should not worry so much about fixing the driver.

-Tony