On Fri, Jun 16, 2017 at 10:22 AM, Avri Altman <[email protected]> wrote: > 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?
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
