From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 585DC36B07E for ; Fri, 8 May 2026 07:23:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778225042; cv=none; b=nD8ed3MmaUgdZGQmxplj+9xSyWAh4nA2BYmqE9l5i5Z5l2R29O2zm6qfYRUvPYXeMEQWDT1J0egCT80FsqaL6jhesvkLorS8MpYVSDGo37mCQQIlmABA1Y4yQUEYysM/frz2uq7MHVwBEdM5Vh4emR4Tyg5mxvLzcRvTQ3K1EaA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778225042; c=relaxed/simple; bh=INo/cQZ4pZ0RHpaBBv3+EwG/ILaAutKmtcjBcxtMa2U=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Qw2JsGpg5pKhLuDtLBdH1VE/aJdtOhBPfvkg+ucfJPJhOtecM+jl3WPvNt6fADhc9vL58ZGyRZiHG4AeVr3cEZlmW3K3wPX6oz/R+9UHPA7JkWUByLEXRxW5gBa/D0/t8BFN4jBZI6v/iHMhvR/w3CkPVPAAyz5HlHYWuYio8jk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=grsecurity.net; spf=pass smtp.mailfrom=opensrcsec.com; dkim=pass (2048-bit key) header.d=grsecurity.net header.i=@grsecurity.net header.b=Wvm0Uqp1; arc=none smtp.client-ip=209.85.221.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=grsecurity.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=opensrcsec.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=grsecurity.net header.i=@grsecurity.net header.b="Wvm0Uqp1" Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-448528f4e69so1078091f8f.3 for ; Fri, 08 May 2026 00:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=grsecurity.net; s=grsec; t=1778225037; x=1778829837; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=FmjdfHX+dRe5B9lTDqblb6dfaGOX8knxGR5NFidcEZw=; b=Wvm0Uqp1IYmctmpAtAMx9pPoR4Bg05FHvhhO9Wr8VzknJIMtytayFRNsEdH+zq+k9r NXxavaG15vUHqcqG02BciTFbyjnQgq/ubgvUjjNrn6+CCLspVyOx+KBHCht8EyaN+IYw XBQNMoXfwnocweEONUOWflR5jnyGq1P6pndDMlhrwTolkdosRQPi3l50XreJvynIvflD PRjMhxZ0RgeNiN91OcyXjbVMcBExpWaZnK/9ESujU65EdO2j/5yuiNFi74XSLEJoeiLT IETTP5EIG36YWQ0yHfS9rLTAhxW+z/gvM/w2/e668c2b6O5me7qHMEjHaQ7fHTaaIWk0 TlLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778225037; x=1778829837; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=FmjdfHX+dRe5B9lTDqblb6dfaGOX8knxGR5NFidcEZw=; b=rzOb2pTqcD9OXAlwtH5CbwcyaUk+Yq+8eE3TM1TYk2YpyvocFJsIHRZHPQNT9sQvkt BBnIFwkVFDGylSlsPV9MdZj2kNE/hDskJ+5mtihqCQtUhDAclomEAMixm6rZ3XbkipV3 mVHh5SPBdr3w2xnhTaG+MrSvdlw1NzOv57TvD4QqVOMrhidN9EeaEaKTaBu+wSXMeyUV t1kBUqt0Jlg0VH7/Gt7crVpKSl6vUqSrzt98SBe509kjpRot7cDF2o7njbPS8RjPjZej U6NVkTN2IbfpzzUUz+l74WJxo45m3nEpTKNZC4LgJXWPqM3SwlkGnTdDylRcPZ/Rkwtt POYQ== X-Gm-Message-State: AOJu0Yw6jvBwPx9WlymE/iizEyKMsKxA9JdsSrFuDfcP5b/pW9x5pO8C dFK+8TjJrtDG6FZD/z7wYzOCMud8hz8F5ZQTA1wbKsiMNUmoxIHZ9v7pCabQIOCk6cQ= X-Gm-Gg: AeBDievcoEksPXBhHAC3UysQPyZ/tP06Xl8vnaPwU+HG5ofp+uHspvwPyW2CWv/UyhB pytMJAI5bR1lKVwMEgKjYX8Y3QxAJT2zlAHA4F5VHj12WPVYVvve5iV69GEDyMHet7NH9gKih5V OKzW/tVTMohJpcTeVW+f1nF6q1rd6v1l9ZBXgX6erZhx74J7YeGANngC93rade3BMC46R/dCVI1 RIISZPbcRbOMnohXih+HV/S3xhg5A8C20ev/OU0evznuH7VIekasEaisTL6vhtV8py32n0nPEcl RKGPlxdPx0wytTV72PL2ytsqOtAlAUVAhO9AtHcgJP6fHlCv3xjgAJVrJRst3CV7iylO0j93+Pa fH5wwxtujf7p2MJupLZVvVdBjFbsal1UNHM/Fm7Oww7tdRFhQVnTj7QpHaxkqHLNx+mzDgVbqeM LqRj5M4cR/CwUhbXp+DVI2MLRV4obqVGPi/hvCj4oQ0g1dycVHYwE0s6U0T0lJ+pgl7Dx1gTcuy KXPMdD/HnI4+8Tz+Cvk5zEfqGjEoT41gMGf43tV/wkQ7EIG9199k93p7fUy+I5DwJI= X-Received: by 2002:a05:600c:524e:b0:489:1d74:56d with SMTP id 5b1f17b1804b1-48e676c14b9mr20837485e9.29.1778225037251; Fri, 08 May 2026 00:23:57 -0700 (PDT) Received: from ?IPV6:2003:fa:af26:200:51a:ef03:a698:a1fc? (p200300faaf260200051aef03a698a1fc.dip0.t-ipconnect.de. [2003:fa:af26:200:51a:ef03:a698:a1fc]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48e6428f77csm20404505e9.0.2026.05.08.00.23.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 May 2026 00:23:56 -0700 (PDT) Message-ID: <5b605463-533f-46ae-833a-b6c8f9bcfae1@grsecurity.net> Date: Fri, 8 May 2026 09:23:55 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] x86/shstk: Provide kernel command line knob to disable To: "Edgecombe, Rick P" , "Hansen, Dave" , "bp@alien8.de" , "dave.hansen@linux.intel.com" , "peterz@infradead.org" , "x86@kernel.org" , "mingo@redhat.com" , "tglx@kernel.org" Cc: "linux-kernel@vger.kernel.org" , "Gao, Chao" References: <20260402173606.1096172-1-minipli@grsecurity.net> <3d7c8d26-558d-40ef-9ad9-3a5100eed9e5@grsecurity.net> <739e4dd0-84a3-4b37-8cc3-b7ec59737010@intel.com> <4cffee5d2886129e621d3011db1d00a236869d1d.camel@intel.com> <457a77eb-2a77-4873-b2a1-24f5110a0393@grsecurity.net> Content-Language: en-US, de-DE From: Mathias Krause Autocrypt: addr=minipli@grsecurity.net; keydata= xsDNBF4u6F8BDAC1kCIyATzlCiDBMrbHoxLywJSUJT9pTbH9MIQIUW8K1m2Ney7a0MTKWQXp 64/YTQNzekOmta1eZFQ3jqv+iSzfPR/xrDrOKSPrw710nVLC8WL993DrCfG9tm4z3faBPHjp zfXBIOuVxObXqhFGvH12vUAAgbPvCp9wwynS1QD6RNUNjnnAxh3SNMxLJbMofyyq5bWK/FVX 897HLrg9bs12d9b48DkzAQYxcRUNfL9VZlKq1fRbMY9jAhXTV6lcgKxGEJAVqXqOxN8DgZdU aj7sMH8GKf3zqYLDvndTDgqqmQe/RF/hAYO+pg7yY1UXpXRlVWcWP7swp8OnfwcJ+PiuNc7E gyK2QEY3z5luqFfyQ7308bsawvQcFjiwg+0aPgWawJ422WG8bILV5ylC8y6xqYUeSKv/KTM1 4zq2vq3Wow63Cd/qyWo6S4IVaEdfdGKVkUFn6FihJD/GxnDJkYJThwBYJpFAqJLj7FtDEiFz LXAkv0VBedKwHeBaOAVH6QEAEQEAAc0nTWF0aGlhcyBLcmF1c2UgPG1pbmlwbGlAZ3JzZWN1 cml0eS5uZXQ+wsERBBMBCgA7AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAFiEEd7J359B9 wKgGsB94J4hPxYYBGYYFAmBbH/cCGQEACgkQJ4hPxYYBGYaX/gv/WYhaehD88XjpEO+yC6x7 bNWQbk7ea+m82fU2x/x6A9L4DN/BXIxqlONzk3ehvW3wt1hcHeF43q1M/z6IthtxSRi059RO SarzX3xfXC1pc5YMgCozgE0VRkxH4KXcijLyFFjanXe0HzlnmpIJB6zTT2jgI70q0FvbRpgc rs3VKSFb+yud17KSSN/ir1W2LZPK6er6actK03L92A+jaw+F8fJ9kJZfhWDbXNtEE0+94bMa cdDWTaZfy6XJviO3ymVe3vBnSDakVE0HwLyIKvfAEok+YzuSYm1Nbd2T0UxgSUZHYlrUUH0y tVxjEFyA+iJRSdm0rbAvzpwau5FOgxRQDa9GXH6ie6/ke2EuZc3STNS6EBciJm1qJ7xb2DTf SNyOiWdvop+eQZoznJJte931pxkRaGwV+JXDM10jGTfyV7KT9751xdn6b6QjQANTgNnGP3qs TO5oU3KukRHgDcivzp6CWb0X/WtKy0Y/54bTJvI0e5KsAz/0iwH19IB0vpYLzsDNBF4u6F8B DADwcu4TPgD5aRHLuyGtNUdhP9fqhXxUBA7MMeQIY1kLYshkleBpuOpgTO/ikkQiFdg13yIv q69q/feicsjaveIEe7hUI9lbWcB9HKgVXW3SCLXBMjhCGCNLsWQsw26gRxDy62UXRCTCT3iR qHP82dxPdNwXuOFG7IzoGBMm3vZbBeKn0pYYWz2MbTeyRHn+ZubNHqM0cv5gh0FWsQxrg1ss pnhcd+qgoynfuWAhrPD2YtNB7s1Vyfk3OzmL7DkSDI4+SzS56cnl9Q4mmnsVh9eyae74pv5w kJXy3grazD1lLp+Fq60Iilc09FtWKOg/2JlGD6ZreSnECLrawMPTnHQZEIBHx/VLsoyCFMmO 5P6gU0a9sQWG3F2MLwjnQ5yDPS4IRvLB0aCu+zRfx6mz1zYbcVToVxQqWsz2HTqlP2ZE5cdy BGrQZUkKkNH7oQYXAQyZh42WJo6UFesaRAPc3KCOCFAsDXz19cc9l6uvHnSo/OAazf/RKtTE 0xGB6mQN34UAEQEAAcLA9gQYAQoAIAIbDBYhBHeyd+fQfcCoBrAfeCeIT8WGARmGBQJeORkW AAoJECeIT8WGARmGXtgL/jM4NXaPxaIptPG6XnVWxhAocjk4GyoUx14nhqxHmFi84DmHUpMz 8P0AEACQ8eJb3MwfkGIiauoBLGMX2NroXcBQTi8gwT/4u4Gsmtv6P27Isn0hrY7hu7AfgvnK owfBV796EQo4i26ZgfSPng6w7hzCR+6V2ypdzdW8xXZlvA1D+gLHr1VGFA/ZCXvVcN1lQvIo S9yXo17bgy+/Xxi2YZGXf9AZ9C+g/EvPgmKrUPuKi7ATNqloBaN7S2UBJH6nhv618bsPgPqR SV11brVF8s5yMiG67WsogYl/gC2XCj5qDVjQhs1uGgSc9LLVdiKHaTMuft5gSR9hS5sMb/cL zz3lozuC5nsm1nIbY62mR25Kikx7N6uL7TAZQWazURzVRe1xq2MqcF+18JTDdjzn53PEbg7L VeNDGqQ5lJk+rATW2VAy8zasP2/aqCPmSjlCogC6vgCot9mj+lmMkRUxspxCHDEms13K41tH RzDVkdgPJkL/NFTKZHo5foFXNi89kA== In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 07.05.26 21:53, Edgecombe, Rick P wrote: > On Thu, 2026-05-07 at 15:39 +0200, Mathias Krause wrote: >> On 07.05.26 00:45, Edgecombe, Rick P wrote: >>> On Wed, 2026-05-06 at 12:03 -0700, Dave Hansen wrote: >>>> Is there a reason that clearcpuid=shstk doesn't work in this case? I >>>> guess shstk and ibt are peers, but I was kinda hoping we'd stop adding >>>> these for every single CPU feature at _some_ point. >>> >>> Oh yea, for the reason of "debugging related issues during early boot" >>> clearcpuid of shstk and ibt should be fine. It taints the kernel, but should be >>> fine for debugging? If I'm reading this right, the kernel does the clearcpuid >>> processing before setting up CET bits. >> >> Unfortunately, neither 'clearcpuid=shstk' nor 'clearcpuid=user_shstk' >> are of any help. >> >> The former doesn't work because X86_FEATURE_SHSTK has no procfs-visible >> string attached, therefore no entry in x86_cap_flags[] and therefore >> can't be found via "shstk" in parse_set_clear_cpuid(). >> >> The latter only clears X86_FEATURE_USER_SHSTK which is a synthetic >> feature bit but setup_cet() only looks for X86_FEATURE_SHSTK. > > So alternatively we could just do: > > diff --git a/tools/arch/x86/include/asm/cpufeatures.h > b/tools/arch/x86/include/asm/cpufeatures.h > index c3b53beb13007..270341e786f28 100644 > --- a/tools/arch/x86/include/asm/cpufeatures.h > +++ b/tools/arch/x86/include/asm/cpufeatures.h > @@ -392,7 +392,7 @@ > #define X86_FEATURE_OSPKE (16*32+ 4) /* "ospke" OS Protection Keys > Enable */ > #define X86_FEATURE_WAITPKG (16*32+ 5) /* "waitpkg" > UMONITOR/UMWAIT/TPAUSE Instructions */ > #define X86_FEATURE_AVX512_VBMI2 (16*32+ 6) /* "avx512_vbmi2" Additional > AVX512 Vector Bit Manipulation s/ > -#define X86_FEATURE_SHSTK (16*32+ 7) /* Shadow stack */ > +#define X86_FEATURE_SHSTK (16*32+ 7) /* "shstk" Shadow stack */ > #define X86_FEATURE_GFNI (16*32+ 8) /* "gfni" Galois Field New > Instructions */ > #define X86_FEATURE_VAES (16*32+ 9) /* "vaes" Vector AES */ > #define X86_FEATURE_VPCLMULQDQ (16*32+10) /* "vpclmulqdq" Carry-Less > Multiplication Double Quadword */ I explicitly didn't propose that as I was under the assumption, hiding that feature bit is intentional. But, as it was you who added that bit like that in 701fb66d576e ("x86/cpufeatures: Add CPU feature flags for shadow stacks") and is now proposing otherwise, I won't object either. > > Now that KVM uses this this feature independently of X86_FEATURE_USER_SHSTK, it > might be good to have the plain HW shstk feature exposed for just normal runtime > user use. (+Chao, for KVM CET) But that sounds more like having the need for an official chicken bit, like I was proposing, no? Using 'clearcpuid=shstk' as a workaround for whatever KVM bugs, similar in spirit to 'nousershstk', but without the kernel taint? >>> >>> I'm remembering we actually already have a "nousershstk" too, which covers the >>> "userspace init cet violations break boot" usage. >> >> Oh, interesting. That'd be the equivalent of 'clearcpuid=user_shstk', right? > > Right, except for no taint. > >> >>> >>> What that doesn't do though, is clear CR4.CET. With nousershstk, KVM can still >>> use CET. So that is what is missing. A way to clear CR4.CET without tainting the >>> kernel when HW supports CET. Do we need it? >>> >> >> Right! Clearing, or, moreover, not setting CR4.CET=1 is what I need for >> the debugging use cases I have in mind and had to hack around a few >> times in the past. >> >> Case in point, the last debugging session involved a bug with CPU >> hotplug where the E-cores did not reset their IA32_S_CET MSR on #INIT >> but the P-cores did (which wasn't the bug, as that's perfectly fine >> SDM-documented behaviour (not resetting, that is)). > > But the above works for this case, right? The taint doesn't matter for > debugging? For *me*, 'clearcpuid=shstk,ibt' would be sufficient for my debugging needs. It's just a question if there's more demand beside some random kernel hacker needing a knob to disable potential problematic features, i.e. do we expect actual *end users* having a need to fully disable CET shadow stacks too? Thanks, Mathias