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=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, USER_AGENT_MUTT autolearn=ham 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 72C6BC10F12 for ; Wed, 17 Apr 2019 04:08:34 +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 412C320693 for ; Wed, 17 Apr 2019 04:08:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="d+Cge1sN" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 412C320693 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.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=X97Bif+G3r+yY2p8XUPTvAh35aYnKrx7SXJpBmRxfyc=; b=d+Cge1sNMa1Om6 x1oaHwAaFtKDZrDVq5MkVKeVlC8prkHEkf1N20HGyEk6gQCygYW2tmZ7mHF2yJFzMrnX7Mizw7dAE DxNzYbBFdQPdb+27uM79CNgR7A2prhtRBfAmKsjssDtnUEu0vtK2eZGDJtfygaf3PVL4OahxevBUq 54oVpnbHho4N6gU0uuKIhqY5cypLW9G+c2Np6rAGWpgBzqFroE7e3yxundm9wr8nQhju8YD5PjMSL 7C/Tv7onUHn74iU8c52P4M5f4T105TqEFNHHNxG2Aio/mT2iDJeQtqGixO4XsoB94jHLWf2I6tGH0 vpLJFsGLmmoX3N3zsGfA==; 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 1hGbs1-0002mB-DG; Wed, 17 Apr 2019 04:08:25 +0000 Received: from willy by bombadil.infradead.org with local (Exim 4.90_1 #2 (Red Hat Linux)) id 1hGbry-0002lh-TV; Wed, 17 Apr 2019 04:08:22 +0000 Date: Tue, 16 Apr 2019 21:08:22 -0700 From: Matthew Wilcox To: Kees Cook Subject: Re: [PATCH] crypto: testmgr - allocate buffers with __GFP_COMP Message-ID: <20190417040822.GB7751@bombadil.infradead.org> References: <20190411192607.GD225654@gmail.com> <20190411192827.72551-1-ebiggers@kernel.org> <20190415022412.GA29714@bombadil.infradead.org> <20190415024615.f765e7oagw26ezam@gondor.apana.org.au> <20190416021852.GA18616@bombadil.infradead.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) 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: Linux ARM , Herbert Xu , Rik van Riel , Linux Kernel Mailing List , Eric Biggers , Linux-MM , linux-security-module , Geert Uytterhoeven , linux-crypto , Laura Abbott , Dmitry Vyukov 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 Mon, Apr 15, 2019 at 10:14:51PM -0500, Kees Cook wrote: > On Mon, Apr 15, 2019 at 9:18 PM Matthew Wilcox wrote: > > I agree; if the crypto code is never going to try to go from the address of > > a byte in the allocation back to the head page, then there's no need to > > specify GFP_COMP. > > > > But that leaves us in the awkward situation where > > HARDENED_USERCOPY_PAGESPAN does need to be able to figure out whether > > 'ptr + n - 1' lies within the same allocation as ptr. Without using > > a compound page, there's no indication in the VM structures that these > > two pages were allocated as part of the same allocation. > > > > We could force all multi-page allocations to be compound pages if > > HARDENED_USERCOPY_PAGESPAN is enabled, but I worry that could break > > something. We could make it catch fewer problems by succeeding if the > > page is not compound. I don't know, these all seem like bad choices > > to me. > > If GFP_COMP is _not_ the correct signal about adjacent pages being > part of the same allocation, then I agree: we need to drop this check > entirely from PAGESPAN. Is there anything else that indicates this > property? (Or where might we be able to store that info?) As far as I know, the page allocator does not store size information anywhere, unless you use GFP_COMP. That's why you have to pass the 'order' to free_pages() and __free_pages(). It's also why alloc_pages_exact() works (follow all the way into split_page()). > There are other pagespan checks, though, so those could stay. But I'd > really love to gain page allocator allocation size checking ... I think that's a great idea, but I'm not sure how you'll be able to do that. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel