linux-kernel - Re: [PATCH v7 1/5] ARM: add basic support for Trusted Foundations

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:	Thu, 10 Oct 2013 16:22:06 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Alexandre Courbot <gnurou@...il.com>,
	Olof Johansson <olof@...om.net>
CC:	Alexandre Courbot <acourbot@...dia.com>,
	Russell King <linux@....linux.org.uk>,
	Tomasz Figa <t.figa@...sung.com>,
	Dave Martin <Dave.Martin@....com>,
	Arnd Bergmann <arnd@...db.de>,
	Kevin Hilman <khilman@...aro.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v7 1/5] ARM: add basic support for Trusted Foundations

On 10/10/2013 02:58 PM, Alexandre Courbot wrote:
> On Wed, Oct 9, 2013 at 4:47 PM, Olof Johansson <olof@...om.net> wrote:
>> On Fri, Oct 4, 2013 at 9:37 AM, Alexandre Courbot <acourbot@...dia.com> wrote:
...
>> But do we really need to panic here? It's a PITA to debug since it'll
>> be a very early panic. I'd rather have the system log errors in dmesg
>> but continue booting with one cpu.
> 
> Actually the first version of this series continued on one CPU if TF
> support was missing (as secondary CPUs would simply fail to boot), but
> IIRC Stephen advocated for the current behavior (panic) instead. I
> agree such an early panic is hard to debug, especially considering
> that most devices using TF (Tegra retail devices) do not even feature
> a serial port.
> 
> On the other hand, if we continue booting in these conditions the
> system freezes as soon as cpuidle kicks in, so we won't be going very
> far anyway. However the console is up when it happens.
> 
> Maybe if there is a way to disable the kernel features TF is supposed
> to manage (SMP & cpuidle at the moment) when registration fails, the
> system could continue more gracefully (even if on one leg) and warn
> the user about this condition. Stephen, can I have your thoughts on
> this?

If we can disable the features that rely on TF/secure-mode when support
is missing, then doing that rather than panic is fine. We do something
similar for PCIe on Tegra20, where LP2 cpuidle state must be disabled or
PCIe interrupts won't work.

I would be inclined to merge the patch as-is right now, since it's only
enabling a new feature that won't see any regressions due to this panic,
and then add the disable-other-features with a separate patch/series
later. Does that seem reasonable?
--
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/