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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 15 May 2024 09:51:32 +0200
From: Jens Wiklander <jens.wiklander@...aro.org>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: linux-kernel@...r.kernel.org, linux-mmc@...r.kernel.org, 
	op-tee@...ts.trustedfirmware.org, 
	Shyam Saini <shyamsaini@...ux.microsoft.com>, Ulf Hansson <ulf.hansson@...aro.org>, 
	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>, 
	Tomas Winkler <tomas.winkler@...el.com>, Alex Bennée <alex.bennee@...aro.org>
Subject: Re: [PATCH v6 1/3] rpmb: add Replay Protected Memory Block (RPMB) subsystem

On Tue, May 14, 2024 at 5:45 PM Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
>
> On Tue, May 07, 2024 at 11:16:17AM +0200, Jens Wiklander wrote:
> > A number of storage technologies support a specialised hardware
> > partition designed to be resistant to replay attacks. The underlying
> > HW protocols differ but the operations are common. The RPMB partition
> > cannot be accessed via standard block layer, but by a set of specific
> > RPMB commands. Such a partition provides authenticated and replay
> > protected access, hence suitable as a secure storage.
> >
> > The initial aim of this patch is to provide a simple RPMB driver
> > interface which can be accessed by the optee driver to facilitate early
> > RPMB access to OP-TEE OS (secure OS) during the boot time.
> >
> > A TEE device driver can claim the RPMB interface, for example, via
> > rpmb_interface_register() or rpmb_dev_find_device(). The RPMB driver
> > provides a callback to route RPMB frames to the RPMB device accessible
> > via rpmb_route_frames().
> >
> > The detailed operation of implementing the access is left to the TEE
> > device driver itself.
> >
> > Signed-off-by: Tomas Winkler <tomas.winkler@...el.com>
> > Signed-off-by: Alex Bennée <alex.bennee@...aro.org>
> > Signed-off-by: Shyam Saini <shyamsaini@...ux.microsoft.com>
> > Signed-off-by: Jens Wiklander <jens.wiklander@...aro.org>
> > Reviewed-by: Linus Walleij <linus.walleij@...aro.org>
> > ---
> >  MAINTAINERS              |   7 ++
> >  drivers/misc/Kconfig     |  10 ++
> >  drivers/misc/Makefile    |   1 +
> >  drivers/misc/rpmb-core.c | 233 +++++++++++++++++++++++++++++++++++++++
> >  include/linux/rpmb.h     | 136 +++++++++++++++++++++++
> >  5 files changed, 387 insertions(+)
> >  create mode 100644 drivers/misc/rpmb-core.c
> >  create mode 100644 include/linux/rpmb.h
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 8999497011a2..e83152c42499 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -19012,6 +19012,13 @@ T:   git git://linuxtv.org/media_tree.git
> >  F:   Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-de2-rotate.yaml
> >  F:   drivers/media/platform/sunxi/sun8i-rotate/
> >
> > +RPMB SUBSYSTEM
> > +M:   Jens Wiklander <jens.wiklander@...aro.org>
> > +L:   linux-kernel@...r.kernel.org
> > +S:   Supported
> > +F:   drivers/misc/rpmb-core.c
> > +F:   include/linux/rpmb.h
> > +
> >  RPMSG TTY DRIVER
> >  M:   Arnaud Pouliquen <arnaud.pouliquen@...s.st.com>
> >  L:   linux-remoteproc@...r.kernel.org
> > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > index 4fb291f0bf7c..dbff9e8c3a03 100644
> > --- a/drivers/misc/Kconfig
> > +++ b/drivers/misc/Kconfig
> > @@ -104,6 +104,16 @@ config PHANTOM
> >         If you choose to build module, its name will be phantom. If unsure,
> >         say N here.
> >
> > +config RPMB
> > +     tristate "RPMB partition interface"
> > +     depends on MMC
> > +     help
> > +       Unified RPMB unit interface for RPMB capable devices such as eMMC and
> > +       UFS. Provides interface for in-kernel security controllers to access
> > +       RPMB unit.
> > +
> > +       If unsure, select N.
> > +
> >  config TIFM_CORE
> >       tristate "TI Flash Media interface support"
> >       depends on PCI
> > diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> > index ea6ea5bbbc9c..8af058ad1df4 100644
> > --- a/drivers/misc/Makefile
> > +++ b/drivers/misc/Makefile
> > @@ -15,6 +15,7 @@ obj-$(CONFIG_LKDTM)         += lkdtm/
> >  obj-$(CONFIG_TIFM_CORE)              += tifm_core.o
> >  obj-$(CONFIG_TIFM_7XX1)              += tifm_7xx1.o
> >  obj-$(CONFIG_PHANTOM)                += phantom.o
> > +obj-$(CONFIG_RPMB)           += rpmb-core.o
> >  obj-$(CONFIG_QCOM_COINCELL)  += qcom-coincell.o
> >  obj-$(CONFIG_QCOM_FASTRPC)   += fastrpc.o
> >  obj-$(CONFIG_SENSORS_BH1770) += bh1770glc.o
> > diff --git a/drivers/misc/rpmb-core.c b/drivers/misc/rpmb-core.c
> > new file mode 100644
> > index 000000000000..e42a45debc76
> > --- /dev/null
> > +++ b/drivers/misc/rpmb-core.c
> > @@ -0,0 +1,233 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright(c) 2015 - 2019 Intel Corporation. All rights reserved.
> > + * Copyright(c) 2021 - 2024 Linaro Ltd.
> > + */
> > +#include <linux/device.h>
> > +#include <linux/init.h>
> > +#include <linux/kernel.h>
> > +#include <linux/list.h>
> > +#include <linux/module.h>
> > +#include <linux/mutex.h>
> > +#include <linux/rpmb.h>
> > +#include <linux/slab.h>
> > +
> > +static struct list_head rpmb_dev_list;
> > +static DEFINE_MUTEX(rpmb_mutex);
> > +static struct blocking_notifier_head rpmb_interface =
> > +     BLOCKING_NOTIFIER_INIT(rpmb_interface);
> > +
> > +/**
> > + * rpmb_dev_get() - increase rpmb device ref counter
> > + * @rdev: rpmb device
> > + */
> > +struct rpmb_dev *rpmb_dev_get(struct rpmb_dev *rdev)
> > +{
> > +     if (rdev)
> > +             get_device(rdev->parent_dev);
>
> Odd, why are you thinking the parent reference has anything to do with
> this device's reference?
>
> Why isn't this a "real" device and part of the driver model properly?
> This way of "hanging onto" a device and attempting to influence it's
> reference count is odd, please make this real and not "fake".

I did this in response to
https://lore.kernel.org/lkml/CAPDyKFqNhGWKm=+7niNsjXOjEJE3U=o7dRNG=JqpptUSo9G-ug@mail.gmail.com/

Perhaps "parent_dev" isn't the best name. The struct rpmb_dev can be
seen as another representation of the underlying device. The life
cycle of struct rpmb_dev is tied to the underlying device with
rpmb_dev_register() and rpmb_dev_unregister(). Just as
rpmb_route_frames() forwards the frames to the device, rpmb_dev_{get,
put}() does the corresponding thing.

>
> Bonus, you get that notifier callback "for free" if you do that.  But
> really, notifier callbacks are a pain, are you sure you want that?

Yes, they are needed because the device may show up late and the
OP-TEE driver doesn't know if any device will show up. As Ulf pointed
out in the link above, at this point, there's no need to tell user
space about this kernel internal abstraction.

Thanks,
Jens

>
> thanks,
>
> greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ