linux-kernel - Re: [PATCH] clocksource: arch_timer: Fix code to use physical timers when requested

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: <20140908135436.GC22717@arm.com>
Date:	Mon, 8 Sep 2014 14:54:36 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Doug Anderson <dianders@...omium.org>
Cc:	Mark Rutland <Mark.Rutland@....com>,
	Olof Johansson <olof@...om.net>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Sonny Rao <sonnyrao@...omium.org>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>,
	Russell King <linux@....linux.org.uk>,
	Sudeep Holla <Sudeep.Holla@....com>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Will Deacon <Will.Deacon@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] clocksource: arch_timer: Fix code to use physical timers
 when requested

On Fri, Sep 05, 2014 at 11:11:47PM +0100, Doug Anderson wrote:
> On Thu, Aug 28, 2014 at 2:35 AM, Mark Rutland <mark.rutland@....com> wrote:
> > Not if you boot Linux at hyp, as we've recommended for this precise
> > reason. That doesn't fix other things like CNTFRQ if the secure
> > initialisation doesn't poke that, however.
> 
> I'll freely admit that I'm out of my league and out of my comfort zone
> here, but...
> 
> In the theory that firmware ought to be as minimal as possible
> (because it's hard to update and hard to keep in sync with kernel
> versions), it seems like firmware ought to start the kernel out in as
> permissive mode as it's willing to provide, right?

Not necessarily (and definitely not for arm64). And we've seen in
practice that the actual deployed kernel may run in a different security
mode than what's in mainline and used for initial development (you may
just not see all the patches upstream). For development, that's indeed
simpler, but once you go into production, a customer requesting some
secure OS for payments etc. and Linux is moved to the non-secure side
(and you end up putting hacks in the kernel because they were not
spotted during initial development with Linux running in secure mode).

> If the kernel is started out as permissive as possible then it can do
> anything it needs to.  Future versions of the kernel can be
> implemented to do any way-cool things that they want to do without an
> update to firmware, right?  ...and current versions of the kernel can
> just shed permissions if they don't want them.
> 
> ...so if I understand correctly, "Secure SVC" mode is more permissive
> than "Non Secure HYP" mode, right?  It looks to me as if we currently
> start the kernel in "Secure SVC" mode.  What do you think about the
> kernel detecting Secure SVC and then dropping down permission levels
> (to Non Secure HYP).  Once it did this, it could update things like
> the virtual offset and then transition down further into non-secure
> SVC mode.

If we talk about ARMv8/AArch64, Secure SVC (aka secure EL1) is not more
permissive than Non-secure Hyp (aka non-secure EL2). The only way to go
from secure EL1 to non-secure EL2 is via EL3 (and SMC call) which means
firmware code. Certain registers like CNTFRQ are only writable in EL3,
CNTVOFF in EL2 or EL3.

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