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]

 



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



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

  Powered by Linux