From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751291AbdKKFQ4 (ORCPT ); Sat, 11 Nov 2017 00:16:56 -0500 Received: from marcansoft.com ([212.63.210.85]:50114 "EHLO mail.marcansoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750791AbdKKFQz (ORCPT ); Sat, 11 Nov 2017 00:16:55 -0500 Subject: Re: [kernel-hardening] Re: vDSO maximum stack usage, stack probes, and -fstack-check To: Andy Lutomirski Cc: LKML , "kernel-hardening@lists.openwall.com" , X86 ML References: <06a4b0b4-4b36-91b6-d146-9fc1300b785f@marcan.st> From: "Hector Martin 'marcan'" Message-ID: <6dc150cb-13df-65d8-cb6e-0a522c13ae11@marcan.st> Date: Sat, 11 Nov 2017 14:16:48 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: es-ES Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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). 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. -- Hector Martin "marcan" (marcan@marcan.st) Public Key: https://mrcn.st/pub