Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp4404494imm; Mon, 14 May 2018 07:08:33 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrdt1VbtXzMtOSjzLpHamQgLxsZdYjQwcWGhgck3ItKrYud98in/zbQ97uhkps3xprBwGfI X-Received: by 2002:a62:d717:: with SMTP id b23-v6mr10623507pfh.5.1526306912978; Mon, 14 May 2018 07:08:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526306912; cv=none; d=google.com; s=arc-20160816; b=c+WDVJQ23tfFwN3URdB+nCVQKf2o9+Tbf5rCuz1Ux1l+z8V6MJF6wpWirDXo5MifMP 5RDJ8cgU3PjbqAuuZOg5bPeqklNzknl4PWLl9rTpi0bLnh85S0PpmqDeyj2LGTiwMIYO dSIUlqDkqrLuyAqGDx71/gckxBWadYETikCHBqFQ1YJzt0VvrP61sH4jEoaeyvBwkvst GC+YLkff/eMnCX6dyy7ubZP3Fv8SDVL2mYlVby1x3w5+oA817uosdndHtxDPUXj8H79/ pIDtFWmPNdRaYwOwUp9Fh9Z7/fAfpbzOHE2U7XAxKZWZJT1Y4gk7gtFYzlE6lUpaUHTM /YvA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=cH+7hyiSxuh3OB3fXLfgQTwGbpVwaQUfC/YBiIl1SRo=; b=blrOmjtS5d2RuksOX1S8gVlIrEDeCjcQpi9WSoARxz8snQ4bUsl4qUQH1dkCyoT1NR a9gWEIq86aLt/lSFGOQnbCUlsis+YkTL7I/NufyvZknIkA4TRVhJTi0zZs0YbVvYKr5Q 5xZLv+bnIwkhD3oZ2GzrZqqNS7+rp9DWX9ltEYTc2AutuY+uzvebJ67Bxj6pjJo31xeY SJ1Iw3UdjZSo5070JFSPW21/fKLKL3emlWzSMV5klx+Thvk+PGKbbt2af5YWY/bcb+vR 3jyV8NC/67T97fZL1mj/jKtfET8bXn7Fyp+dg6yZh7rZSMPOXxtMTW5N2o45UbydvUvY hLug== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v38-v6si6012668plg.283.2018.05.14.07.08.09; Mon, 14 May 2018 07:08:32 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932503AbeENOHV (ORCPT + 99 others); Mon, 14 May 2018 10:07:21 -0400 Received: from foss.arm.com ([217.140.101.70]:43404 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932413AbeENOHU (ORCPT ); Mon, 14 May 2018 10:07:20 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A57B21596; Mon, 14 May 2018 07:07:19 -0700 (PDT) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2D5B83F25D; Mon, 14 May 2018 07:07:18 -0700 (PDT) Date: Mon, 14 May 2018 15:07:15 +0100 From: Mark Rutland To: Alexander Popov Cc: Andy Lutomirski , Laura Abbott , Kees Cook , Ard Biesheuvel , kernel-hardening@lists.openwall.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] arm64: Clear the stack Message-ID: <20180514140714.sfmvfpwco63eomor@lakrids.cambridge.arm.com> References: <20180504110907.c2dw33kjmyybso6t@lakrids.cambridge.arm.com> <4badae50-be9b-2c6d-854b-57ab48664800@linux.com> <71199506-b46b-5f91-e489-e6450b6d1067@linux.com> <20180511161317.57k6prl54xjmsit3@lakrids.cambridge.arm.com> <20180514051555.bpbydgr56hyffjch@salmiak> <6c311899-7131-d21b-10f6-d2ba7380a392@linux.com> <20180514100639.v3erlzbuv2e4awfh@lakrids.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 14, 2018 at 04:53:12PM +0300, Alexander Popov wrote: > On 14.05.2018 13:06, Mark Rutland wrote: > > I think it is reasonable to panic() here even with CONFIG_VMAP_STACK > > selected. > > It's too tough for CONFIG_VMAP_STACK on x86 - the system can proceed to live. > Anyway, the check_alloca() code will not be shared between x86 and arm64, I've > described the reasons in this thread. So I can have BUG() for CONFIG_VMAP_STACK > on x86 and Laura can consistently use panic() on arm64. If we need arch-specific implementations anyway, then that's fine by me. > >> So we should not do it in check_alloca() as well, just use BUG() and > >> hope for the best. > > > > Regardless of whether we BUG() or panic(), we're hoping for the best. > > > > Consistently using panic() here will keep things simpler, so any failure > > reported will be easier to reason about, and easier to debug. > > Let me keep BUG() for !CONFIG_SCHED_STACK_END_CHECK. I beware of using panic() > by default, let distro/user decide this. I remember very well how I was shouted > at, when this one was merged: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ce6fa91b93630396ca220c33dd38ffc62686d499 Sure; my comments needn't hold up your patches. Thanks, Mark.