On Sat, 7 Sep 2013, Catalin Marinas wrote:
On 6 Sep 2013, at 20:52, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Fri, 6 Sep 2013, Catalin Marinas wrote:
On Fri, Sep 06, 2013 at 02:50:45AM +0100, Nicolas Pitre wrote:
I understand the issue with having a secure OS that needs to protect itself from the nasty Linux world. However, if I understand the model right, the secure OS is there to provide special services to the non-secure OS and not the reverse. Therefore the secure OS should simply pack and hide its things when told to do so, right?
The problem is when it is *not* told to do so.
Well, just halt the whole system in that case. Or raise a fault if you want to be nice.
I don't think you got my point. How to force the halting of the whole system when the non-secure OS controls what to halt? It controls which CPUs to halt, when to disable cluster coherency. This is normally for good reasons like power management but a malicious non-secure OS may also use these to cause data corruption on the secure side (with various consequences, it allows options for attack).
What I meant is:
- Secure OS traps on any attempt from the non secure OS to disable coherency or halt CPUs while it is active.
- Non-secure OS wants to do some power management so it tells secure OS to pack its things and remove its hands from the hardware controls.
- While non-secure OS has control over the hardware knobs, secure OS refuses to operate.
- Non-secure OS tells secure OS to come back. Secure OS reinstates its watch guard on the hardware control knobs.
- If non-secure OS attempts to touch the hardware knobs without telling secure OS to get away first, secure OS takes offence and either hangs the system or signals a fault.
If you want the secure side to detect what the non-secure OS tries to halt, you don't allow non-secure access to certain peripherals like CCI, power controller, DCSCB etc.
As I say above. But...
At this point the only option is do it in firmware.
What I'm saying is that there could be another option i.e. telling secure OS to lie down and give non-secure OS control over the hardware knobs until non-secure OS asks secure OS to come back into service.
You still want the power decision (policy) to happen in the non-secure OS but with the actual hardware access in firmware.
That's where things get murky. The policy comes as a result of last man determination, etc. In other words, the policy is not only about "I want to save power now". It is also "what kind of power saving I can aford now". And that's basically what MCPM does. With an abstract interface such as PSCI, that policy decision is moved into firmware.
same malicious use-case reasons, the firmware cannot afford to rely on the non-secure OS to prevent "last man" races.
Again, by the time non-secure OS attempts to determine the last man, it should have told the secure OS to take cover.
This is like memory protection in user space: if you don't ask the kernel for extra memory before touching it, you get killed. But the kernel doesn't interfere with user space for the managing of that memory beyond giving it blank pages.
I don't think I understand the analogy. If I got it right, it's more like allowing user space to get its memory without trapping into the kernel.
I hope my explanation above clears up this analogy now.
Shifting the privilege levels down, a better analogy would be user application (non-root since root has a special 'trusted' status in Linux) able to control coherency and CPU/cluster shutdown *without* having to do system calls. Would you feel comfortable with this?
Let me propose a counter-example: with PSCI and the power management in secure firmware is like having the GNOME Power Manager compiled into the kernel. It would work of course, but maybe the GNOME developers would prefer dealing with it in user space instead without having to update the kernel when there is a bug in the Power Manager.
The only workaround is not to trust things controlled from outside that privilege levels, in such case coherency. This pretty much means UP only.
And why is that a problem? Certainly the secure OS shouldn't need to be that CPU hungry, just like the Linux kernel is not supposed to take away too much CPU cycles from user space.
As I said, the secure OS model should imply veto power only, not executive power. That ought to be sufficient. The non-secure world can learn to inform the secure OS of its intent.
The veto power can only be imposed by blocking access to devices controlling coherency/shutdown. That's the only way you can safely 'teach' the non-secure OS to inform the secure OS about it.
That's what I say above.
It depends on how you start. If you wait to see how many patterns appear and later try to unify them you need a lot more men power. The aim here is to try to provide rules and only relax the rules when there are valid reasons (sorry but not trusting the secure firmware doesn't look to me like a valid one).
It's not about mistrust. It is about proper software complexity maintenance.
Nicolas