From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>,
ARM kernel mailing list
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>
Subject: Re: Multi-platform, and secure-only ARM errata workarounds
Date: Tue, 26 Feb 2013 11:01:30 -0700 [thread overview]
Message-ID: <512CF87A.4090404@wwwdotorg.org> (raw)
In-Reply-To: <20130226113538.GS17833-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
On 02/26/2013 04:35 AM, Russell King - ARM Linux wrote:
> On Tue, Feb 26, 2013 at 10:23:26AM +0000, Arnd Bergmann wrote:
>> On Monday 25 February 2013, Stephen Warren wrote:
>>> Is there any other alternative I'm not seeing? Having the kernel
>>> suddenly become incompatible with any currently extant bootloader when I
>>> enable CONFIG_MULTIPLATFORM doesn't seem like a great idea.
>>
>> Could we make those errata be run-time enabled only when not booting
>> in secure mode?
>
> The long and the short answer to this is... no.
>
> 1. It is impossible to tell whether we're running secure or non-secure.
>
> 2. Errata need to be applied before the MMU is initialized. We need the
> MMU to be initialized to run any C code what so ever, so calling out
> to platform specific code to set errata is not possible. Moreover,
> we no longer determine the platform in the assembly code since DT
> came along: this was removed because detecting it in DT from assembly
> is far from trivial (you'd need to write an assembly DT parser).
>
> Now, as for having the secure mode errata enabled on a kernel running in
> non-secure mode... what happens today is that we check whether something
> before the kernel has enabled the workaround, and we omit to write to
> the register.
>
> What that means is that we expect whatever came before the kernel to have
> appropriately enabled the bits in the secure registers. If it hasn't,
> and you have one of these secure mode workarounds enabled, the kernel
> will fault at boot time.
The conditional in that statement makes me wonder which of the following
operations will fault in non-secure mode:
1) Reading from the diagnostic register.
2) Writing to the diagnostic register, of a value the same as what's
already there.
3) Writing to the diagnostic register, of a value different than what's
already there.
Would the following not fault in both secure and non-secure mode:
read diagnostic register
if desired bit already set:
b 1f
set desired bit
write value back to diagnostic register
1:
If so, that would allow a multi-SoC kernel to keep the errata workaround
enabled, and allow the kernel to apply the WAR /if/ booted in secure
mode, but require the errata to be previously enabled if the kernel was
not booted in secure mode.
WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: Multi-platform, and secure-only ARM errata workarounds
Date: Tue, 26 Feb 2013 11:01:30 -0700 [thread overview]
Message-ID: <512CF87A.4090404@wwwdotorg.org> (raw)
In-Reply-To: <20130226113538.GS17833@n2100.arm.linux.org.uk>
On 02/26/2013 04:35 AM, Russell King - ARM Linux wrote:
> On Tue, Feb 26, 2013 at 10:23:26AM +0000, Arnd Bergmann wrote:
>> On Monday 25 February 2013, Stephen Warren wrote:
>>> Is there any other alternative I'm not seeing? Having the kernel
>>> suddenly become incompatible with any currently extant bootloader when I
>>> enable CONFIG_MULTIPLATFORM doesn't seem like a great idea.
>>
>> Could we make those errata be run-time enabled only when not booting
>> in secure mode?
>
> The long and the short answer to this is... no.
>
> 1. It is impossible to tell whether we're running secure or non-secure.
>
> 2. Errata need to be applied before the MMU is initialized. We need the
> MMU to be initialized to run any C code what so ever, so calling out
> to platform specific code to set errata is not possible. Moreover,
> we no longer determine the platform in the assembly code since DT
> came along: this was removed because detecting it in DT from assembly
> is far from trivial (you'd need to write an assembly DT parser).
>
> Now, as for having the secure mode errata enabled on a kernel running in
> non-secure mode... what happens today is that we check whether something
> before the kernel has enabled the workaround, and we omit to write to
> the register.
>
> What that means is that we expect whatever came before the kernel to have
> appropriately enabled the bits in the secure registers. If it hasn't,
> and you have one of these secure mode workarounds enabled, the kernel
> will fault at boot time.
The conditional in that statement makes me wonder which of the following
operations will fault in non-secure mode:
1) Reading from the diagnostic register.
2) Writing to the diagnostic register, of a value the same as what's
already there.
3) Writing to the diagnostic register, of a value different than what's
already there.
Would the following not fault in both secure and non-secure mode:
read diagnostic register
if desired bit already set:
b 1f
set desired bit
write value back to diagnostic register
1:
If so, that would allow a multi-SoC kernel to keep the errata workaround
enabled, and allow the kernel to apply the WAR /if/ booted in secure
mode, but require the errata to be previously enabled if the kernel was
not booted in secure mode.
next prev parent reply other threads:[~2013-02-26 18:01 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-25 23:47 Multi-platform, and secure-only ARM errata workarounds Stephen Warren
2013-02-25 23:47 ` Stephen Warren
2013-02-26 9:36 ` Marc Dietrich
2013-02-26 9:36 ` Marc Dietrich
[not found] ` <4928288.ie8EUukfVD-D3pzGp0ZKuDWZbiwp4sFPyrtisivX6KghOMvlBiLbJSELgA04lAiVw@public.gmane.org>
2013-02-26 16:39 ` Stephen Warren
2013-02-26 16:39 ` Stephen Warren
[not found] ` <512CE533.6020005-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-02-26 22:31 ` Nicolas Pitre
2013-02-26 22:31 ` Nicolas Pitre
2013-02-27 9:03 ` Marc Dietrich
2013-02-27 9:03 ` Marc Dietrich
[not found] ` <22709540.96uJddbx1U-D3pzGp0ZKuDWZbiwp4sFPyrtisivX6KghOMvlBiLbJSELgA04lAiVw@public.gmane.org>
2013-02-27 14:00 ` Rob Herring
2013-02-27 14:00 ` Rob Herring
2013-02-27 17:42 ` Stephen Warren
2013-02-27 17:42 ` Stephen Warren
2013-02-28 13:58 ` Marc Dietrich
2013-02-28 13:58 ` Marc Dietrich
[not found] ` <512BF81A.3080700-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-02-26 10:23 ` Arnd Bergmann
2013-02-26 10:23 ` Arnd Bergmann
[not found] ` <201302261023.26939.arnd-r2nGTMty4D4@public.gmane.org>
2013-02-26 10:31 ` Catalin Marinas
2013-02-26 10:31 ` Catalin Marinas
[not found] ` <20130226103114.GA16875-5wv7dgnIgG8@public.gmane.org>
2013-02-26 10:35 ` Catalin Marinas
2013-02-26 10:35 ` Catalin Marinas
[not found] ` <20130226103503.GB16875-5wv7dgnIgG8@public.gmane.org>
2013-02-26 10:48 ` Arnd Bergmann
2013-02-26 10:48 ` Arnd Bergmann
[not found] ` <201302261048.06644.arnd-r2nGTMty4D4@public.gmane.org>
2013-02-26 11:11 ` Catalin Marinas
2013-02-26 11:11 ` Catalin Marinas
2013-02-26 11:35 ` Russell King - ARM Linux
2013-02-26 11:35 ` Russell King - ARM Linux
[not found] ` <20130226113538.GS17833-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2013-02-26 14:07 ` Rob Herring
2013-02-26 14:07 ` Rob Herring
2013-02-26 18:01 ` Stephen Warren [this message]
2013-02-26 18:01 ` Stephen Warren
[not found] ` <512CF87A.4090404-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-02-26 18:11 ` Russell King - ARM Linux
2013-02-26 18:11 ` Russell King - ARM Linux
[not found] ` <20130226181114.GU17833-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2013-02-26 18:30 ` Stephen Warren
2013-02-26 18:30 ` Stephen Warren
[not found] ` <512CFF30.9080300-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-02-26 18:49 ` Russell King - ARM Linux
2013-02-26 18:49 ` Russell King - ARM Linux
[not found] ` <20130226184942.GV17833-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2013-02-27 6:07 ` Santosh Shilimkar
2013-02-27 6:07 ` Santosh Shilimkar
2013-03-01 17:37 ` Stephen Warren
2013-03-01 17:37 ` Stephen Warren
[not found] ` <5130E757.6090500-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-03-01 18:05 ` Russell King - ARM Linux
2013-03-01 18:05 ` Russell King - ARM Linux
2013-03-04 6:34 ` Peter De Schrijver
2013-03-04 6:34 ` Peter De Schrijver
[not found] ` <20130304063436.GB27241-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>
2013-03-04 9:16 ` Peter De Schrijver
2013-03-04 9:16 ` Peter De Schrijver
[not found] ` <20130304091600.GC27241-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>
2013-03-04 17:08 ` Stephen Warren
2013-03-04 17:08 ` Stephen Warren
[not found] ` <5134D50B.8060001-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-03-05 7:40 ` Peter De Schrijver
2013-03-05 7:40 ` Peter De Schrijver
[not found] ` <20130305074047.GH27241-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>
2013-03-05 17:00 ` Stephen Warren
2013-03-05 17:00 ` Stephen Warren
[not found] ` <513624AA.4090207-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-03-06 8:14 ` Peter De Schrijver
2013-03-06 8:14 ` Peter De Schrijver
[not found] ` <20130306081401.GN27241-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>
2013-03-06 16:18 ` Stephen Warren
2013-03-06 16:18 ` Stephen Warren
2013-03-10 17:25 ` Santosh Shilimkar
2013-03-10 17:25 ` Santosh Shilimkar
[not found] ` <513CC21E.7080901-l0cyMroinI0@public.gmane.org>
2013-03-10 18:47 ` Olof Johansson
2013-03-10 18:47 ` Olof Johansson
[not found] ` <CAOesGMgYL19+u-bLp080iasct5xtC=qfNCoz=SY7bbVgF=7JQg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-03-11 16:59 ` Stephen Warren
2013-03-11 16:59 ` Stephen Warren
2013-03-11 18:54 ` Jason Gunthorpe
2013-03-11 18:54 ` Jason Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=512CF87A.4090404@wwwdotorg.org \
--to=swarren-3lzwwm7+weoh9zmkesr00q@public.gmane.org \
--cc=arnd-r2nGTMty4D4@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org \
--cc=rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.