| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAPDyKFpX7=DGE8ERpt4ATM2XkgfZ2Tmi+QP-ozMJ6nVmgUeMEQ@mail.gmail.com>
Date: Wed, 21 Aug 2024 16:10:28 +0200
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Jens Wiklander <jens.wiklander@...aro.org>
Cc: linux-kernel@...r.kernel.org, linux-mmc@...r.kernel.org,
op-tee@...ts.trustedfirmware.org,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Shyam Saini <shyamsaini@...ux.microsoft.com>,
Linus Walleij <linus.walleij@...aro.org>, Jerome Forissier <jerome.forissier@...aro.org>,
Sumit Garg <sumit.garg@...aro.org>, Ilias Apalodimas <ilias.apalodimas@...aro.org>,
Bart Van Assche <bvanassche@....org>, Randy Dunlap <rdunlap@...radead.org>,
Ard Biesheuvel <ardb@...nel.org>, Arnd Bergmann <arnd@...db.de>, Manuel Traut <manut@...ka.net>,
Mikko Rapeli <mikko.rapeli@...aro.org>, Tomas Winkler <tomas.winkler@...el.com>,
Alexander Usyskin <alexander.usyskin@...el.com>
Subject: Re: [PATCH v9 2/4] mmc: block: register RPMB partition with the RPMB subsystem
On Tue, 20 Aug 2024 at 16:47, Ulf Hansson <ulf.hansson@...aro.org> wrote:
>
> On Wed, 14 Aug 2024 at 17:36, Jens Wiklander <jens.wiklander@...aro.org> wrote:
> >
> > Register eMMC RPMB partition with the RPMB subsystem and provide
> > an implementation for the RPMB access operations abstracting
> > the actual multi step process.
> >
> > Add a callback to extract the needed device information at registration
> > to avoid accessing the struct mmc_card at a later stage as we're not
> > holding a reference counter for this struct.
> >
> > Taking the needed reference to md->disk in mmc_blk_alloc_rpmb_part()
> > instead of in mmc_rpmb_chrdev_open(). This is needed by the
> > route_frames() function pointer in struct rpmb_ops.
> >
> > Signed-off-by: Tomas Winkler <tomas.winkler@...el.com>
> > Signed-off-by: Alexander Usyskin <alexander.usyskin@...el.com>
> > Signed-off-by: Jens Wiklander <jens.wiklander@...aro.org>
> > Tested-by: Manuel Traut <manut@...ka.net>
> > Reviewed-by: Linus Walleij <linus.walleij@...aro.org>
>
> First of all, sorry for the long delay! Besides only one comment, see
> more below, this looks good to me.
>
> > ---
> > drivers/mmc/core/block.c | 242 ++++++++++++++++++++++++++++++++++++++-
> > 1 file changed, 240 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
> > index 2c9963248fcb..cc7318089cf2 100644
> > --- a/drivers/mmc/core/block.c
> > +++ b/drivers/mmc/core/block.c
> > @@ -33,6 +33,7 @@
> > #include <linux/cdev.h>
> > #include <linux/mutex.h>
> > #include <linux/scatterlist.h>
> > +#include <linux/string.h>
> > #include <linux/string_helpers.h>
> > #include <linux/delay.h>
> > #include <linux/capability.h>
> > @@ -40,6 +41,7 @@
> > #include <linux/pm_runtime.h>
> > #include <linux/idr.h>
> > #include <linux/debugfs.h>
> > +#include <linux/rpmb.h>
> >
> > #include <linux/mmc/ioctl.h>
> > #include <linux/mmc/card.h>
> > @@ -76,6 +78,48 @@ MODULE_ALIAS("mmc:block");
> > #define MMC_EXTRACT_INDEX_FROM_ARG(x) ((x & 0x00FF0000) >> 16)
> > #define MMC_EXTRACT_VALUE_FROM_ARG(x) ((x & 0x0000FF00) >> 8)
> >
> > +/**
> > + * struct rpmb_frame - rpmb frame as defined by eMMC 5.1 (JESD84-B51)
> > + *
> > + * @stuff : stuff bytes
> > + * @key_mac : The authentication key or the message authentication
> > + * code (MAC) depending on the request/response type.
> > + * The MAC will be delivered in the last (or the only)
> > + * block of data.
> > + * @data : Data to be written or read by signed access.
> > + * @nonce : Random number generated by the host for the requests
> > + * and copied to the response by the RPMB engine.
> > + * @write_counter: Counter value for the total amount of the successful
> > + * authenticated data write requests made by the host.
> > + * @addr : Address of the data to be programmed to or read
> > + * from the RPMB. Address is the serial number of
> > + * the accessed block (half sector 256B).
> > + * @block_count : Number of blocks (half sectors, 256B) requested to be
> > + * read/programmed.
> > + * @result : Includes information about the status of the write counter
> > + * (valid, expired) and result of the access made to the RPMB.
> > + * @req_resp : Defines the type of request and response to/from the memory.
> > + *
> > + * The stuff bytes and big-endian properties are modeled to fit to the spec.
> > + */
> > +struct rpmb_frame {
> > + u8 stuff[196];
> > + u8 key_mac[32];
> > + u8 data[256];
> > + u8 nonce[16];
> > + __be32 write_counter;
> > + __be16 addr;
> > + __be16 block_count;
> > + __be16 result;
> > + __be16 req_resp;
> > +} __packed;
> > +
> > +#define RPMB_PROGRAM_KEY 0x1 /* Program RPMB Authentication Key */
> > +#define RPMB_GET_WRITE_COUNTER 0x2 /* Read RPMB write counter */
> > +#define RPMB_WRITE_DATA 0x3 /* Write data to RPMB partition */
> > +#define RPMB_READ_DATA 0x4 /* Read data from RPMB partition */
> > +#define RPMB_RESULT_READ 0x5 /* Read result request (Internal) */
> > +
> > static DEFINE_MUTEX(block_mutex);
> >
> > /*
> > @@ -155,6 +199,7 @@ static const struct bus_type mmc_rpmb_bus_type = {
> > * @id: unique device ID number
> > * @part_index: partition index (0 on first)
> > * @md: parent MMC block device
> > + * @rdev: registered RPMB device
> > * @node: list item, so we can put this device on a list
> > */
> > struct mmc_rpmb_data {
> > @@ -163,6 +208,7 @@ struct mmc_rpmb_data {
> > int id;
> > unsigned int part_index;
> > struct mmc_blk_data *md;
> > + struct rpmb_dev *rdev;
> > struct list_head node;
> > };
> >
> > @@ -2670,7 +2716,6 @@ static int mmc_rpmb_chrdev_open(struct inode *inode, struct file *filp)
> >
> > get_device(&rpmb->dev);
> > filp->private_data = rpmb;
> > - mmc_blk_get(rpmb->md->disk);
>
> If I understand correctly, the call to mmc_blk_get() is here to
> reference count the usage of the md->disk. So when a user decides to
> open the chrdev, we are keeping a reference to the corresponding data
> around, until the corresponding file descriptor is closed and
> mmc_rpmb_chrdev_release() is called. We do the similar thing if the
> regular mmc block device is opened.
>
> If we change to increase/decrease the reference count from
> mmc_blk_alloc_rpmb_part()/mmc_blk_rpmb_device_release() instead - are
> you certain that we are still taking care of the above scenario
> correctly?
>
> I guess a test that opens the chrdev and then unbinding the mmc host
> driver should tell us. :-)
>From your nice little debugging session conveyed to me offlist, you
have convinced me that this is perfectly okay.
Therefore, please add:
Reviewed-by: Ulf Hansson <ulf.hansson@...aro.org>
Kind regards
Uffe
Powered by blists - more mailing lists