Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3674618yba; Sat, 11 May 2019 17:07:02 -0700 (PDT) X-Google-Smtp-Source: APXvYqz/LAyjO3MZ5V3s1ZjbQvkDWCmBf0IiwJfbiXv+TcaYrziGQpiuzhP2pIBfJ3+bGLuUEoNB X-Received: by 2002:a62:128a:: with SMTP id 10mr24230620pfs.225.1557619621898; Sat, 11 May 2019 17:07:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557619621; cv=none; d=google.com; s=arc-20160816; b=A0PEgDpNuN6JgjAI0SDe5MbF/HU2026mKq8bS7KfDWcyOEH+NDXtbWltcFlnS5aE4c pCYdCN9LUkwTq3GlAw/DCcyU4NjoUQ3BwGYndZElqXZ7bxB+2wOnhxvOp6bbWEJ5RAWP TPrMgxrOVillJPaozTPvp3esBQzTgTrYcs3KYZOXwxN+LF7pq4nTiL4oh0N8bAUPX3sn u2Mtclxkjfe8mdHReWQej43OVzZDUSSPKQM8BSIHbGOgebswsC9o4496hQchF6RNvT3P dhAXLb5XRSFF9s8ULL6HD8x+W7ROZlSA9Vsuge/kz6kjqOr2+DLCkqFWbGFgIm5JqOF5 OCIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=8y80o7oSIlIzTCnyWQkOPMTGAyD56gpaeSiM/jdKK2U=; b=0ba4Rc3QuRBSJjZPq+YZewiJ/nS9W5GmCxbvl5nVIQHnkU22W0dcAC7epi59rXwEsA Xh6WNQHGgN/DGNz/7TJrfqf4Me2QW6PL+b/2nFuJ2dKJH55PGFLY+piXq71ijY2JWjJz rDt56hA2cj6r9vc9R6Ea7fIEgGBcqnfpoVPWJECjYUB8tWi3t5bSnuKzwJqWe0UILzr3 3zBqZdpAB09F0gTSd51B3ur+X5721R4Hq7kNtbWZCTK2zGXOTZ0dw51TvoYivZDocUiu IvLeJDF0IuSZGyoFi+T8z9X8XblLOVe98iugkGyvxmpFsR1VN1ZVCRPs32rYog2yh0dX tkXA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=Up8uv0Ro; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f138si7199736pfa.150.2019.05.11.17.05.46; Sat, 11 May 2019 17:07:01 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=Up8uv0Ro; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726279AbfELADN (ORCPT + 99 others); Sat, 11 May 2019 20:03:13 -0400 Received: from mail-pl1-f193.google.com ([209.85.214.193]:41885 "EHLO mail-pl1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726118AbfELADM (ORCPT ); Sat, 11 May 2019 20:03:12 -0400 Received: by mail-pl1-f193.google.com with SMTP id f12so2532051plt.8 for ; Sat, 11 May 2019 17:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=8y80o7oSIlIzTCnyWQkOPMTGAyD56gpaeSiM/jdKK2U=; b=Up8uv0Ro+asj6bZpmf+2XYSZWCYr/M9KA7mJrddNqEPkhkzz6kB9OePFPDIeuj1jF3 tlM3NuPEElrJfHddfeTGU9x8B7GGBsL0Y5eXRSon1D09kzysHRFcZo0q3LeZZLOzVYVH RfcHVfW050pkFtmhtxMh+a0Hy0k8c7OB3+p9k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=8y80o7oSIlIzTCnyWQkOPMTGAyD56gpaeSiM/jdKK2U=; b=pmeG2xPKNuIstaJBxYU90m0jQ4us3UVcjkiqiMCVpebji+C5wDTHoIjRgfHUhvqBD4 +VBvvScZNt75+v4U2vLOHUmrGHyI+y4ubDqk4Ijr0nS/oY1h6//n6c3gJAB4z0dBox0t dEqi9MvbGl0Nb8sdmiN/SNKQokn4j4e9w98uxlD5pc6Z4KbjZZM73Zvc4xpg9I7eMiPr 3xrHCnt9wt1+r3GGut6FGBiRPd9Jclm6cGdnFfv+M4fAleJccOba+MWVtZh485cQBPg2 f2bxADDI5EV0v3CAdsVX+VrkI8C3uva5oQvuL4icvfh70RNxWfpPkvxvq1H7bqvZT/Bp 7rNA== X-Gm-Message-State: APjAAAXnx2KSED6KLuqa2rkbAeCCgmv7f5tGnqSxvWFvG/iHyQPhYKoV iaLfbK7Juy6If01hCCT5iWl4muC9OP4= X-Received: by 2002:a17:902:b410:: with SMTP id x16mr21770482plr.174.1557619391706; Sat, 11 May 2019 17:03:11 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id l1sm11146220pgp.9.2019.05.11.17.03.09 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 11 May 2019 17:03:10 -0700 (PDT) Date: Sat, 11 May 2019 17:03:08 -0700 From: Kees Cook To: Laura Abbott Cc: Andrew Morton , Eric Biggers , Matthew Wilcox , Rik van Riel , linux-kernel@vger.kernel.org Subject: Re: [PATCH] usercopy: Remove HARDENED_USERCOPY_PAGESPAN Message-ID: <201905111657.76FE0BDCEC@keescook> References: <201905101341.A17DDD7@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 10, 2019 at 08:41:43PM -0400, Laura Abbott wrote: > On 5/10/19 3:43 PM, Kees Cook wrote: > > This feature continues to cause more problems than it solves[1]. Its > > intention was to check the bounds of page-allocator allocations by using > > __GFP_COMP, for which we would need to find all missing __GFP_COMP > > markings. This work has been on hold and there is an argument[2] > > that such markings are not even the correct signal for checking for > > same-allocation pages. Instead of depending on BROKEN, this just removes > > it entirely. It can be trivially reverted if/when a better solution for > > tracking page allocator sizes is found. > > > > [1] https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg37479.html > > [2] https://lkml.kernel.org/r/20190415022412.GA29714@bombadil.infradead.org > > > > Suggested-by: Eric Biggers > > Signed-off-by: Kees Cook > > --- > > mm/usercopy.c | 67 ------------------------------------------------ > > security/Kconfig | 11 -------- > > 2 files changed, 78 deletions(-) > > > > diff --git a/mm/usercopy.c b/mm/usercopy.c > > index 14faadcedd06..15dc1bf03303 100644 > > --- a/mm/usercopy.c > > +++ b/mm/usercopy.c > > @@ -159,70 +159,6 @@ static inline void check_bogus_address(const unsigned long ptr, unsigned long n, > > usercopy_abort("null address", NULL, to_user, ptr, n); > > } > > -/* Checks for allocs that are marked in some way as spanning multiple pages. */ > > -static inline void check_page_span(const void *ptr, unsigned long n, > > - struct page *page, bool to_user) > > -{ > > -#ifdef CONFIG_HARDENED_USERCOPY_PAGESPAN > > - const void *end = ptr + n - 1; > > - struct page *endpage; > > - bool is_reserved, is_cma; > > - > > - /* > > - * Sometimes the kernel data regions are not marked Reserved (see > > - * check below). And sometimes [_sdata,_edata) does not cover > > - * rodata and/or bss, so check each range explicitly. > > - */ > > - > > - /* Allow reads of kernel rodata region (if not marked as Reserved). */ > > - if (ptr >= (const void *)__start_rodata && > > - end <= (const void *)__end_rodata) { > > - if (!to_user) > > - usercopy_abort("rodata", NULL, to_user, 0, n); > > - return; > > - } > > - > > - /* Allow kernel data region (if not marked as Reserved). */ > > - if (ptr >= (const void *)_sdata && end <= (const void *)_edata) > > - return; > > - > > - /* Allow kernel bss region (if not marked as Reserved). */ > > - if (ptr >= (const void *)__bss_start && > > - end <= (const void *)__bss_stop) > > - return; > > - > > > I agree the page spanning is broken but is it worth keeping the > checks against __rodata __bss etc.? They're all just white-listing later checks (except RODATA which is doing a cheap RO test which is redundant on any architecture with actual rodata...) so they don't have any value in staying without the rest of the page allocator logic. > > > - /* Is the object wholly within one base page? */ > > - if (likely(((unsigned long)ptr & (unsigned long)PAGE_MASK) == > > - ((unsigned long)end & (unsigned long)PAGE_MASK))) > > - return; > > - > > - /* Allow if fully inside the same compound (__GFP_COMP) page. */ > > - endpage = virt_to_head_page(end); > > - if (likely(endpage == page)) > > - return; > > - > > - /* > > - * Reject if range is entirely either Reserved (i.e. special or > > - * device memory), or CMA. Otherwise, reject since the object spans > > - * several independently allocated pages. > > - */ > > - is_reserved = PageReserved(page); > > - is_cma = is_migrate_cma_page(page); > > - if (!is_reserved && !is_cma) > > - usercopy_abort("spans multiple pages", NULL, to_user, 0, n); > > - > > - for (ptr += PAGE_SIZE; ptr <= end; ptr += PAGE_SIZE) { > > - page = virt_to_head_page(ptr); > > - if (is_reserved && !PageReserved(page)) > > - usercopy_abort("spans Reserved and non-Reserved pages", > > - NULL, to_user, 0, n); > > - if (is_cma && !is_migrate_cma_page(page)) > > - usercopy_abort("spans CMA and non-CMA pages", NULL, > > - to_user, 0, n); > > - } We _could_ keep the mixed CMA/reserved/neither check if we really wanted to, but that's such a corner case of a corner case, I'm not sure it's worth doing the virt_to_head_page() across the whole span to figure it out. I really wish we had size of allocation reliably held somewhere. We'll need it for doing memory tagging of the page allocator too... -- Kees Cook