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=0.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,FSL_HELO_FAKE,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT 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 8C85CC10F11 for ; Wed, 10 Apr 2019 19:07:37 +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 5D0812082E for ; Wed, 10 Apr 2019 19:07:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="QtULUp43"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="lpbMvmzo" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5D0812082E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.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=7T8IgiubZFp9qIjtIAUZRzA3hVzhVvfqq81PkxpGTFg=; b=QtULUp43z2W3QD 1/1qLX2dO17i/R9lZpPJaztxRGphZE0XOiTh+Q21HBIM5W2wB8KDtuBGr0vFNJKN4f3YRPURxW1xT 59WBYM5ZISnqeTwxPkQ+Mb2N+MPA/j9ezGuqI2SkX2BqtJNo5oQDKCVzEXCAwg2JTHo+a6A2AyncK dWE4A5+yGYSI4HBrurqKRtSCK98dK02eL7+Hftzqff/af8pJSS1ZdWSC5z/vhGZsR/HpeufwGusTZ dremB0HvKMSx1gdEV+LR0ebqXiP0PVGjhb1nNd85/Iv5qHMfi0O5yeE5urEeD1OU5+TCgS1GbCp1n vdYFPer0n1aogQMW4BxQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hEIZM-0005dg-O8; Wed, 10 Apr 2019 19:07:36 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hEIZJ-0005dA-Mh for linux-arm-kernel@lists.infradead.org; Wed, 10 Apr 2019 19:07:35 +0000 Received: from gmail.com (unknown [104.132.1.77]) (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 D39952082E; Wed, 10 Apr 2019 19:07:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1554923253; bh=l5kx7M5yIhwXZKbmcPL7AM62Ycxqpjj9uZJIKXIkFXk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lpbMvmzoK4obAkSjUiVj+EJaYr0Z2YfkhiR34D1ICsugEYR1EAhNnz5I7CbWuJcfg ZZdcdlhzwAO3/43bU/AoqBZhciueBKrBKPr0zqNY1P3zcqN738Rj7zmls3BBsZ9YLF /5/0OdnzKiGCKE1wYY1814YukGtRhezkGyeOjNpc= Date: Wed, 10 Apr 2019 12:07:31 -0700 From: Eric Biggers To: Kees Cook Subject: Re: crypto: Kernel memory overwrite attempt detected to spans multiple pages Message-ID: <20190410190729.GA120258@gmail.com> References: <20190319170911.GB202956@gmail.com> <20190320185719.GB180195@gmail.com> <20190321175122.GA1587@sol.localdomain> <20190410031734.GB7140@sol.localdomain> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190410_120733_778901_4C5FF0DC X-CRM114-Status: GOOD ( 25.34 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Herbert Xu , Linux Kernel Mailing List , linux-security-module , Geert Uytterhoeven , Linux Crypto Mailing List , Linux ARM 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 Wed, Apr 10, 2019 at 11:30:57AM -0700, Kees Cook wrote: > On Tue, Apr 9, 2019 at 8:17 PM Eric Biggers wrote: > > > > On Thu, Mar 21, 2019 at 10:51:22AM -0700, Eric Biggers wrote: > > > On Thu, Mar 21, 2019 at 10:45:31AM -0700, Kees Cook wrote: > > > > On Wed, Mar 20, 2019 at 11:57 AM Eric Biggers wrote: > > > > > > > > > > On Tue, Mar 19, 2019 at 10:09:13AM -0700, Eric Biggers wrote: > > > > > > On Tue, Mar 19, 2019 at 12:54:23PM +0100, Geert Uytterhoeven wrote: > > > > > > > When running the sha1-asm crypto selftest on arm with > > > > > > > CONFIG_HARDENED_USERCOPY_PAGESPAN=y: > > > > > > > > > > > > > > usercopy: Kernel memory overwrite attempt detected to spans > > > > > > > multiple pages (offset 0, size 42)! > > > > > > > > > > > > Well, this must happen with the new (in 5.1) crypto self-tests implementation > > > > > > for any crypto algorithm when CONFIG_HARDENED_USERCOPY_PAGESPAN=y. I don't > > > > > > understand why hardened usercopy considers it a bug though, as there's no buffer > > > > > > overflow. The crypto tests use copy_from_iter() to copy data into a 2-page > > > > > > buffer that was allocated with __get_free_pages(): > > > > > > > > > > > > __get_free_pages(GFP_KERNEL, 1) > > > > > > > > > > > > ... where 1 means an order-1 allocation. > > > > > > > > > > > > If it copies to offset=4064 len=42, for example, then hardened usercopy > > > > > > considers it a bug even though the buffer is 8192 bytes long. Why? > > > > > > > > > > > > It isn't actually copying anything to/from userspace, BTW; it's using iov_iter > > > > > > with ITER_KVEC. > > > > > > > > > > > > - Eric > > > > > > > > > > Kees, any thoughts on why hardened usercopy rejects copies spanning a page > > > > > boundary when they seem to be fine? > > > > > > > > This is due to missing the compound page marking, if I remember > > > > correctly. However, I tend to leave the pagespan test disabled: it > > > > really isn't ready for production use -- there are a lot of missing > > > > annotations still. > > > > > > > > > > So do I need to add __GFP_COMP? Is there any actual reason to do so? > > > Why does hardened usercopy check for it? > > > > > > - Eric > > > > Hi Kees, any answer to this question? > > Hi! Sorry, this got lost in my inbox. Yes, if you can add __GFP_COMP, > that would fix this case. No one has had time lately to track down all > these cases, but avoiding adding new ones would be wonderful. :) > > It's in there because it's a state I'd like to get to in the kernel, > but it'll require a lot more work to get there. > That didn't answer my question. My question is what is the purpose of this? If there was actual buffer overflow when __GFP_COMP isn't specified that would make perfect sense, but AFAICS there isn't. So why does hardened usercopy consider it broken when __GFP_COMP isn't specified? - Eric _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel