Received: by 10.223.185.116 with SMTP id b49csp4529053wrg; Tue, 6 Mar 2018 18:18:18 -0800 (PST) X-Google-Smtp-Source: AG47ELuh3tL0rxyQoI2Xc4BEVsRCFWZ4O4xYbCh0sDyDnOwliTYoKGYAClJN+v2HQcAM7ub4ta05 X-Received: by 10.98.64.146 with SMTP id f18mr21103551pfd.30.1520389098796; Tue, 06 Mar 2018 18:18:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520389098; cv=none; d=google.com; s=arc-20160816; b=zh/tu+0U/+0KXBMYQAKIl2XIA8IASc1JFnWBiiPRVoHoh7WQuXPnZCw53JuaPdmw/s Nm0e20id8vX9PqCSzH/3tmDY7GgXklFibMifSSg2iR0HDpFYrExgjJ2DDuOkN7pjy8Y6 vELK2wMDQYoULHrfLVD49a2x9QmLMSOi4SDTiJwnpJWmy+p4JnT9GtQL4+fqSaTXlvPf 0Hyq1XNGIzB2xYcMk/op1QOeQsX5+0vSh7ehiRdLwFgMSKaPEAa60JAgg5Ff6xQ+j6Zp gU1RHIp9noFoLwkylwF9SzYE/87kLif4WyxpbDLbR9TPPICkVhCT4F8+6o4f/0unyI0s ew+g== 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:dkim-signature:arc-authentication-results; bh=67KF93qxo06ToM0L0lVTklwrjHz9cy0Kg4aRAENsnec=; b=gtcVyUc9QCA5eVoBs8JyFv612thp0kYJx1MHjaLdYxg5s/ukQEHOOP6cXRU/ZoIRJk ut2/OTgTYAQtb//NTEf+CuGnWfJzBMiTCDTpah4YMUSYmm4xhJOGA60G1KzPr36bQWGg 0R3gf1PTHd00FAUR0o0XFyM7wZGlyAiOuG0KysU572T0ADXNWOUpOmyvumiUCTtlcX04 SgL5mTX1op/tmuUpglOm11OMzngaIfjXCWiYHex9JXHxRQ/DPA2aUqIzxFIcPtS2P/Ze kTPGSQp4giCXgtjcy7uQvCdDYfXL5eRtI1EP7eQjFpaO5NujMU+TbKXpJ9k+BCwsL/W9 qaZg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@eso.teric.us header.s=mail header.b=i/dL+2bx; 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 34-v6si12030237plc.368.2018.03.06.18.18.04; Tue, 06 Mar 2018 18:18:18 -0800 (PST) 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; dkim=pass header.i=@eso.teric.us header.s=mail header.b=i/dL+2bx; 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 S1754173AbeCGCRL (ORCPT + 99 others); Tue, 6 Mar 2018 21:17:11 -0500 Received: from eso.teric.us ([69.164.192.171]:41040 "EHLO eso.teric.us" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754150AbeCGCRJ (ORCPT ); Tue, 6 Mar 2018 21:17:09 -0500 Received: from neo.teric.us (neo.teric.us [198.58.100.135]) by eso.teric.us (Postfix) with ESMTPS id D337B1036E; Tue, 6 Mar 2018 20:17:08 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eso.teric.us; s=mail; t=1520389028; bh=67KF93qxo06ToM0L0lVTklwrjHz9cy0Kg4aRAENsnec=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=i/dL+2bx5k8RFZqalzYpv6MrfgqOq310kurqQueZ/fHZZtR6GjNJ0xR2fbX5hwt+p uKsxUsnIE5CdfEXDZUJydBXCtdb30iX0huqj6DaUj32LjGxbrPTIwaFTZZ/kynOUJo Sq22gtiB/YJQkwsvxkF8UYAWDJPk2DwKBdYRVUzvRHmnqMKM6xJXfvFy1CzQLsj5Tf AVf0gRkg4HVSitFPzUv2fnsoqWJ10ChkL6XbuKmnPobP8tvU1iH2eCQHmdzQvrr9hj ePld6ERIATM5B7iF2QoLSKrln3g+q0Goiim0Fn5bYuWXq03bVhNZ0RwlQkCHOSMUIu e7e4eNDVbCkKQ== Received: by neo.teric.us (Postfix, from userid 1002) id A119E185FDB; Tue, 6 Mar 2018 20:17:08 -0600 (CST) Date: Tue, 6 Mar 2018 20:17:08 -0600 From: Julia Cartwright To: "Jason A. Donenfeld" Cc: LKML , pageexec@freemail.hu Subject: Re: C tricks for efficient stack zeroing Message-ID: <20180307021708.GC1924@kryptos.localdomain> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 02, 2018 at 08:50:17PM +0100, Jason A. Donenfeld wrote: [..] > What would be really nice would be to somehow keep track of the > maximum stack depth, and just before the function returns, clear from > the maximum depth to its stack base, all in one single call. This > would not only make the code faster and less brittle, but it would > also clean up some algorithms quite a bit. > > Ideally this would take the form of a gcc attribute on the function, > but I was unable to find anything of that nature. I started looking > for little C tricks for this, and came up dry too. I realize I could > probably just take the current stack address and zero out until _the > very end_ but that seems to overshoot and would probably be bad for > performance. The best I've been able to do come up with are some > x86-specific macros, but that approach seems a bit underwhelming. > Other approaches include adding a new attribute via the gcc plugin > system, which could make this kind of thing more complete [cc'ing > pipacs in case he's thought about that before]. Can objtool support a static stack usage analysis? I'm wondering if it's possible to place these sensitive functions in a special linker section, like .text.stackzero.; objtool could collect static call data (as it already does) and stack usage, spitting out a symbol definition stackzero__max_depth, which you could then use to bound your zeroing. Obviously this is a static analysis, with the limitations therein. Julia