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 05558C10F14 for ; Thu, 11 Apr 2019 21:04:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C0DFA2070D 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=i+U8qo+JWu75akFMFJi+EpVoLmMyecNjZ88Ihdf/NSYrdQIkDIWE+SI6NSxU9PBMD 5gyGomH4Zl47ejtI2OYDKA1gV+Cyaj2B8qIfMIwYbjXvo0rQxOTRcTfb0SICGi275n yB7VPfEMmAXA3RjPguTxUtoSx7HOBO+ytn5AWvG0= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726640AbfDKVED (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: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org 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 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,URIBL_BLOCKED, 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 6F069C10F13 for ; Thu, 11 Apr 2019 20:56:50 +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 37F3D21850 for ; Thu, 11 Apr 2019 20:56:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="rHZ6Mgjn"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="wPDQirIs" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 37F3D21850 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=RvRqyoMKdXyfH3n4t9UP3E7ArzlwKo0pY0sgEeccTHk=; b=rHZ6MgjnkkkuMl qNuPVn138i71DFFnnZ8DytK6PACEwvz2Plh7fmE/4moFs6po7DAxpQ5VPDPH530bYX3aVCb8xzjGT 9a0NikjhrBTyvOGJc8UNbMZcWQ0stBLboHvpTMjqXdYmAc/s/rMu9U8OPdi+jMGb1JbDm7xNiWXh8 yfdkuNrULKOy1pNXOmfTKf7KqN1Oun+R/7oP3DMrheq5iJEbYlpSvO/XpEwLQ0STazpeiCArcG6ho SSDR4l2dOLISnauR+uMIPw/uksRFTJ53AT9xqcmcgwEg8PKzoT/QvPLSr0YMhEziKgDtNyTT4W6/T dms9055NvUkG9vin0IJw==; 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 1hEgkY-0002Rb-MX; Thu, 11 Apr 2019 20:56:46 +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 1hEgkV-0002RI-Ut for linux-arm-kernel@lists.infradead.org; Thu, 11 Apr 2019 20:56:45 +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 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 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-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-20190411_135644_015021_AEB609E2 X-CRM114-Status: GOOD ( 15.48 ) 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 , Rik van Riel , Linux Kernel Mailing List , linux-security-module , Geert Uytterhoeven , Dmitry Vyukov , Laura Abbott , Linux ARM , Linux Crypto Mailing List 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, 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel