Messages in this thread | | | Date | Wed, 10 Sep 2014 11:09:59 -0700 | Subject | Re: [PATCH] clocksource: arch_timer: Fix code to use physical timers when requested | From | Doug Anderson <> |
| |
Will,
On Wed, Sep 10, 2014 at 10:34 AM, Will Deacon <will.deacon@arm.com> wrote: > 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.
Hrm. I could have sworn someone told me that exynos5250-snow is booted in Secure SVC mode and has been that way forever. I could certainly be wrong. Stupid question, but should any of your statements apply to an A15 or an A12? Maybe things change with newer CPUs?
On the rk3288 I have in front of me I tried running the following at (semi early) boot to help confirm we were in Secure SVC. Standard "I don't know what I'm doing" caveats apply:
asm volatile("mrc p15, 0, %0, c1, c1, 0" : "=r" (val)); pr_info("DOUG: val is %#010x", val); val |= (1 << 2); asm volatile("mcr p15, 0, %0, c1, c1, 0" : : "r" (val)); val = 0xffffffff; asm volatile("mrc p15, 0, %0, c1, c1, 0" : "=r" (val)); pr_info("DOUG: val is %#010x", val);
When I did that I found that I was able to read back 0x00000004. OK, and I just replicated that same behavior on exynos5250-snow.
Since I think the SCR register is only accessible from "Secure PL1 modes" and I showed that I could change it, to me that meant that I must be in "Secure PL1". Please yell if I'm just being an idiot and I can look for some other way to test for secure mode.
Also: I wasn't actually suggesting running Linux in secure mode, I was only suggesting _booting_ Linux in secure mode. The idea was that Linux would realize this and immediately switch to nonsecure HYP mode. Linux doesn't normally run at HYP mode, so it would eventually drop down into nonsecure SVC mode, too.
One (admittedly weak) justification was that if someone later wanted to do some whizbang feature in the Linux kernel that required "secure svc" mode then it would be possible on this hardware. Obviously this person would need to implement a whole crapload of code to handle this, but they wouldn't need to add custom firmware.
The other (important) justification was to keep bootloaders simple. All of the "I've never even thought about secure mode" bootloaders that I've seen just happen to boot the kernel in Secure SVC. That makes me think that must be the easiest thing for them to do. We should support them.
> 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.
See above and also my summary to Mark Rutland. I don't think your statement above is quite where we're at, but hopefully we're on the same page now. :)
-Doug
| |