On Fri, 6 Sep 2013, Charles Garcia-Tobin wrote:
[snip]
And this is not my call to make either. System vendors will choose their own poison for themselves. Between risk inducing complexity in secure firmware and non-standard low-level machine specific L3 calls I don't think there is much to rejoice about.
But my point is that there is legitimacy in both models and right now I don't see a single "true" solution. Hence my claim that you should not insist on PSCI or nothing.
My main problem is that I only see MCPM being legitimate in a system where linux runs in secure world. Here all the coherency/cache management, and by consequence last man tracking etc, can be done happily in Linux. However if you are going to productise a device, and consequently run linux non-secure then you need PSCI.
Let's assume that you need a secure firmware. Whether it is PSCI or not is inconsequential for the current discussion. Obviously, if you are going to have a secure firmware then you may as well use a standard interface definition like PSCI of course. But that is not my point.
As pointed out before in this thread, you can't disable coherency from linux or ignore secure cache maintenance. If you go with MCPM you end up in a situation where folk will do bring up using that, ignore sorting out their FW, and then end up either asking for obscure, very platform specific ways back doors into the secure world like we have today.
But "sorting out FW" is a damn hard thing to do.
If MCPM is not in the kernel, something equivalent has to be implemented in the firmware. There is no way around that.
I'll let other judge my own abilities, but I can say that the other two ARM guys who worked on MCPM are very smart. Yet it took us about 6 months to get MCPM right on TC2. And we did introduce a few screw-ups that weren't caught by formal testing along the way. Fortunately for us we had only the kernel to update in order to fix things.
Wishful thinking doesn't work in software development. Shit happens all the time despite formal testing, only because the tests might themselves be buggy. Therefore proper engineering practices dictate that you *must* keep your hard-to-replace firmware as simple and obvious as possible otherwise you're typically stuck with its bugs for a long long time. The issue with the TC2 M3 firmware I highlighted earlier seems to be an example of that.
So what do many engineers do? They try to lower the risk by transferring complexity where it is less costly to fix after the facts i.e. in the kernel. And quite often that means very platform specific back doors into the secure world. Those back doors are significantly easier to implement and validate, with a better probability to get right on the first try.
This will obviate the whole point of PSCI, and the whole effort. If you go with PSCI you'd encourage a model where folk do it properly from the start.
A good software model should not pull complexity out of the kernel to move it into secure firmware. Will the IP stack be moved to the secure OS next... because we need "secure" networking? That's simply an engineering non-sense.
And maybe the whole secure world architecture is to blame for that. Having to delegate tasks to the secure firmware like cache maintenance for the non secure world that have nothing to do with secure services per se because the hardware cannot on its own ensure the integrity of the secure world otherwise is insane. The secure OS should provide services only. It certainly shouldn't be in the complex and subtle power management business at all. There is certainly something to reconsider on the hardware side here.
As a compromise the secure OS could veto some operations while it is active and relinquish that power when told to lie down. But I suspect that also requires hardware support to do properly.
I can understand the need for flexibility, so having a system which ultimately always calls PSCI, but which allows a SoC callback in the path (which is essentially the option 5 above) makes sense to me. This model encourages adoption of PSCI, but gives the flexibility for early adoption and provides a development path.
Again I don't mind PSCI in some cases. It is especially nice for virtual environments where the hardware _has_ to be abstracted anyway.
But the idea of trying to abstract as much hardware controls behind firmware as possible is wrong. Software has bugs, and hardware has bugs too. The kernel must have the ability to adapt to that during the life cycle of a product, and implement more efficient handling of that hardware with time.
Finally I just don't think we should use the "FW has been crap in the past" card as way to discourage FW for ever more. That's not the right answer, there are valid uses for it and a whole industry around it.
Obviously. If you are in the business of writing firmware code, I'm sure you are full of hatred for me at the moment and wish I'd shut up. I'll continue to assert that firmware should always be kept as simple, obvious and unobtrusive as possible nevertheless. While there are valid uses for firmware, there are too many misguided uses as well.
The second best option is to make the demonstration that firmware is actually easy to audit, and easy to fix and upgrade when real life usage in the field shows it is flawed. And there must be recommendations and mechanisms to ensure that actually happens in a timely manner. Unfortunately I'm not seeing any effort in that direction so far, nor even anyone wishing to assume the extra costs implied by this.
absolutely agree with using the card to encourage better development of FW in the future. Standardised APIs is part of that story.
If we're stuck with firmware then yes: we do need Standardized APIs indeed. Bad firmware with a good interface is certainly better than bad firmware with a bad interface.
But more complex firmware is not a good solution from an engineering point of view. This is why, despite the great efforts deployed by ARM and yourself in particular on PSCI, some people will opt to keep their firmware to a minimum and keep as much control into the cheaply updateable kernel instead.
Nicolas