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

[Doug Anderson]

Catalin,

On Mon, Sep 8, 2014 at 6:54 AM, Catalin Marinas <catalin.marinas@xxxxxxx> wrote:
> 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@xxxxxxx> 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).

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.

To put it another way: if you're already architecting your system to
have firmware manage the secure state then everything you have said
makes sense.  You've got to solve all the problems (processor bringup,
suspend/resume, etc) anyway, so being consistent about having the
kernel in nonsecure HYP makes sense.  ...but if you have no need to
ever limit access to "secure mode" then adding a whole lot of code to
the firmware doesn't make sense to me.


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

Hmmm, I guess I was under the impression that if you were in Secure
SVC mode then you are guaranteed to have enough access that you could
control where the SMC call would go.  Thus you could install your own
SMC handler and effectively transition yourself from Secure SVC to
Monitor mode, then to Hypervisor mode.

I was also under the impression that if you were in Nonsecure HYP mode
that you couldn't guarantee that you could control the transition back
to Secure SVC mode.

If the above is incorrect then I guess my statement is incorrect.  Can
you confirm?


...however, even if "Secure SVC" isn't guaranteed to be more
permissive than "Nonsecure HYP", it is often the case that you can
transition from "Secure SVC" to "Nonsecure HYP" (by setting up
handlers, etc) because the system hasn't been locked down.  Given that
if we "do nothing" in firmware we seem to boot the kernel in Secure
SVC w/ the ability to transition to Nonsecure HYP, that seems like a
good reason for the kernel to be able to handle that switching.


-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/