From patchwork Wed Sep 20 14:13:09 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tycho Andersen X-Patchwork-Id: 9961517 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 4248D60234 for ; Wed, 20 Sep 2017 14:13:27 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2DF57290D3 for ; Wed, 20 Sep 2017 14:13:27 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 225FF290DB; Wed, 20 Sep 2017 14:13:27 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.wl.linuxfoundation.org (Postfix) with SMTP id 39AD8290D3 for ; Wed, 20 Sep 2017 14:13:26 +0000 (UTC) Received: (qmail 31972 invoked by uid 550); 20 Sep 2017 14:13:24 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Delivered-To: mailing list kernel-hardening@lists.openwall.com Received: (qmail 31945 invoked from network); 20 Sep 2017 14:13:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=docker.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=VUnD58IpcypgyWUbYgugpCgCDhs9pwqYH/n3SfWQOW8=; b=Cn90mB4ZnYcHbLK5K0HfSsvlZTnu6JP69Gvkrk5lA6x67WQw9ghqr+pUJKcw7+FlRf w9+EbTOK1uoWaxVPipu0JWK7+tX8U4ysJ7v5zGaZGR97pO4+O3CJur/3dF4w96HOZ5Mj wcb8Egzy98CMWhMqbzrUKydeRxmLky2+p9iWE= 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:user-agent; bh=VUnD58IpcypgyWUbYgugpCgCDhs9pwqYH/n3SfWQOW8=; b=lXzJH/I5tGcow5mvvG9CDyt8Hq0aPWSeCxnv1Rw1TRckeHpYWTyu6VvuGuXwpojX2Q IUk6hmlO6A7vBZz/FqtbOD6LVnbX3mJ/JlUMTgMVx+DLbt3ENXD5ywSXkq/8TPBtolwI 9Bby0Kcx2DjF7a2dove2lbO4UGd+s5zIy4X5J9+9UkzIaxnWvyNAnGnkq6v++nW5aupd Q0cpvh14bZmu49rbIXiL7RQ3UBbjmKPkC0Fo1sDEU6hqMsYIef3KMwHadgYojH8yVrnB IbQX/aUKOrLnAKUlclja8k6GJ/7jMYadOWyWevFyUwMbnKf5Tk2L4AYRTHBMgsi79Ufn wLmA== X-Gm-Message-State: AHPjjUjuXS0KTASQ8s65l3wW0t0J9cLZkPN3x8ZfM6JG3AGKpqdZnDmj NBcWH+q9BLyrjo82GfZxh4ZDpw== X-Google-Smtp-Source: AOwi7QCaLerUpqR9P1uxbw3bRm5w+bsiBvBG0/VXV6HYkStm2NOI1kSaFU75VLTiXmgZfxDqqYOnCA== X-Received: by 10.202.171.87 with SMTP id u84mr5950486oie.321.1505916791853; Wed, 20 Sep 2017 07:13:11 -0700 (PDT) Date: Wed, 20 Sep 2017 08:13:09 -0600 From: Tycho Andersen To: Alexander Popov Cc: Kees Cook , "kernel-hardening@lists.openwall.com" , PaX Team , Brad Spengler , Laura Abbott , Mark Rutland , Ard Biesheuvel , "x86@kernel.org" , Andy Lutomirski Message-ID: <20170920141309.gbrx53xahjmyrv6c@docker> References: <1499883471-23822-1-git-send-email-alex.popov@linux.com> <20170815033834.2qbjj2of62udqyz3@smitten> <93382ef8-105f-eed4-0d97-0b1a66a047e6@linux.com> <20170816211636.4zwublkvpn6hbo5n@smitten> <20170817175807.ejgsrfdgojgbtkwf@smitten> <1d0963e6-4a89-9859-5379-8575a925ef08@linux.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1d0963e6-4a89-9859-5379-8575a925ef08@linux.com> User-Agent: NeoMutt/20170113 (1.7.2) Subject: [kernel-hardening] Re: [PATCH RFC v3 1/1] gcc-plugins: Add stackleak feature erasing the kernel stack at the end of syscalls X-Virus-Scanned: ClamAV using ClamSMTP On Wed, Sep 20, 2017 at 02:27:05PM +0300, Alexander Popov wrote: > > +/* > > + * Note that the way this test fails is kind of ugly; it hits the BUG() in > > + * track_stack, but then the BUG() handler blows the stack and hits the stack > > + * guard page. > > + */ > > Yes, actually, the reason is deeper. > > When there are less than (THREAD_SIZE / 16) bytes left in the kernel stack, the > BUG() in track_stack() is hit. But do_error_trap(), which handles the invalid > opcode, has a big stack frame. So it is instrumented by the STACKLEAK gcc plugin > and itself calls track_stack() at the beginning. Hence we have a recursive > BUG(), which eventually hits the guard page. > > I banned the instrumentation of do_error_trap() in the plugin, but it didn't > really help, since there are several other instrumented functions called during > BUG() handling. > > So it seems to me that this BUG() in track_stack() is really useless and can be > dropped. Moreover: > - it is not a part of the PaX patch; > - it never worked in Grsecurity kernel because of the error spotted by Tycho. > > What do you think about it? We'll only have a stack guard page in the case of vmap stack, so maybe we can do: Anyway, thanks for the reviews, I'll post an updated version shortly. Tycho diff --git a/fs/exec.c b/fs/exec.c index 8333c4dce59b..8351369cd1e4 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1960,7 +1960,8 @@ void __used track_stack(void) current->thread.lowest_stack = sp; } - if (unlikely((sp & (THREAD_SIZE - 1)) < (THREAD_SIZE / 16))) + if (!IS_ENABLED(CONFIG_VMAP_STACK) && + unlikely((sp & (THREAD_SIZE - 1)) < (THREAD_SIZE / 16))) BUG(); } EXPORT_SYMBOL(track_stack);