On Fri, Jun 16, 2017 at 10:22 AM, Avri Altman <Avri.Altman@xxxxxxx> wrote: > Hi, > >> -----Original Message----- >> From: Linus Walleij [mailto:linus.walleij@xxxxxxxxxx] >> Sent: Thursday, June 15, 2017 3:13 PM >> To: linux-mmc@xxxxxxxxxxxxxxx; Ulf Hansson <ulf.hansson@xxxxxxxxxx> >> Cc: linux-block@xxxxxxxxxxxxxxx; Jens Axboe <axboe@xxxxxxxxx>; Christoph >> Hellwig <hch@xxxxxx>; Arnd Bergmann <arnd@xxxxxxxx>; Bartlomiej >> Zolnierkiewicz <b.zolnierkie@xxxxxxxxxxx>; Paolo Valente >> <paolo.valente@xxxxxxxxxx>; Avri Altman <Avri.Altman@xxxxxxx>; Adrian >> Hunter <adrian.hunter@xxxxxxxxx>; Linus Walleij <linus.walleij@xxxxxxxxxx> >> Subject: [PATCH 4/5] RFC: mmc: block: Convert RPMB to a character device >> >> The RPMB partition on the eMMC devices is a special area used for storing >> cryptographically safe information signed by a special secret key. To write >> and read records from this special area, authentication is needed. >> >> The RPMB area is *only* and *exclusively* accessed using ioctl():s from >> userspace. It is not really a block device, as blocks cannot be read or written >> from the device, also the signed chunks that can be stored on the RPMB are >> actually >> 256 bytes, not 512 making a block device a real bad fit. >> >> Currently the RPMB partition spawns a separate block device named >> /dev/mmcblkNrpmb for each device with an RPMB partition, including the >> creation of a block queue with its own kernel thread and all overhead >> associated with this. On the Ux500 >> HREFv60 platform, for example, the two eMMCs means that two block >> queues with separate threads are created for no use whatsoever. >> >> I have concluded that this block device design for RPMB is actually pretty >> wrong. The RPMB area should have been designed to be accessed from >> /dev/mmcblkN directly, using ioctl()s on the main block device. It is however >> way too late to change that, since userspace expects to open an RPMB >> device in /dev/mmcblkNrpmb and we cannot break userspace. >> > Not sure how much you are bound by this. > Previous attempts, adopting a pragmatic approach - just added another ioctl number, and used /dev/mmcblkN. > Moreover, a designated ioctl allows to address more cleanly the rpmb-specific needs, that are somehow awkward using multi_cmd. > Within the context of an RFC, would be interesting to know if someone even used /dev/mmcblkNrpmb? Good question, need to look for TrustyOS and OP-TEE. > >> Some discussion points: >> >> I am aware of Tomas Winklers attempts to make RPMB handling into its own >> subsystem. I have no such ambitions whatsoever, I am only trying to sensibly >> accomodate what we already have and handle our RPMB in a way that is not >> littering the place with weirdo block devices. > > I think that the key benefit of Tomas's approach, is being so comprehensive. > Thus enables pmb access of embedded block devices - mmc as well as other. My approach came from actual use case, but we cannot probably break already working software. > Cheers, > Avri > Thanks Tomas -- 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
