Re: [RFC 0/6] mmc: Field Firmware Update

From: Gwendal Grignou <gwendal@chromium.org>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Gwendal Grignou <gwendal@chromium.org>,
	Alex Lemberg <Alex.Lemberg@sandisk.com>,
	Holger Schurig <holgerschurig@gmail.com>,
	Avi Shchislowski <Avi.Shchislowski@sandisk.com>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Chris Ball <chris@printf.net>,
	Baolin Wang <baolin.wang@linaro.org>
Subject: Re: [RFC 0/6] mmc: Field Firmware Update
Date: Wed, 13 Apr 2016 15:33:36 -0700	[thread overview]
Message-ID: <CAMHSBOUjGutAOXYu01rjr-SgWKkGDL7KfQALn-bgkLopBVwpOA@mail.gmail.com> (raw)
In-Reply-To: <CAPDyKFoH3=czLW5_AKcJLRZa2ptTuumiMT24PZw6zKBW38WOwQ@mail.gmail.com>

On Mon, Apr 4, 2016 at 4:50 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> On 2 April 2016 at 02:23, Gwendal Grignou <gwendal@chromium.org> wrote:
> > On Thu, Jan 14, 2016 at 5:16 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >> On 28 December 2015 at 15:12, Alex Lemberg <Alex.Lemberg@sandisk.com> 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