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. 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). -- Best regards, Siarhei Siamashka -- 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.
