On Mon, Apr 4, 2016 at 4:50 AM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > > On 2 April 2016 at 02:23, Gwendal Grignou <gwendal@xxxxxxxxxxxx> wrote: > > On Thu, Jan 14, 2016 at 5:16 AM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > >> On 28 December 2015 at 15:12, Alex Lemberg <Alex.Lemberg@xxxxxxxxxxx> wrote: > > > I am arriving after the battle, but I have finally rebased the eMMC > > FFU kernel ffu code to 4.x. It is based on what Avi and Alex have > > written. > > As stated earlier, the advantage over using MMC_MUTLI_CMD is we can > > force a reset and rescan of the card without asking the user to reboot > > their machine. > > No matter what, I think the problem is how you would *safely* deal > with the reset. Especially in the case when the eMMC already has an > mounted file system on it. Assuming the firmware is not wiping data or resizing the available space, the data in the flash is readable after the upgrade. For the host point of view, a firmware update and a reset is equivalent to a reset, that could happen during error recovery. The only change are in the cid/csd//extcsd registers the firmware may have updated. The stack has to assume these registers are not constant and can change after reset. When looking into the mmc stack, AFAICT, the code that needs to get device specifics always rely on fields that are re-generated by mmc_card_inif() (card->ext_csd, output of mmc_decode_csd()/cid(() and so on). > > > Just doing something that *might* work, isn't good enough to me. > > > Also, by only sending a firmware name over the ioctl, we can use Kees' > > work for firmware validation (https://lwn.net/Articles/605432/). > > The request_firmware() interface would indeed be good to use. Although > unless we can figure out a way on how to safely deal with reset, we > will have to live without request_firmware(). > > > To prevent downloading firmware from unknown source, we would reject > > some commands (like SWITCH with FFU_MODE) in the kernel > > MMC_IOC/MULTI_CMD ioctl handler. > > I don't follow, can you elaborate on this please. Today, an attacker with root access could break the chain of trust by writing a firmware in the eMMC that corrupts data on the fly and return infected code to the host after verification. One way is to use firmware signed by the manufacturer, a stronger approach is to enforce that the firmware is part of the root partition. To prevent a bad firmware from being downloaded, we have to make sure downloading firmware using raw single or multi commands ioctls does not work. Gwendal. > > > Kind regards > Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
