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. 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. 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.
