From patchwork Mon Sep 25 16:17:32 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexander Popov X-Patchwork-Id: 9970197 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 7DB6A602CB for ; Mon, 25 Sep 2017 16:17:51 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6F31E285DE for ; Mon, 25 Sep 2017 16:17:51 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 63CD128CF1; Mon, 25 Sep 2017 16:17:51 +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.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED 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 9D9E2285DE for ; Mon, 25 Sep 2017 16:17:49 +0000 (UTC) Received: (qmail 18394 invoked by uid 550); 25 Sep 2017 16:17:48 -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 18370 invoked from network); 25 Sep 2017 16:17:47 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:from:to:cc:references :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=ipNJSp25w/OCUxpYaigmmEqiKP8dVUG5lybtYm7L3Yo=; b=qywr2cxuYtdk+3HpreDUn2M9XijQIOjQblZ5VZgkZEARqHvvK0s8fKcjDs4Uu0vkgj bZtPE4D/q8019VGdmX2uN82XBdbwcA1YNRSNEI8DnCEsaRQL4sXg3ByqKLfU/vzdE3lw EbGv/uuToH2qAEkGOW/gSuxWZl4xgBlVpLNbrq+1xeIbrNI5jJefPopYN3bLSQxUSzdd 324mg7yJaYsU+N584TPAzw9oXtiGyRLFWHpSGOc9WsNv5/26H6lA3H85Ej7NZUrWRTYa GjFewjywKyvWmfr7LVRC1+m3MnxNjASxCpD+HE7jgQSOBG0s50Iw4VDDJhht9AJC1cQ9 yYpA== X-Gm-Message-State: AHPjjUjkLMIOyd3u7lS1Rs38M9JrWy67bpDXvg5z7libja+kmpulBe60 NHtUGH+gRBEzAEjUWtGH8Fs= X-Google-Smtp-Source: AOwi7QD/82hZ4dpDretqekihchkAzJJS36M9ks1BULMjnHWTMXOfe+ltIM7PA6FIYlHORPsYryicBQ== X-Received: by 10.46.78.25 with SMTP id c25mr2861352ljb.119.1506356256035; Mon, 25 Sep 2017 09:17:36 -0700 (PDT) From: Alexander Popov To: Tycho Andersen Cc: Kees Cook , "kernel-hardening@lists.openwall.com" , PaX Team , Brad Spengler , Laura Abbott , Mark Rutland , Ard Biesheuvel , "x86@kernel.org" , Andy Lutomirski 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> <20170920211814.pq43vq3o53nh2xcn@smitten> <499874eb-48bb-f7f7-176a-b0b1e37cc9c6@linux.com> Message-ID: <7bf586cc-527c-eb3c-b86a-2adbbb7fdfda@linux.com> Date: Mon, 25 Sep 2017 19:17:32 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <499874eb-48bb-f7f7-176a-b0b1e37cc9c6@linux.com> Content-Language: en-US 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 Hello Tycho, On 21.09.2017 22:39, Alexander Popov wrote: > On 21.09.2017 00:18, Tycho Andersen wrote: >> + /* >> + * Check each byte, as we don't know the current stack alignment. >> + */ > > Excuse me, what do you mean by the "current stack alignment"? I guess I got it now. For x86 and x86_64 the stack alignment is controlled by cc_stack_align in arch/x86/Makefile (-mpreferred-stack-boundary in case of gcc). The stack is 4-byte aligned for x86 and 8-byte aligned for x86_64. > The STACKLEAK_POISON position is always 8-byte aligned for x86_64 and 4-byte > aligned for x86 (see the shr instruction in the asm implementation). Eh, my statement is wrong. I've made a simple experiment: this change makes the poison be unaligned: So your idea to check each byte at first should work fine. Would you allow me to make the next version of your test and include it into the fourth version of the STACKLEAK patch? I'll show it to you before sending to the mailing list. Best regards, Alexander diff --git a/fs/exec.c b/fs/exec.c index 56bdc19..893d2e4 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -1961,7 +1961,7 @@ COMPAT_SYSCALL_DEFINE5(execveat, int, fd, #ifdef CONFIG_GCC_PLUGIN_STACKLEAK void __used track_stack(void) { - unsigned long sp = (unsigned long)&sp; + unsigned long sp = (unsigned long)&sp + 1; if (sp < current->thread.lowest_stack && sp >= (unsigned long)task_stack_page(current) +