Received: by 10.223.185.116 with SMTP id b49csp292275wrg; Fri, 2 Mar 2018 19:26:43 -0800 (PST) X-Google-Smtp-Source: AG47ELucwDKn8VoOYUVcpNCquOAvrqjS9ZEiwnerITEQiuhMhJzCsCUJWgMpXgNHcCfTWtzY4dCi X-Received: by 10.98.196.199 with SMTP id h68mr7684459pfk.42.1520047603632; Fri, 02 Mar 2018 19:26:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520047603; cv=none; d=google.com; s=arc-20160816; b=DvFJAkG/x+BYm3sZxMRAY12ZhS3FbrDaqj0/tAIcQrgICpINMJhL22iU4DAHo0dBNn cjxo4kheqoRv7qTLHL6Z4N2BScZMBgtZ6/EvNGH0c8Rg6gcSzZvzBVqMYmsQ8Av75pNs EcdJyoZcxFEZRGxI0NxgaLEsvd8DMKt7cTZdawF51Os96E/w/9VEkjZ3wfD/4FJW8l8L /cr1HRIZkJsG7I47ZilkMxNf5Iz240iHTU8U+kPOzsj/rkS2TEyjiUFn191Wy9rwrpC1 emoXJV1VWYbrMwolgVr5aa32Hc/I9ZMUtBvNbetYQ1BfCGdqNHD+eEN9LL/caX+zQCLg w3xg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :mime-version:dkim-signature:arc-authentication-results; bh=FEOVAvFXlr8OlDcCW3bXaPAZOq7Ate6Z1gwQihuz550=; b=CRlWFP5BIGGSDfr7JoEQFftoIm+2LNEDAgF5u5FfybpbnFxyqehYlmUCf5jIjBzBHG BzZzu3StjY/majMh24+DWffVri0iJwGSNxBvuQ+td9cIxa0fM11Wp5Ky7TrWaWX6nHsD Xt7LoaaHAwN8gGyQWZtMCoowsvrLanWi7LVHLZ+Dva5QORHjr5ewERlI53SZYKhfiHbV nv2Y1mpG+y/Szex/6JEnYNUX45NDch/jMFXfzWVOnq1a43Nj/sULa352z4oFexsUrh+1 gViOhzXUpTMKATEJFQe/gB4LL9WCZSEUdBMfUUIPQdvRTviT+q4Nmwf5aTwAzUMNTwdk qX+Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@zx2c4.com header.s=mail header.b=l3EqDd4Y; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=zx2c4.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e4si4906865pgv.581.2018.03.02.19.26.29; Fri, 02 Mar 2018 19:26:43 -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=@zx2c4.com header.s=mail header.b=l3EqDd4Y; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=zx2c4.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932350AbeCBTuX (ORCPT + 99 others); Fri, 2 Mar 2018 14:50:23 -0500 Received: from frisell.zx2c4.com ([192.95.5.64]:36055 "EHLO frisell.zx2c4.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932243AbeCBTuT (ORCPT ); Fri, 2 Mar 2018 14:50:19 -0500 Received: by frisell.zx2c4.com (ZX2C4 Mail Server) with ESMTP id d8ca7637 for ; Fri, 2 Mar 2018 19:32:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=zx2c4.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; s=mail; bh=/hk 8MwqJtt8Mhx94+yo9qRNfe08=; b=l3EqDd4YNjWwPfou8jQawR3V6lCYkzsy/UH QYL7SQsFzllceM3KX2SIxwf4rVgMsIiqNm8r5l+DZwhl779/Khyiq3Kl20P+ttyH uPWnbLfB6KVgd5N7rNcfd9s9g9HqdCLmt8SYhAVgzzTLvTrrH546oJJPnHYoGbQj NDPM2vOhzLARrHXslWIQAYUcQ4dMN9Fmw1tYK+Oc6Ta3sBampxkJDmT6zPTUA6uV Lf4p9q5AYXg0h6/L/xltVo5W+Bu8MdQxqXf1dCl6TMN4TH1L8VZgMo70wTfLIYrq cNF4nVWBAQ+/hkBvPPfwVPHIvxO10AsAcShioezlxrl+d1rYRFA== Received: by frisell.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 708bb7d1 (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:NO) for ; Fri, 2 Mar 2018 19:32:32 +0000 (UTC) Received: by mail-oi0-f53.google.com with SMTP id 123so7879651oig.5 for ; Fri, 02 Mar 2018 11:50:18 -0800 (PST) X-Gm-Message-State: APf1xPBID03LT8UaFdXjJu+utVI7u9TMMbExRTv4s5IQJzqkDPoTkYff J38nDU+wkRfhDR7imyrVwHHfmk007a0aDb77S2c= X-Received: by 10.202.9.2 with SMTP id 2mr4528266oij.170.1520020217533; Fri, 02 Mar 2018 11:50:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.213.24 with HTTP; Fri, 2 Mar 2018 11:50:17 -0800 (PST) From: "Jason A. Donenfeld" Date: Fri, 2 Mar 2018 20:50:17 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: C tricks for efficient stack zeroing To: LKML Cc: pageexec@freemail.hu Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi list, I'm writing this email to solicit tricks for efficiently zeroing out the stack upon returning from a function. The reason this is often desirable is if the stack contains intermediate values that could assist in some form of cryptographic attack if compromised at a later point in time. It turns out many surprising things could be such an aid to an attacker, and so generally it's important to clean things up upon returning. Often times complicated cryptographic functions -- say elliptic curve scalar multiplication -- use a decent amount of stack (say, 1k or 2k), with a variety of functions, and then copy a result into a return argument. Imagine a call graph like this: do_something(u8 *output, const u8 *input) thing1(...) thing2(...) thinga(...) thingb(...) thingi(...) thingc(...) thing3(...) thing4(...) thinga(...) thingc(...) Each one of these functions have a few stack variables. The current solution is to call memzero_explicit() on each of those stack variables when each function return. But let's say that thingb uses as much or more stack as thinga. In this case, I'm wasting cycles (and gcc optimizations) by clearing the stack in both thinga and thingb, and I could probably get away with doing this in thingb only. Probably. But to hand estimate those seems a bit brittle. 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]. I thought maybe somebody on the list has thought about this problem in depth before and might have some insights to share. Regards, Jason