Hi, > -----Original Message----- > From: Linus Walleij [mailto:[email protected]] > Sent: Thursday, June 15, 2017 3:13 PM > To: [email protected]; Ulf Hansson <[email protected]> > Cc: [email protected]; Jens Axboe <[email protected]>; Christoph > Hellwig <[email protected]>; Arnd Bergmann <[email protected]>; Bartlomiej > Zolnierkiewicz <[email protected]>; Paolo Valente > <[email protected]>; Avri Altman <[email protected]>; Adrian > Hunter <[email protected]>; Linus Walleij <[email protected]> > 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?
> 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. Cheers, Avri
