On Wed, Sep 10, 2014 at 06:17:23PM +0100, Doug Anderson wrote:

On Mon, Sep 8, 2014 at 6:54 AM, Catalin Marinas [off-list ref] wrote:

quoted

On Fri, Sep 05, 2014 at 11:11:47PM +0100, Doug Anderson wrote:

quoted

On Thu, Aug 28, 2014 at 2:35 AM, Mark Rutland [off-list ref] wrote:

quoted

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).

I guess the important part of my statement is "as it's willing to
provide".  In your case your firmware isn't willing to provide "secure
SVC".  In our case it is.

We've actually shipped products where the firmware boots the kernel in
"secure" mode.  These products have a very different security model
than you're envisioning, I guess.  In these products, less firmware is
better and adding firmware code to do the whole transition to "non
secure hyp mode" just isn't worth it.  It's not just a one-time blob
of code in the firmware before booting the kernel.  (I'm told) it
means somehow keeping firmware code around to help out with turning
processors off/on and to help with resume from S3.  That's
infrastructure that we don't want to add.

Setting aside the security model, booting in secure mode can also have a
significant impact on the programming model of system IP, not just the CPU.
For example, the SMMU register file suddenly looks different and the way in
which it is programmed also changes. The GIC (v3+) is similar. Linux doesn't
have drivers that know about this so, whilst not impossible, there's a
non-trivial amount of work (and then maintenance overhead) if you want to
support booting Linux on the secure side.

The secure world may be more permissive in some regards, but it's actually
a burden in others. It's not a simple superset of non-secure, and this is
more evident than ever in ARMv8.

As I understand it, this conversation started because we're booting at
non-secure EL1 with a badly configured EL2. That sounds like something
we may have to fix/work around in Linux (Olof points out that it used to
work), but we shouldn't conflate that with booting on the secure side to
get away from broken firmware.

Will