Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp5997546rwl; Mon, 9 Jan 2023 02:50:36 -0800 (PST) X-Google-Smtp-Source: AMrXdXtUbrCYy/zL1Ucvps+QhvYGXW32R0i15On7wwpsFco5/ok/wLT/rZ1gUx3sTzIFROsW+lDd X-Received: by 2002:a05:6402:2a04:b0:47a:f54c:1ba4 with SMTP id ey4-20020a0564022a0400b0047af54c1ba4mr61365838edb.25.1673261436324; Mon, 09 Jan 2023 02:50:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673261436; cv=none; d=google.com; s=arc-20160816; b=A5VOXqbh71x2PXT5+c+gxEA/oaS8IuCCkL4nREpXW7wNl9VRLNOU3zB1cwcZR3SWPn EDB3l9cWZH+rwK1VbM9xSOLjaJUFdjj2A/5CK736F1CJMF/To36s03aprRM+TjosFRXM UpXavYUAVdRVj6F1+bRZcKxAb16TBOFThscDbo8YYOY2RyHfJwLQLiIivO1vKt1cF+/q MECdBtxkzBTxjU0VYrY4HD+h36HilWayWVVbl6TjiLLDfKzFC4eXNIMAsfOMCUmiWs13 LHcmCmeofwzKSZMOSABixw2+xTHnlfryKQGtY/B2rhpVp6sluFDl34jECe3SxdCmScWO /bHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:sender:dkim-signature; bh=+15hlIC73/i7RS8+s7sRGfxlZ9giO8ORM4NySaQdUqw=; b=h0r6G3VG0/wb0qnyFBi/gtB7nSQRiLlUAzpCOHkYJTUKByEEelMeJMS3I3XH+Qsipt XIKVC0Z7tWN0awIqwl7PKGbHO/PL+GZKdM3+l4vj7ewzGZ/o/q6gfc1j1G+88Vo+8xZw TCFgt39QxEGQLU4/Z11YJBA8CtpmXz6jsYoOY170TrOw5eQtAnfQCdFACQGVSdxfrFUu SD2EcPYnYpObgmqrsKRM2dr0uDsnW//7KEoqy/Z2lojqgkViy08a9KbYweZcSv+Cl0pb miK031Z36BDbJVp0kABFBKbXs9hpvn29OLBZo/RNthauxby5oLSdScAbGDJPM59VYCC/ dZIw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=QTQPm9dT; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w22-20020a05640234d600b0046b953601cbsi9879318edc.27.2023.01.09.02.50.23; Mon, 09 Jan 2023 02:50:36 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=QTQPm9dT; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236231AbjAIKkw (ORCPT + 53 others); Mon, 9 Jan 2023 05:40:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51590 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236629AbjAIKkr (ORCPT ); Mon, 9 Jan 2023 05:40:47 -0500 Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7B79018E30 for ; Mon, 9 Jan 2023 02:40:44 -0800 (PST) Received: by mail-wm1-x32e.google.com with SMTP id ay40so5934900wmb.2 for ; Mon, 09 Jan 2023 02:40:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=+15hlIC73/i7RS8+s7sRGfxlZ9giO8ORM4NySaQdUqw=; b=QTQPm9dTr2P+uNEcd2haK7oI3EsCl2CiT2PFiC+9aWUECvzpl/1dX6RUi3w1wAwUZU 98OwaBy0wphzoRUfHAWXfy4gjFFF1gwinlNbYHtD1osfx3Sgi2tnGQlCk0uJ91wK10gd u/L3arQWNbOOWQsr+CR3u3RaMD9aBfinrma9rQWocpt5lVUs1jka3UDyeP9zSrZxMUaC PThOTZWFQSwdd4C2S5sar9HLCOYEEHdIOmptddVdbqoP3ao/a6hANmk2hfUY8NyQxHTu OAcIeUwstXsEUK1gUEYtSxGdV/TrWoZvLgqVKzddvL5TY7tv1OlENjOvdN355nLNRNgM TUpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+15hlIC73/i7RS8+s7sRGfxlZ9giO8ORM4NySaQdUqw=; b=zjC2Vh2R3Hvd0q2WB/XKIqISb26jKuMBg4y1g9YUb7Y/VSPGiGypjXiDw0R35GUxPd buXgfnmheJyLcApXi3V2NFO3+aSUBgEBDsMXxEAD7Q92mfC5GSPcrikmxZohUAWuPaVm 23ARVQnsa6cqVpHKcY/dtA+7LafeZlDi9acLptk9PuiTAZGVU368+BxkXu4OoA5ipjJX I8l+MLeVV5PXjmo0IwlA2NlkD7m5bMUYbr6ujFSJisG7oB1HWzv2wSrLmU7qwOkXYihn lPjc6QUwsOMvCXq7LU8/iejx7nS69lRJQLxaC7HHTtm2SB0BIkhiBuRS+wZHqYAzMkNQ z+bA== X-Gm-Message-State: AFqh2kp/BZvNUulRJtVBBfCkPGT/IzBtcF3TJ7h87A+A/nlq5PT9fzEk ADTtRfQXJ4SFEARiQGo6zc4= X-Received: by 2002:a05:600c:2252:b0:3d3:5d8b:7af with SMTP id a18-20020a05600c225200b003d35d8b07afmr48782803wmm.41.1673260843065; Mon, 09 Jan 2023 02:40:43 -0800 (PST) Received: from gmail.com (1F2EF719.nat.pool.telekom.hu. [31.46.247.25]) by smtp.gmail.com with ESMTPSA id k4-20020a05600c1c8400b003d22528decesm17703586wms.43.2023.01.09.02.40.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Jan 2023 02:40:42 -0800 (PST) Sender: Ingo Molnar Date: Mon, 9 Jan 2023 11:40:40 +0100 From: Ingo Molnar To: "Maciej W. Rozycki" Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] x86: Disable kernel stack offset randomization for !TSC Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Maciej W. Rozycki wrote: > For x86 kernel stack offset randomization uses the RDTSC instruction, > which causes an invalid opcode exception with hardware that does not > implement this instruction: > @@ -85,7 +86,8 @@ static inline void arch_exit_to_user_mod > * Therefore, final stack offset entropy will be 5 (x86_64) or > * 6 (ia32) bits. > */ > - choose_random_kstack_offset(rdtsc() & 0xFF); > + if (cpu_feature_enabled(X86_FEATURE_TSC)) > + choose_random_kstack_offset(rdtsc() & 0xFF); > } While this is an obscure corner case, falling back to 0 offset silently feels a bit wrong - could we at least attempt to generate some unpredictability in this case? It's not genuine entropy, but we could pass in a value that varies from task to task and which is not an 'obviously known' constant value like the 0 fallback? For example the lowest 8 bits of the virtual page number of the current task plus the lowest 8 bits of jiffies should vary from task to task, has some time dependence and is cheap to compute: (((unsigned long)current >> 12) + jiffies) & 0xFF This combined with the per-CPU forward storage of previous offsets: #define choose_random_kstack_offset(rand) do { \ if (static_branch_maybe(CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT, \ &randomize_kstack_offset)) { \ u32 offset = raw_cpu_read(kstack_offset); \ offset ^= (rand); \ raw_cpu_write(kstack_offset, offset); \ } \ Should make this reasonably hard to guess for long-running tasks even if there's no TSC - and make it hard to guess even for tasks whose creation an attacker controls, unless there's an info-leak to rely on. Thanks, Ingo