linux-kernel - Re: [RESEND PATCH 0/1] Fix the "hard LOCKUP" when running a heavy loading

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:	Tue, 3 Nov 2015 11:14:37 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Caesar Wang <wxt@...k-chips.com>
Cc:	Heiko Stuebner <heiko@...ech.de>, hl@...k-chips.com,
	sjg@...omium.org, Jonathan Stone <j.stone@...sung.com>,
	dianders@...omium.org, linux-rockchip@...ts.infradead.org,
	cwz@...k-chips.com, Ard Biesheuvel <ard.biesheuvel@...aro.org>,
	Gregory CLEMENT <gregory.clement@...e-electrons.com>,
	Stephen Boyd <sboyd@...eaurora.org>,
	linux-kernel@...r.kernel.org, Huang Tao <huangtao@...k-chips.com>,
	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
	Nadav Haklai <nadavh@...vell.com>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [RESEND PATCH 0/1] Fix the "hard LOCKUP" when running a heavy
 loading

On Tue, Nov 03, 2015 at 04:10:08PM +0800, Caesar Wang wrote:
> As the Russell said:
> "in other words, which can be handled by updating a control register in
> the firmware or boot loader"
> Maybe the better solution is in firmware.

The full quote is:

"I think we're at the point where we start insisting that workarounds
which are simple enable/disable feature bit operations (in other words,
which can be handled by updating a control register in the firmware or
boot loader) must be done that way, and we are not going to add such
workarounds to the kernel anymore."

The position hasn't changed.  Workarounds such as this should be handled
in the firmware/boot loader before control is passed to the kernel.

The reason is very simple: if the C compiler can generate code which
triggers the bug, it can generate code which triggers the bug in the
boot loader.  So, the only place such workarounds can be done is before
any C code gets executed.  Putting such workarounds in the kernel is
completely inappropriate.

Sorry, I'm not going to accept this workaround into the kernel.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/