On Mon, 29 Mar 2021 at 15:23, Ard Biesheuvel <a...@kernel.org> wrote:
> On Fri, 26 Mar 2021 at 19:36, Heinrich Schuchardt <xypron.g...@gmx.de> > wrote: > > > > On 26.03.21 15:12, François Ozog wrote: > > > Hi > > > > > > Trusted Firmware M recently introduced protection against glitching at > > > key decision points: > > > https://github.com/mcu-tools/mcuboot/pull/776 > > > > > > To me this is a key mitigation element for companies that target PSA > > > level 3 compliance which means hardware attacks resilience. > > > > > > I believe similar techniques need to be used in different projects > > > involved in Linux secure booting (TF-A, OP-TEE, U-Boot, Linux kernel). > > > > Power glitches can induce changes in data, in code, and in CPU state. > > Signing selected variables cannot be a sufficient counter-measure. > > > > If you want to protect against power glitches, it seems more promising > > to do so on the hardware side, e.g. > > > > * provide circuitry that resets the board if a power-glitch or an > > electromagnetic interference is detected > > * use ECC RAM > > > > Of course it is more promising to do this on the hardware side, nobody > is debating that. Whether it makes sense to harden the software as > well is completely orthogonal to that: on hardened hardware, it adds > another layer of protection, and on hardware that cannot be hardened > for some reason (cost, or more often, the fact that it has already > shipped), it adds a layer of protection where no protection whatsoever > was available beforehand. > > However, I do share some of your skepticism: incorporation of these > techniques is not trivial, and commoditizing it by dropping it into > some library that you can link your software against is *not* what I > would prefer to see. This only encourages a check the box mentality, > where people either assume that having the library makes everything > magically secure, or ($DEITY forbid), it gets sucked into the MISRAs > or FIPSes of this world, and it becomes a certification requirement, > and using the library is mandatory, regardless of whether there is a > point to it, or whether it is being used in the right way. > > So I'd be more interested in seeing how the underlying methods can be > applied more widely, and not how it gets shrinkwrapped and shipped > with a .h file without any need on the part of the developer to > understand what really goes on under the hood. > > I also think this is first about guidelines with a set of helpers. For instance, lets consider: if (checkstuff(input)==0) { dostuff(); } It Can be transformed into something like (yet insufficient to be really protected but that's gives an idea, more to be read in the TFM code and readme.md) /* SUCCESS is an arbitrary value != 0 as 0 is a typical value of a register when glitched */ if (checkstuff(input, &result) == SUCCESS) { letwaitarandomdelay(); if (doublecheck_successful_result(input, result) == SUCCESS) { /* this code is not protected against PC attacks */ dostuff(); } -- > Ard. > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
