From: gregkh@linuxfoundation.org (Greg Kroah-Hartman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 3/5] tee: generic TEE subsystem
Date: Wed, 8 Jul 2015 15:33:25 -0700 [thread overview]
Message-ID: <20150708223325.GA5843@kroah.com> (raw)
In-Reply-To: <20150708222649.GA20068@obsidianresearch.com>
On Wed, Jul 08, 2015 at 04:26:49PM -0600, Jason Gunthorpe wrote:
> 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;
Oops, right there's your problem. You can't have two reference counted
objects trying to manage the memory of a single structure. No matter
what you do, it's going to be a pain to deal with this, so don't :)
>
> 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.
No, separate them, make the cdev a pointer and all should be fine.
> > 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?
Oh yeah, that commit :(
If you know _exactly_ what you are doing, you can get away with this,
but I strongly recommend not doing that. As proof of that, in some new
code I'm working on, I did not do this, just because I'm not smart
enough to ensure it's all working properly...
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
To: Jason Gunthorpe
<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
Cc: Dmitry Torokhov
<dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
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 15:33:25 -0700 [thread overview]
Message-ID: <20150708223325.GA5843@kroah.com> (raw)
In-Reply-To: <20150708222649.GA20068-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
On Wed, Jul 08, 2015 at 04:26:49PM -0600, Jason Gunthorpe wrote:
> 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;
Oops, right there's your problem. You can't have two reference counted
objects trying to manage the memory of a single structure. No matter
what you do, it's going to be a pain to deal with this, so don't :)
>
> 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.
No, separate them, make the cdev a pointer and all should be fine.
> > 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?
Oh yeah, that commit :(
If you know _exactly_ what you are doing, you can get away with this,
but I strongly recommend not doing that. As proof of that, in some new
code I'm working on, I did not do this, just because I'm not smart
enough to ensure it's all working properly...
thanks,
greg k-h
--
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
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 15:33:25 -0700 [thread overview]
Message-ID: <20150708223325.GA5843@kroah.com> (raw)
In-Reply-To: <20150708222649.GA20068@obsidianresearch.com>
On Wed, Jul 08, 2015 at 04:26:49PM -0600, Jason Gunthorpe wrote:
> 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;
Oops, right there's your problem. You can't have two reference counted
objects trying to manage the memory of a single structure. No matter
what you do, it's going to be a pain to deal with this, so don't :)
>
> 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.
No, separate them, make the cdev a pointer and all should be fine.
> > 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?
Oh yeah, that commit :(
If you know _exactly_ what you are doing, you can get away with this,
but I strongly recommend not doing that. As proof of that, in some new
code I'm working on, I did not do this, just because I'm not smart
enough to ensure it's all working properly...
thanks,
greg k-h
next prev parent reply other threads:[~2015-07-08 22:33 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
2015-07-08 22:26 ` Jason Gunthorpe
2015-07-08 22:26 ` Jason Gunthorpe
2015-07-08 22:33 ` Greg Kroah-Hartman [this message]
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=20150708223325.GA5843@kroah.com \
--to=gregkh@linuxfoundation.org \
--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.