linux-kernel - Re: [PATCH] arm: Add Arm Erratum 773769 for Large data RAM latency.

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: <CAD=FV=W_=NsEXwfnSw_VzwboDZHWU+AX09f0ECNX-XqYDF5Phg@mail.gmail.com>
Date:	Wed, 8 Jan 2014 13:32:15 -0800
From:	Doug Anderson <dianders@...omium.org>
To:	Nicolas Pitre <nico@...xnic.net>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	Will Deacon <will.deacon@....com>,
	Vivek Gautam <gautam.vivek@...sung.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-samsung-soc@...r.kernel.org" 
	<linux-samsung-soc@...r.kernel.org>,
	"kgene.kim@...sung.com" <kgene.kim@...sung.com>,
	"sboyd@...eaurora.org" <sboyd@...eaurora.org>,
	David Garbett <David.Garbett@....com>,
	Catalin Marinas <Catalin.Marinas@....com>,
	"gregory.clement@...e-electrons.com" 
	<gregory.clement@...e-electrons.com>,
	Olof Johansson <olofj@...omium.org>
Subject: Re: [PATCH] arm: Add Arm Erratum 773769 for Large data RAM latency.

Nicolas,

On Wed, Jan 8, 2014 at 12:58 PM, Nicolas Pitre <nico@...xnic.net> wrote:
> On Wed, 8 Jan 2014, Doug Anderson wrote:
>
>> On Wed, Jan 8, 2014 at 11:20 AM, Russell King - ARM Linux
>> <linux@....linux.org.uk> wrote:
>> > We've been through these arguments many times, you're not the first to
>> > raise it, and we've decided upon the policy.  We want as _few_ work-
>> > arounds in the kernel as possible, because applying the work-arounds
>> > is very problematical with the mixture of secure and non-secure booting.
>>
>> OK, fair enough.  If we want no workaround here then we can drop this patch.
>>
>>
>> I'd guess that the way forward is:
>>
>> * Land kernel workaround locally in Chromium tree
>>
>> * I'll try to land FW change locally in at least one Chromium branch.
>> If we were to get a new RO build ever (seems unlikely at this point)
>> it would be fixed for upstream kernels.  If we were to get a new RW
>> build (seems unlikely, but at least less unlikely) it would be fixed
>> if someone landed a kernel patch to save/restore this register across
>> suspend/resume.
>>
>> * If Joe Upstream wants to run an upstream kernel on some type of
>> exynos5250 product (Samsung ARM Chromebook, HP Chromebook 11, Nexus 10
>> are the ones I know of) then he will deal with the small number of
>> crashes or figure out a solution.
>
> At some point you have to realize that what you're proposing is not
> viable when taking into account the bigger picture.  And your FW
> architecture is to blame.  If you were running Windows instead of Linux
> I bet you'd have found a way to fix things differently than asking
> Microsoft to add a special quirk in their code.  In the PC world you are
> required to perform a BIOS update instead.

Yup, I can believe that.

...I'm merely trying to report reality.  Firmware updates (even RW
ones) require an extra level of scrutiny / testing and a chunk of
in-house resources.  Those resources get allocated if there is no
other choice, but I can't force a lot of people to spend a lot of time
to approve a RW firmware update (actually approving >= 3 RW firmware
updates since there are at least three different 5250 variants) when
there is a simple and low risk kernel fix for it.  I could try, but
I'll get slapped down / laughed at.

If this were the Windows/x86 world and we had no choice the decision
would go a different way.  ...but we're not in the Windows/x86 world.


> So you really need to provision the ability to update at least a portion
> of the firmware that is not read-only.  That may be a third-stage
> bootloader or the like which purpose is only to install workarounds such
> as this before executing the kernel and which doesn't need to be updated
> with the kernel.  And in theory you should be able to do that on top of
> your current RO firmware.

The fact that we have too much code in RO is a known issue and people
are definitely working on that.  It has already bitten us.  It's
unlikely that someone will try retrofit something to work on existing
devices, though.

-Doug
--
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/