Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754347AbbDRRaP (ORCPT ); Sat, 18 Apr 2015 13:30:15 -0400 Received: from quartz.orcorp.ca ([184.70.90.242]:52332 "EHLO quartz.orcorp.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753312AbbDRRaN (ORCPT ); Sat, 18 Apr 2015 13:30:13 -0400 Date: Sat, 18 Apr 2015 11:29:23 -0600 From: Jason Gunthorpe To: Russell King - ARM Linux Cc: Jens Wiklander , valentin.manea@huawei.com, devicetree@vger.kernel.org, javier@javigon.com, emmanuel.michel@st.com, Herbert Xu , Arnd Bergmann , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, jean-michel.delorme@st.com, tpmdd-devel@lists.sourceforge.net, linux-arm-kernel@lists.infradead.org Subject: Re: [tpmdd-devel] [RFC PATCH 1/2] tee: generic TEE subsystem Message-ID: <20150418172923.GA10605@obsidianresearch.com> References: <1429257057-7935-1-git-send-email-jens.wiklander@linaro.org> <1429257057-7935-2-git-send-email-jens.wiklander@linaro.org> <20150417163054.GA28241@obsidianresearch.com> <20150418090147.GF12732@n2100.arm.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150418090147.GF12732@n2100.arm.linux.org.uk> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3483 Lines: 83 On Sat, Apr 18, 2015 at 10:01:47AM +0100, Russell King - ARM Linux wrote: > On Fri, Apr 17, 2015 at 10:30:54AM -0600, Jason Gunthorpe wrote: > > On Fri, Apr 17, 2015 at 09:50:56AM +0200, Jens Wiklander wrote: > > > + teedev = devm_kzalloc(dev, sizeof(*teedev), GFP_KERNEL); > > [..] > > > + rc = misc_register(&teedev->miscdev); > > [..] > > > +void tee_unregister(struct tee_device *teedev) > > > +{ > > [..] > > > + misc_deregister(&teedev->miscdev); > > > +} > > [..] > > >+static int optee_remove(struct platform_device *pdev) > > >+{ > > >+ tee_unregister(optee->teedev); > > > > Isn't that a potential use after free? AFAIK misc_deregister does not > > guarentee the miscdev will no longer be accessed after it returns, and > > the devm will free it after optee_remove returns. > > > > Memory backing a stuct device needs to be freed via the release > > function. > > Out of interest, which struct device are you talking about here? Sorry, I was imprecise. In the first paragraph I ment 'miscdev' to refer to the entire thing, struct tee_device, struct misc_device, the driver allocations, etc. So, the first issue is the use-after-free via ioctl() touching struct tee_device that you described. But then we trundle down to: + ctx->teedev->desc->ops->get_version(ctx, &vers.spec_version, + vers.uuid); If we kref teedev so it is valid then calling a driver call back after (or during) it's remove function is very likely to blow up. Also, in TPM we discovered that adding a sysfs file was very ugly (impossible?) because without the misc_mtx protection that open has, getting a locked tee_device in the sysfs callback is difficult. With TPM, we ended up trying lots of options for fixing struct misc_device in the tpm core, which is handling multiple sub drivers, and basically gave up. Gave each struct tpm_device an embedded struct device like Greg suggested here. Then the tpm core is working with the APIs, not struggling against them. But this is not a user-space invisible change, so better to do it right from day 1 .. We followed rtc as an example of how to create a mid-layer that exports it's own register function, with char dev and sysfs components. It seems properly implemented, and has elegant solutions to these problems (like ops): - Don't mess with modules, use 'ops' and set 'ops' to null when the driver removes. The driver core will keep the driver module around for you bettwen the probe/remove calls. Setting ops = NULL ensures driver module code cannot be called after remove. - Use locking for 'ops' to serialize driver callbacks with driver removal - Embed a struct device/etc in the struct tee_device and use the release function to deallocate struct tee_device. All callbacks from the driver/char/sysfs core can now use container_of on something that is already holds the right kref. - Consider an alloc/register pattern as we use now in TPM. This has proven smart for TPM as it allows: alloc tee_device + init struct device, etc driver setup core library helper calls for setup/etc driver register + char dev publish It appeared to me this driver was copying TPM's old architecture, which is very much known to be broken. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/