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.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 46FEBC282CE for ; Thu, 11 Apr 2019 21:04:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 10E1B2070D for ; Thu, 11 Apr 2019 21:04:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1555016649; bh=rBrc//Q8zkoBO+A9SsRSKoG9WGpSqk/8v99bH2iG5No=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=WnIjGsW2i3VxJMirvocUbMJm2z57yUWEAOt8hkVWrIlTkTDQMttZFlzFIid8KVC9G xnlPWRlfK69j593Hr889HqrHlVPfZtRJUsCjYCR7fdiFjvnXv8H68PsalYJleU/KrW IBs188GC109B44ujw9CpOBu4S5Dm4XY3s2IMPnaE= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727063AbfDKVED (ORCPT ); Thu, 11 Apr 2019 17:04:03 -0400 Received: from mail.kernel.org ([198.145.29.99]:40388 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726723AbfDKVED (ORCPT ); Thu, 11 Apr 2019 17:04:03 -0400 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 3FE532146F; Thu, 11 Apr 2019 20:56:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1555016203; bh=rBrc//Q8zkoBO+A9SsRSKoG9WGpSqk/8v99bH2iG5No=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=wPDQirIsuHS5B2351kVZEj22FJLGqwUYvVMz4uKk743DHmbgBnRF3JgLtTuw8ph0E WaCg0I1PWscaFjRPzGnAO/jGP47dAx4wE2onubgeXY7SL0OS/HYT/Aj0ka7jk2z81K BEUUBQOqppvUjGPpabEkBIQe13AjAl2n+O5HhqSI= Date: Thu, 11 Apr 2019 13:56:41 -0700 From: Eric Biggers To: Kees Cook Cc: Dmitry Vyukov , Geert Uytterhoeven , Herbert Xu , linux-security-module , Linux ARM , Linux Crypto Mailing List , Linux Kernel Mailing List , Laura Abbott , Rik van Riel Subject: Re: crypto: Kernel memory overwrite attempt detected to spans multiple pages Message-ID: <20190411205640.GE225654@gmail.com> References: <20190410031734.GB7140@sol.localdomain> <20190410190729.GA120258@gmail.com> <20190410231156.GB120258@gmail.com> <20190411175823.GC225654@gmail.com> <20190411192607.GD225654@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: On Thu, Apr 11, 2019 at 01:36:37PM -0700, Kees Cook wrote: > On Thu, Apr 11, 2019 at 12:26 PM Eric Biggers wrote: > > Well, I guess I'll just add __GFP_COMP so I at least don't get spammed with > > useless bug reports. > > Thanks, I appreciate it. > > > But I don't think it's in any way acceptable to change the semantics of the > > kernel's page allocator but only under some obscure config option, don't > > document it anywhere, ignore the known problems for years, say that the option > > is broken anyway so it shouldn't be used, and have to exchange 15 emails to get > > anything resembling an explanation. > > I understand what you mean, yeah. I'm sorry I wasn't clear about it > earlier. What do you think might help the situation as far as > documentation? > Explanation in Documentation/core-api/memory-allocation.rst of when to use __GFP_COMP and why. Where "why" includes the real underlying reason why it's designed the way it is, not just "you now need to provide this flag in order to stop the hardened usercopy thing from crashing, even though previously it meant something else, because that's the way it is." Also a brief, improved explanation of __GFP_COMP in include/linux/gfp.h. Also get Documentation/security/self-protection.rst up to date with what's actually in the kernel. Currently it doesn't mention hardened usercopy at all, and it's unclear about what's supported now vs. what is future work. And actually fix the known problems with the pagespan check, not ignore them for years. If not feasible, remove the option. - Eric