On Tue, 28 Feb 2017 09:16:11 +0000 Andre Przywara <[email protected]> wrote:
> 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. OK, that's fine. And since I need this patch myself, I went ahead, mutilated your patch and submitted a pull request: https://github.com/linux-sunxi/sunxi-tools/pull/99 -- 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.
