RE: [PATCH 4/5] RFC: mmc: block: Convert RPMB to a character device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

> 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

--
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




[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux