From patchwork Mon Dec 26 19:30:34 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Peter_M=C3=BCller?= X-Patchwork-Id: 6334 Return-Path: Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by web04.haj.ipfire.org (Postfix) with ESMTPS id 4Ngnv75Wk0z3wcv for ; Mon, 26 Dec 2022 19:30:43 +0000 (UTC) Received: from mail02.haj.ipfire.org (mail02.haj.ipfire.org [172.28.1.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail02.haj.ipfire.org", Issuer "R3" (verified OK)) by mail01.ipfire.org (Postfix) with ESMTPS id 4Ngnv70KP1z15G; Mon, 26 Dec 2022 19:30:43 +0000 (UTC) Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4Ngnv70FZmz2xqw; Mon, 26 Dec 2022 19:30:43 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4Ngnv608s4z2xmd for ; Mon, 26 Dec 2022 19:30:42 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384)) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4Ngnv36NVpzwp for ; Mon, 26 Dec 2022 19:30:38 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1672083041; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=E3ONbktdFbMtb1COqbCex/m5ffHBlW3IcnsBKceTDM8=; b=J4t2s4oAn1wR0TP7bXw1eK5RxH+VoajxovopmhX8NWa/4GDi9t60N7fsDCCjQ2/77TJy59 WSe5zEuIrnHXZrDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1672083041; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=E3ONbktdFbMtb1COqbCex/m5ffHBlW3IcnsBKceTDM8=; b=CP7msEzDy9bEn9kbqJqd8CIU/PceOTfXcqjadXmdno+4G45GSlaslJ1at96xjksFGGIeQP WfMpIXCOo8tQ1uNdp2cALSJ9XYq1pqlZkj9/FnFbYg7NB4kvpJ50a6+n9PD7W3uZ6p/sPO NQ3ayhpYM4Ydd0PPp+AOvR5GN8Kui7/NmRtM9eI6/5r1YOE6Cte1qiNi/1nv0YP546sQaX JQB7aArwbodY5ZBkgWvgDD0u9Uez8FGw9UTibYNBr5rM1tp+q6TbZ3q3Iu/ODCS/3VkMIL wSRXX8z3EM+6PkiF6yLJjXcKNbG4eLZHIiRvMnK0zWLFcCuw1Rt/sTqPqGvAog== Message-ID: <0d75d16c-8e27-f49d-f1b4-548a52a7a763@ipfire.org> Date: Mon, 26 Dec 2022 19:30:34 +0000 MIME-Version: 1.0 Subject: [PATCH 18/21] linux: Poison kernel stack before returning from syscalls Content-Language: en-US To: development@lists.ipfire.org References: <0e60a1de-6210-835e-54a4-ec5e3128e42e@ipfire.org> From: =?utf-8?q?Peter_M=C3=BCller?= In-Reply-To: <0e60a1de-6210-835e-54a4-ec5e3128e42e@ipfire.org> X-BeenThere: development@lists.ipfire.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFire development talk List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: development-bounces@lists.ipfire.org Sender: "Development" From the kernel documentation: > This option makes the kernel erase the kernel stack before > returning from system calls. This has the effect of leaving > the stack initialized to the poison value, which both reduces > the lifetime of any sensitive stack contents and reduces > potential for uninitialized stack variable exploits or information > exposures (it does not cover functions reaching the same stack > depth as prior functions during the same syscall). This blocks > most uninitialized stack variable attacks, with the performance > impact being driven by the depth of the stack usage, rather than > the function calling complexity. > > The performance impact on a single CPU system kernel compilation > sees a 1% slowdown, other systems and workloads may vary and you > are advised to test this feature on your expected workload before > deploying it. > > This plugin was ported from grsecurity/PaX. Let's give it a try. A 1% increase in compile time does not bother us too much, and given that this is enabled in IPFire 3.x as well, we may as well take the opportunity to gain experience with this in the field. Signed-off-by: Peter Müller --- config/kernel/kernel.config.x86_64-ipfire | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/config/kernel/kernel.config.x86_64-ipfire b/config/kernel/kernel.config.x86_64-ipfire index f1d6c2ede..3d9e01e38 100644 --- a/config/kernel/kernel.config.x86_64-ipfire +++ b/config/kernel/kernel.config.x86_64-ipfire @@ -6915,7 +6915,10 @@ CONFIG_GCC_PLUGIN_STRUCTLEAK=y # CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF is not set CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL=y # CONFIG_GCC_PLUGIN_STRUCTLEAK_VERBOSE is not set -# CONFIG_GCC_PLUGIN_STACKLEAK is not set +CONFIG_GCC_PLUGIN_STACKLEAK=y +CONFIG_STACKLEAK_TRACK_MIN_SIZE=100 +# CONFIG_STACKLEAK_METRICS is not set +# CONFIG_STACKLEAK_RUNTIME_DISABLE is not set CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y # CONFIG_INIT_ON_FREE_DEFAULT_ON is not set CONFIG_CC_HAS_ZERO_CALL_USED_REGS=y