On Tue, Sep 10, 2013 at 08:07:17PM +0100, Nicolas Pitre wrote:
On Tue, 10 Sep 2013, Catalin Marinas wrote:
I hope it is clear by now that if you care about _proper_ security in the power management context, point 3 above must be handled in firmware. That's independent of how complex the firmware needs to be for such task. PSCI as an API and the Generic Firmware implementation is addressing this (and at the same time providing a common framework for secure OS vendors to rely on). Generic Firmware will be further developed to address other concerns but that's not the point.
Indeed it is the point! And as I keep repeating this over and over in various ways because there is no one who is addressing my very concern so far:
It's not hard to understand: the generic firmware is *not* public yet. You will be able review it and discuss your concerns at the right time.
I *do* appreciate the complexities of MCPM but that doesn't make it write once only (it's not even software only, part of the state coordination may be handled in hardware). But the experience gained from developing it is definitely not lost.
We clearly have a different understanding of the ARM security model and I've already gone to great lengths explaining it. I won't go over those arguments again, you seem to have ignored them so far.
The decision for adopting the ARM generic firmware or other firmware lies entirely with the ARMv8 SoC vendors and they should know better what their security needs are (or will be). It's not the role of the Linux community to mandate certain firmware. However, we *do* have the right to mandate certain standards like booting protocols, DT, ACPI etc. for code aimed to be included in mainline.
Linux interaction with the firmware is another area which badly needs standardisation, whether it is secure firmware or not, simply because that's the first code a CPU executes when out of reset. Such standardisation is even more important in the presence of secure firmware (and given that AArch64 is new, companies will have to write new firmware and there is little legacy to carry).
The first interaction with firmware (EL3 or not, boot loader) is the booting protocol (primary and secondary CPUs). This is defined by Documentation/arm64/booting.txt and will also cover PSCI. It can be extended to other protocols in the future as long as they follow simple rules:
- Existing protocols are not feasible/sufficient (with good arguments, EFI_STUB for example) - There are no SoC or CPU implementation specific quirks required before the FDT is parsed and the (secondary) CPUs enabled the MMU. IOW: - caches and TLBs clean&invalidated - full CPU/cluster coherency enabled - errata workaround bits set
Power management is not covered by the above document, though there is a relation between secondary CPU booting and hotplug. To be clear, as the arm64 kernel _gatekeeper_ I set the basic rules for ARMv8 SoC power management code aimed for mainline (I'll capture them in a soc.txt document):
- If EL3 is present, standard EL3 firmware interface required - New EL3 interface can be accepted if the existing interfaces are not feasible (with good arguments, it is properly documented and widely accepted) - CPUs coming out of power down or idle need to be have all the SoC or implementation specific quirks enabled: - caches and TLBs clean & invalidated - coherency enabled - errata workaround bits set
ARM provides PSCI as such standard API in the presence of EL3 but I'm _open_ to other _well-thought_ firmware API proposals that can gain wider acceptance. Hint: Linaro is a good forum for wider SoC vendor and Linux community discussions, I would expect concrete proposals rather than complains. (BTW, my impression from the last Connect was that LEG is adopting PSCI for the ACPI work)
Note that the above rules don't have anything to do with MCPM. That's a SoC power driver implementation detail (and I already suggested turning it into a library if needed to avoid duplication). But the above firmware API rules still apply and if PSCI is present you have the advantage of generic support in Linux.
(as a side note, generalising your TC2 MMC experience to _any_ firmware is unprofessional IMHO. You keep repeating it and to me starts sounding like FUD)