From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 06D44C32754 for ; Thu, 8 Aug 2019 13:05:33 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D261A2171F for ; Thu, 8 Aug 2019 13:05:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="QjZTqZC/"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="sv7ua+Cx" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D261A2171F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=zstzdvXXRAwMEd5EMVwd8GOhv3to0yta/0qQTdNOjqs=; b=QjZTqZC/Gf7/Tq 9HmXse87+OF7IF2PSe7MgsZdcRpoBCcvYda9Ugp/A3jVeN1MYIEd3ROC/lQzNNKwbYTf5kDaVMP/I bm2uskeDmvtjwoeU46z5IeLpr7+RiNtVVBqvhyIBcX2MUDHXhpLvNHzjOycJyzQMIUNhIkqIim2XA Q3/a7kFx+tm+/jwvDGiHyR1EBK3a5/T8wiLFM5AGJNj8CkDxiQyh6i3J0Z7hx9zoNY/2H/LFyso7Z 4YkOYDVPnMR3/F8etxVjzcvXHOEt11c82BGaeDsYimhmV3hB7NgaHd2XPBNUFQ07ZRAtzv9Mq90OW c5Pt30CGj6JL01HSxw8Q==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hvi6l-0001MO-T0; Thu, 08 Aug 2019 13:05:31 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hvi6i-0001M1-Jp for linux-arm-kernel@lists.infradead.org; Thu, 08 Aug 2019 13:05:30 +0000 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id AC5772171F; Thu, 8 Aug 2019 13:05:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1565269528; bh=r3Z5T+QVkdlTcqHZjGzDvph2nY+qT+ThI9PNNH4bnTU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=sv7ua+CxnH4xl1J1IjZ4Q7jgVJb+PPElfZvzAsBNQ07YIHlG+uNLPT/sSoREMITc0 VpYeoLODKkw4x74JJz0bjREEdESbRSBpDQGQKNTpND9muZFan0O6qStPHezRRNYFuG fFQqWbfVP0ioqth8Xw5+UntJX+vqnM19c/d6e7f8= Date: Thu, 8 Aug 2019 15:05:25 +0200 From: Greg KH To: Robin Murphy Subject: Re: usb zero copy dma handling Message-ID: <20190808130525.GA1756@kroah.com> References: <20190808084636.GB15080@priv-mua.localdomain> <20190808085811.GA1265@kroah.com> <10bcb28b-e87b-7b16-97e3-88e727e76d25@arm.com> <20190808100726.GB23844@kroah.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20190808100726.GB23844@kroah.com> User-Agent: Mutt/1.12.1 (2019-06-15) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190808_060528_698987_5B460408 X-CRM114-Status: GOOD ( 36.55 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: yvahkhfo.1df7f8c2@hashmail.org, linux-usb@vger.kernel.org, security@kernel.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Aug 08, 2019 at 12:07:26PM +0200, Greg KH wrote: > On Thu, Aug 08, 2019 at 10:46:24AM +0100, Robin Murphy wrote: > > On 2019-08-08 9:58 am, Greg KH wrote: > > > On Thu, Aug 08, 2019 at 10:46:36AM +0200, yvahkhfo.1df7f8c2@hashmail.org wrote: > > > > Hello linux-usb and linux-arm. > > > > > > > > Ccing security@ because "the kernel dma code is mapping randomish > > > > kernel/user mem to a user process" seems to have security implications > > > > even though i didnt research that aspect past "its a 100% reliable way > > > > to crash a raspi from userspace". > > > > > > > > tried submitting this through linux-arm-kernel ~2 weeks ago but > > > > the only "response" i got was phishing-spam. > > > > tried to follow up through raspi-internals chat, they suggested > > > > i try linux-usb instead, but otoh the original reporter was > > > > deflected from -usb to "try some other mls, they might care". > > > > https://www.spinics.net/lists/linux-usb/msg173277.html > > > > > > > > if i am not following some arcane ritual or indenting convention required > > > > by regular users of these lists i apologize in advance, but i am not a > > > > kernel developer, i am just here as a user with a bug and a patch. > > > > (and the vger FAQ link 404s...) > > > > > > The "arcane ritual" should be really well documented by now, it's in > > > Documentation/SubmittingPatches in your kernel tree, and you can read it > > > online at: > > > https://www.kernel.org/doc/html/latest/process/submitting-patches.html > > > > > > > > > > i rediffed against HEAD even though the two weeks old patch still applied > > > > cleanly with +2 offset. > > > > > > > > # stepping off soap box # actual technical content starts here # > > > > > > > > this is a followup to that thread from 2018-11: > > > > https://www.spinics.net/lists/arm-kernel/msg685598.html > > > > > > > > the issue was discussed in more detail than i can claim > > > > to fully understand back then, but no fix ever merged. > > > > but i would really like to use rtl_433 on a raspi without > > > > having to build a custom-patched kernel first. > > > > > > > > the attached patch is my stripdown/cleanup of a devel-diff > > > > provided to me by the original reporter Steve Markgraf. > > > > credits to him for the good parts, blame to me for the bad parts. > > > > > > > > this does not cover the additional case of "PIO-based usb controllers" > > > > mainly because i dont understand what that means (or how to handle it) > > > > and if its broken right now (as the thread indicates) it might > > > > as well stay broken until someone who understands cares enough. > > > > > > > > could you please get this on track for merging? > > > > > > > > > > > > > > regards, > > > > x23 > > > > > > > > > > > > > > > > > > > diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c > > > > index b265ab5405f9..69594c2169ea 100644 > > > > --- a/drivers/usb/core/devio.c > > > > +++ b/drivers/usb/core/devio.c > > > > @@ -238,9 +238,14 @@ static int usbdev_mmap(struct file *file, struct vm_area_struct *vma) > > > > usbm->vma_use_count = 1; > > > > INIT_LIST_HEAD(&usbm->memlist); > > > > +#ifdef CONFIG_X86 > > > > if (remap_pfn_range(vma, vma->vm_start, > > > > virt_to_phys(usbm->mem) >> PAGE_SHIFT, > > > > size, vma->vm_page_prot) < 0) { > > > > +#else /* !CONFIG_X86 */ > > > > + if (dma_mmap_coherent(ps->dev->bus->sysdev, > > > > + vma, mem, dma_handle, size) < 0) { > > > > +#endif /* !CONFIG_X86 */ > > > > dec_usb_memory_use_count(usbm, &usbm->vma_use_count); > > > > return -EAGAIN; > > > > } > > > > > > First off, we need this in a format we could apply it in (hint, read the > > > above links). > > > > > > But the main issue here is what exactly is this "fixing"? What is wrong > > > with the existing code that non-x86 systems have such a problem with? > > > Shouldn't all of these dma issues be handled by the platform with the > > > remap_pfn_range() call itself? > > > > If usbm->mem is (or ever can be) a CPU address returned by > > dma_alloc_coherent(), then doing virt_to_phys() on it is bogus and may yield > > a nonsense 'PFN' to begin with. However, it it can can ever come from a > > regular page allocation/kmalloc/vmalloc then unconditionally passing it to > > dma_mmap_coherent wouldn't be right either. > > usbm->mem comes from a call to usb_alloc_coherent() which calls > hcd_buffer_alloc() which tries to allocate memory in the best possible > way for that specific host controller. If the host controller has a > pool of memory, it uses that, if the host controller has PIO it uses > kmalloc(), if there are some "pools" of host controller memory it uses > dma_pool_alloc() and as a total last resort, calls dma_alloc_coherent(). > > So yes, this could happen. > > So how to fix this properly? What host controller driver is being used > here that ends up defaulting to dma_alloc_coherent()? Shouldn't that be > fixed up no matter what? > > And then, if what you say is correct then a real fix for devio.c could > be made, but that is NOT going to just depend on the arch the system is > running on, as all of this depends on the host controller being accessed > at that moment for that device. Also see this thread: https://lore.kernel.org/linux-usb/20190801220134.3295-1-gavinli@thegavinli.com/ where this just came up and how the proposed patch here would cause warnings to occur in the kernel log of users for no good reason. That issue is supposed to be fixed "soon"... thanks, greg k-h _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel