From: jgunthorpe@obsidianresearch.com (Jason Gunthorpe)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 3/5] tee: generic TEE subsystem
Date: Wed, 8 Jul 2015 16:26:49 -0600 [thread overview]
Message-ID: <20150708222649.GA20068@obsidianresearch.com> (raw)
In-Reply-To: <20150708211129.GA29824@kroah.com>
On Wed, Jul 08, 2015 at 02:11:29PM -0700, Greg Kroah-Hartman wrote:
> > > + cdev_init(&teedev->cdev, &tee_fops);
> > > + teedev->cdev.owner = teedesc->owner;
> >
> > This also needs to set teedev->cdev.kobj.parent.
> > I'm guessing:
> >
> > teedev->cdev.kobj.parent = &teedev->dev.kobj;
> >
> > TPM had the same mistake..
>
> Really? As of a few years ago, A cdev's kobject should not be touched
> by anything other than the cdev core. It's not a "real" kobject in that
> it is never registered in sysfs, and no one sees it. I keep meaning to
Well, when I looked at it, it looked like it was necessary to maintain
the refcount on the memory that is holding cdev.
The basic issue is that cdev_del doesn't seem to be synchronizing.
The use after free race is then something like:
struct tpm_chip {
struct device dev;
struct cdev cdev;
CPU0 CPU1
================= ======================
tpm_chip = kalloc
cdev_add(&tpm_chip->cdev)
device_add(&tpm_chip->dev)
chrdev_open
filp->f_op->open
cdev_del(&tpm_chip->cdev)
device_unregister
(&tpm_chip->dev)
kfree(tpm_chip)
tpm_chip = container_of
fput
cdev_put(.. cdev)
Ie we need cdev to hold a ref on tpm_chip->dev until cdev_put is
called.
> just use something else one of these days for that structure, as lots of
> people get it wrong. Or has things changed there?
Not recently, but this is the commit:
commit 2f0157f13f42800aa3d9017ebb0fb80a65f7b2de
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date: Sun Oct 21 17:57:19 2012 -0700
char_dev: pin parent kobject
In certain cases (for example when a cdev structure is embedded into
another object whose lifetime is controlled by a separate kobject) it is
beneficial to tie lifetime of another object to the lifetime of
character device so that related object is not freed until after
char_dev object is freed.
To achieve this let's pin kobject's parent when doing cdev_add() and
unpin when last reference to cdev structure is being released.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It doesn't seem the be the best situation, this is the 3rd time this
week I've noticed cdev with a kalloc'd struct being used improperly.
Perhaps cdev_init should accept the module and kref parent as an
argument?
Jason
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
To: Greg Kroah-Hartman
<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
Dmitry Torokhov
<dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Jens Wiklander
<jens.wiklander-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Herbert Xu
<herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>,
valentin.manea-hv44wF8Li93QT0dZR+AlfA@public.gmane.org,
jean-michel.delorme-qxv4g6HH51o@public.gmane.org,
emmanuel.michel-qxv4g6HH51o@public.gmane.org,
javier-5MUHepqpBA1BDgjK7y7TUQ@public.gmane.org,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
Michal Simek
<michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH v4 3/5] tee: generic TEE subsystem
Date: Wed, 8 Jul 2015 16:26:49 -0600 [thread overview]
Message-ID: <20150708222649.GA20068@obsidianresearch.com> (raw)
In-Reply-To: <20150708211129.GA29824-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
On Wed, Jul 08, 2015 at 02:11:29PM -0700, Greg Kroah-Hartman wrote:
> > > + cdev_init(&teedev->cdev, &tee_fops);
> > > + teedev->cdev.owner = teedesc->owner;
> >
> > This also needs to set teedev->cdev.kobj.parent.
> > I'm guessing:
> >
> > teedev->cdev.kobj.parent = &teedev->dev.kobj;
> >
> > TPM had the same mistake..
>
> Really? As of a few years ago, A cdev's kobject should not be touched
> by anything other than the cdev core. It's not a "real" kobject in that
> it is never registered in sysfs, and no one sees it. I keep meaning to
Well, when I looked at it, it looked like it was necessary to maintain
the refcount on the memory that is holding cdev.
The basic issue is that cdev_del doesn't seem to be synchronizing.
The use after free race is then something like:
struct tpm_chip {
struct device dev;
struct cdev cdev;
CPU0 CPU1
================= ======================
tpm_chip = kalloc
cdev_add(&tpm_chip->cdev)
device_add(&tpm_chip->dev)
chrdev_open
filp->f_op->open
cdev_del(&tpm_chip->cdev)
device_unregister
(&tpm_chip->dev)
kfree(tpm_chip)
tpm_chip = container_of
fput
cdev_put(.. cdev)
Ie we need cdev to hold a ref on tpm_chip->dev until cdev_put is
called.
> just use something else one of these days for that structure, as lots of
> people get it wrong. Or has things changed there?
Not recently, but this is the commit:
commit 2f0157f13f42800aa3d9017ebb0fb80a65f7b2de
Author: Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Sun Oct 21 17:57:19 2012 -0700
char_dev: pin parent kobject
In certain cases (for example when a cdev structure is embedded into
another object whose lifetime is controlled by a separate kobject) it is
beneficial to tie lifetime of another object to the lifetime of
character device so that related object is not freed until after
char_dev object is freed.
To achieve this let's pin kobject's parent when doing cdev_add() and
unpin when last reference to cdev structure is being released.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
Signed-off-by: Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
It doesn't seem the be the best situation, this is the 3rd time this
week I've noticed cdev with a kalloc'd struct being used improperly.
Perhaps cdev_init should accept the module and kref parent as an
argument?
Jason
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Jens Wiklander <jens.wiklander@linaro.org>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
Arnd Bergmann <arnd@arndb.de>, Rob Herring <robh+dt@kernel.org>,
Herbert Xu <herbert@gondor.apana.org.au>,
valentin.manea@huawei.com, jean-michel.delorme@st.com,
emmanuel.michel@st.com, javier@javigon.com,
Mark Rutland <mark.rutland@arm.com>,
Michal Simek <michal.simek@xilinx.com>
Subject: Re: [PATCH v4 3/5] tee: generic TEE subsystem
Date: Wed, 8 Jul 2015 16:26:49 -0600 [thread overview]
Message-ID: <20150708222649.GA20068@obsidianresearch.com> (raw)
In-Reply-To: <20150708211129.GA29824@kroah.com>
On Wed, Jul 08, 2015 at 02:11:29PM -0700, Greg Kroah-Hartman wrote:
> > > + cdev_init(&teedev->cdev, &tee_fops);
> > > + teedev->cdev.owner = teedesc->owner;
> >
> > This also needs to set teedev->cdev.kobj.parent.
> > I'm guessing:
> >
> > teedev->cdev.kobj.parent = &teedev->dev.kobj;
> >
> > TPM had the same mistake..
>
> Really? As of a few years ago, A cdev's kobject should not be touched
> by anything other than the cdev core. It's not a "real" kobject in that
> it is never registered in sysfs, and no one sees it. I keep meaning to
Well, when I looked at it, it looked like it was necessary to maintain
the refcount on the memory that is holding cdev.
The basic issue is that cdev_del doesn't seem to be synchronizing.
The use after free race is then something like:
struct tpm_chip {
struct device dev;
struct cdev cdev;
CPU0 CPU1
================= ======================
tpm_chip = kalloc
cdev_add(&tpm_chip->cdev)
device_add(&tpm_chip->dev)
chrdev_open
filp->f_op->open
cdev_del(&tpm_chip->cdev)
device_unregister
(&tpm_chip->dev)
kfree(tpm_chip)
tpm_chip = container_of
fput
cdev_put(.. cdev)
Ie we need cdev to hold a ref on tpm_chip->dev until cdev_put is
called.
> just use something else one of these days for that structure, as lots of
> people get it wrong. Or has things changed there?
Not recently, but this is the commit:
commit 2f0157f13f42800aa3d9017ebb0fb80a65f7b2de
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date: Sun Oct 21 17:57:19 2012 -0700
char_dev: pin parent kobject
In certain cases (for example when a cdev structure is embedded into
another object whose lifetime is controlled by a separate kobject) it is
beneficial to tie lifetime of another object to the lifetime of
character device so that related object is not freed until after
char_dev object is freed.
To achieve this let's pin kobject's parent when doing cdev_add() and
unpin when last reference to cdev structure is being released.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It doesn't seem the be the best situation, this is the 3rd time this
week I've noticed cdev with a kalloc'd struct being used improperly.
Perhaps cdev_init should accept the module and kref parent as an
argument?
Jason
next prev parent reply other threads:[~2015-07-08 22:26 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-08 10:16 [PATCH v4 0/5] generic TEE subsystem Jens Wiklander
2015-07-08 10:16 ` Jens Wiklander
2015-07-08 10:16 ` [PATCH v4 1/5] arm/arm64: add smccc ARCH32 Jens Wiklander
2015-07-08 10:16 ` Jens Wiklander
2015-07-08 10:16 ` Jens Wiklander
2015-07-08 10:16 ` [PATCH v4 2/5] dt/bindings: add bindings for optee Jens Wiklander
2015-07-08 10:16 ` Jens Wiklander
2015-07-08 10:16 ` Jens Wiklander
2015-07-08 10:16 ` [PATCH v4 3/5] tee: generic TEE subsystem Jens Wiklander
2015-07-08 10:16 ` Jens Wiklander
2015-07-08 17:10 ` Jason Gunthorpe
2015-07-08 17:10 ` Jason Gunthorpe
2015-07-08 21:11 ` Greg Kroah-Hartman
2015-07-08 21:11 ` Greg Kroah-Hartman
2015-07-08 22:26 ` Jason Gunthorpe [this message]
2015-07-08 22:26 ` Jason Gunthorpe
2015-07-08 22:26 ` Jason Gunthorpe
2015-07-08 22:33 ` Greg Kroah-Hartman
2015-07-08 22:33 ` Greg Kroah-Hartman
2015-07-08 22:33 ` Greg Kroah-Hartman
2015-07-08 23:16 ` Jason Gunthorpe
2015-07-08 23:16 ` Jason Gunthorpe
2015-07-08 23:16 ` Jason Gunthorpe
2015-07-08 23:53 ` Greg Kroah-Hartman
2015-07-08 23:53 ` Greg Kroah-Hartman
2015-07-09 0:47 ` Dmitry Torokhov
2015-07-09 0:47 ` Dmitry Torokhov
2015-07-08 23:28 ` Dmitry Torokhov
2015-07-08 23:28 ` Dmitry Torokhov
2015-07-08 23:28 ` Dmitry Torokhov
2015-07-08 23:52 ` Greg Kroah-Hartman
2015-07-08 23:52 ` Greg Kroah-Hartman
2015-07-09 0:56 ` Dmitry Torokhov
2015-07-09 0:56 ` Dmitry Torokhov
2015-07-09 0:56 ` Dmitry Torokhov
2015-07-09 12:49 ` Jens Wiklander
2015-07-09 12:49 ` Jens Wiklander
2015-07-09 18:25 ` Jason Gunthorpe
2015-07-09 18:25 ` Jason Gunthorpe
2015-07-08 10:16 ` [PATCH v4 4/5] tee: add OP-TEE driver Jens Wiklander
2015-07-08 10:16 ` Jens Wiklander
2015-07-08 10:16 ` [PATCH v4 5/5] Documentation: tee subsystem and op-tee driver Jens Wiklander
2015-07-08 10:16 ` Jens Wiklander
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150708222649.GA20068@obsidianresearch.com \
--to=jgunthorpe@obsidianresearch.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.