Hi, On 28/02/17 03:08, Siarhei Siamashka wrote: > On Mon, 27 Feb 2017 20:55:53 +0000 > Andre Przywara <[email protected]> wrote: > >> On Mon, 27 Feb 2017 05:48:48 +0200 >> Siarhei Siamashka <[email protected]> wrote: >> >>> On Mon, 27 Feb 2017 02:22:08 +0000 >>> André Przywara <[email protected]> wrote: >>> >>>> On 27/02/17 01:20, Siarhei Siamashka wrote: >>>>> On Wed, 22 Feb 2017 17:08:47 +0000 >>>>> Andre Przywara <[email protected]> wrote: >>>>> >>>>>> If an SoC has the "secure boot" fuse burned, it will enter FEL >>>>>> mode in non-secure state, so with the SCR.NS bit set. Since in >>>>>> this mode the secure/non-secure state restrictions are actually >>>>>> observed, we suffer from several restrictions: >>>>>> - No access to the SID information (both via memory mapped and >>>>>> "register"). >>>>>> - No access to secure SRAM (SRAM A2 on H3/A64/H5). >>>>>> - No access to the secure side of the GIC, so it can't be >>>>>> configured to be accessible from non-secure world. >>>>>> - No RMR trigger on ARMv8 cores to bring the core into AArch64. >>>>>> Those limitations make a board pretty useless for many >>>>>> applications. >>>>>> >>>>>> However it has been found out that a simple "smc" call will >>>>>> immediately return from monitor mode, but with the NS bit >>>>>> cleared, so access to all secure peripherals is suddenly >>>>>> possible. >>>>>> >>>>>> Add a sunxi-fel command called "smc" which will issue exactly >>>>>> this instruction to make those boards useful in "secure boot" >>>>>> FEL mode. >>>>>> >>>>>> It should be given early in the command queue to given >>>>>> subsequent code full access to the system: >>>>>> $ ./sunxi-fel -v -p smc spl sunxi-spl.bin ... >>>>>> >>>>>> Signed-off-by: Andre Przywara <[email protected]> >>>>>> >>>>>> --- >>>>>> Hi, >>>>>> >>>>>> if that sounds vaguely useful (it definitedly is for me to get >>>>>> the Remix Mini PC started), I can follow the Github process if >>>>>> you prefer that. >>>>>> >>>>>> Cheers, >>>>>> Andre. >>>>> >>>>> Hi Andre, >>>>> >>>>> Why don't we just do this automatically without adding a new >>>>> special command? >>>>> >>>>> We are not allowed to read the SCR register for detecting this >>>>> state, right? But can we still use some other detection method? >>>>> For example, maybe try to read SID and assume that we need the >>>>> SMC workaround if it reads back as zero? >>>> >>>> Yes, indeed I was thinking about exactly that ;-) >>>> From actually using this feature I realized that its usage is error >>>> prone: non-secure boards crash on calling it, secure board just >>>> don't work without it. >>>> And indeed there is no architectural way of checking whether you are >>>> running secure or non-secure (as reading a secure-only register like >>>> NSACR or SCR will trap, which means crash in our case). >>>> >>>> So (trying to) read the SID is indeed the best workaround I came up >>>> with: If it's all zero, we are probably secure and need the smc. >>>> There is still a slight chance that the SID is all zero even on a >>>> non-secure board (I think this was the case for some older SoCs?), >>>> so maybe we need an option to suppress using this heuristic? >>> >>> At least we should report every taken action in the sunxi-fel verbose >>> log (about the SMC workaround getting applied) because it greatly >>> simplifies troubleshooting. >>> >>> And IMHO having any options to suppress this workaround is a bit >>> premature until we encounter a real A64/H64/H5 chip where it fails >>> in the wild. >>> >>> Another variant of the detection heuristics could just use SRAM A2 >>> (well, not quite "SRAM", but the OpenRISC reset vector area). I'm >>> getting the following output on my Jide Remix Mini (Allwinner H64): >>> >>> $ ./sunxi-fel readl 0x40004 >>> 0x00000000 >>> >>> $ ./sunxi-fel smc >>> >>> $ ./sunxi-fel readl 0x40004 >>> 0x15000000 >>> >>> We are either reading zero from there, or it is a hardwired OpenRISC >>> instruction L.NOP. >> >> Yeah, that sounds even better, but would be restricted to SoCs which >> have an OpenRISC. Not sure if that is actually a super set of >> secure-boot capable chips. > > There is no obligation to implement exactly the same solution for every > SoC. > >> Only thing is that we need to add the address of "secure SRAM" to the >> per-SoC data structure, but that may become useful for other purposes >> in the future as well, I guess. > > We can even implement it as a simple check with just a single address of > a word (or even byte), which needs to be compared with zero. Some SoCs > may make use of NOPs from the delay slots of the OpenRISC reset vector > in SRAM A2. The other SoCs may use their SID.
That sounds like a good solution, yes. > Once we come to an agreement, could you please submit a pull request > at github? We have travis-ci enabled there, so patches are at least > automatically compile tested (on non-Linux systems too). Yes, will do, but please don't your breath on it, as it isn't very high on my priority list at the moment. Cheers, Andre. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
