From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752570AbdKLEV2 (ORCPT ); Sat, 11 Nov 2017 23:21:28 -0500 Received: from mail.kernel.org ([198.145.29.99]:42832 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751434AbdKLEV1 (ORCPT ); Sat, 11 Nov 2017 23:21:27 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 72BD021914 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org X-Google-Smtp-Source: AGs4zMZ8CfjB+Rzo5of6JjCKfW3LYSXVilItRreUX7VLUMNolIPG9w6jEaQUqP5RoST3+cZdWjV+1tKZK9FdmeaMiK0= MIME-Version: 1.0 In-Reply-To: <6dc150cb-13df-65d8-cb6e-0a522c13ae11@marcan.st> References: <06a4b0b4-4b36-91b6-d146-9fc1300b785f@marcan.st> <6dc150cb-13df-65d8-cb6e-0a522c13ae11@marcan.st> From: Andy Lutomirski Date: Sat, 11 Nov 2017 20:21:05 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [kernel-hardening] Re: vDSO maximum stack usage, stack probes, and -fstack-check To: "Hector Martin 'marcan'" Cc: Andy Lutomirski , LKML , "kernel-hardening@lists.openwall.com" , X86 ML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 10, 2017 at 9:16 PM, Hector Martin 'marcan' wrote: > On 2017-11-11 07:04, Andy Lutomirski wrote: >>> On Nov 10, 2017, at 8:36 AM, Hector Martin 'marcan' wrote: >>> >>>> On 2017-11-11 01:02, Hector Martin 'marcan' wrote: >>>> Not entirely sure what's going on here. >>> >>> Actually, if you think about it, it doesn't matter that it skips the >>> first page, since it's probing one page more. That just means the caller >>> will have probed the previous page. So ultimately you're just probing >>> ahead of where you need to, but that should be OK. >>> >> >> The whole point is to touch the stack pages in order. Also, I see no >> guarantee that the function would touch the intermediate page before >> clobbering the probed page. You're seeing exactly that behavior, in >> fact. > > Only because Go is not C and is not compiled like this. If all the code > is GCC-compiled C code and built with -fstack-check, it should always > probe stack pages in order except for potentially the second page in the > stack, which may be touched after the third page (but hopefully your > stack is at least two pages long to begin with). If you're generating code to improve stack overflow, assuming that you have at least two pages left seems like an *awful* assumption to make. > > AIUI -fstack-check was not intended for stack clash protection (the > latter isn't even in a GCC release yet), but in most circumstances it > seems to me like it's an effective mitigation if all code is compiled > with it. Qualys mentioned it as such in their advisory. This is probably > why Gentoo Hardened enables it by default globally in their toolchain. > Gentoo Hardened should seriously consider turning it back off. Do you happen to know what exactly Gentoo does to cause the vdso to get build with -fstack-check? I'll write a patch to either fail the build or to force it off.