From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4B8B11CAB3 for ; Wed, 25 Mar 2026 16:39:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.136 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774456767; cv=none; b=q3/TMaYFZlOt9RncUzGBGbwoaupV7w389ZqQjw+OUXHR374W9WpadvLYksY721wQrfiKaEad4WEqKP1j+9j4XUXb3mVoEibLHRqNma6BTaA2GVIQ88+AjEMXt6Hd9XUUKdMR2gTSa4ropPmfmCPrI1iDcOk7MoR/xuZ0TMVQ0x4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774456767; c=relaxed/simple; bh=SbsQqgEa7EUaRxUSkGOHouozYf/KhLOIOrYrSQAqfps=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=VMlhg/khY2tlbxZ7TLV5fHwhdX8Tl2wLlyl5EtxY1BXj0jVz497aQZzhKuyh7YHXIMXoAAJ4hg/+R10yTFeL5gBWRgGVFOMugTES3H9cArGF6XcPpxkH7F2zVY6E4L63ixEqGbUwouQ54jEedsX/xlknDVKAgz9UIFTtu7kYNSc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com; spf=pass smtp.mailfrom=zytor.com; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b=RPzk8c+H; arc=none smtp.client-ip=198.137.202.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zytor.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b="RPzk8c+H" Received: from [IPV6:2601:646:8081:9481:619:3ffd:957c:6748] ([IPv6:2601:646:8081:9481:619:3ffd:957c:6748]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 62PGMeT93169071 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 25 Mar 2026 09:22:40 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 62PGMeT93169071 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026022301; t=1774455761; bh=f4YnPqemjRNmKlcS4ejwbwiZvjZjs3U28a0ZpSQpJN4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=RPzk8c+HrfQrtC/VfUuzmPmfwr6TH8VyBz08jLBdmTaYqRT5x+vjiTHEfh28kmxrP 4NRxq/1d7+qB44T1CBqJIRKnjpLXwBlIH5McZu8Kvju08JBCqzYE+EzFKWMlJiFhNo 6JCDq30Sm7J85eY0HpgpeZRh8sNDnsnIErO5GVpxkl6JvVaCdYNTd/ezjOBFaXjFIv MM48Y5JyOLg5pTLV131RdX2neb10F2Kt9KNLSAvQeSI6yIJ38o5pafIlLIDzfJ0prN WvaIMsNHIUvtUucXzumOoz74oL+WROWKhZBIsBJrocx7KeWX49FtD7GNxvfBpoivvQ TXyro28ofj5rQ== Message-ID: <8bb320bb-62e0-4252-8ef9-9b6aa04b02ba@zytor.com> Date: Wed, 25 Mar 2026 09:22:35 -0700 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 0/2] x86/fred: enable FRED by default To: Borislav Petkov , Sohil Mehta Cc: Xin Li , Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, "Peter Zijlstra (Intel)" , Kees Cook , "Ahmed S. Darwish" , linux-kernel@vger.kernel.org References: <20260323201510.1537333-1-hpa@zytor.com> <84489fd4-aa23-4ba1-b5a1-c1baafb6718d@intel.com> <927AE575-3C10-427E-9C4B-0238CBF8301E@zytor.com> <763cbc92-fda0-454e-a2dd-919671db15c3@zytor.com> <1fb5ae44-d443-414f-9d63-3efce4b73bc9@intel.com> <8cba266d-4d3d-4058-a4b4-b937395e50e3@intel.com> <20260324195351.GOacLrz90cagXTepUx@fat_crate.local> Content-Language: en-US, sv-SE From: "H. Peter Anvin" In-Reply-To: <20260324195351.GOacLrz90cagXTepUx@fat_crate.local> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2026-03-24 12:53, Borislav Petkov wrote: > On Tue, Mar 24, 2026 at 10:19:00AM -0700, Sohil Mehta wrote: >> With FRED proposed to be default on, I think we should match the above >> and only let fred=off disable it. All other inputs should be ignored. > > So we have only said so far that "on" enables FRED and "off" disables it. And > we can do that by carving out the FRED option parsing into a separate function > and acting only on those and ignoring the rest. > > All those other fred=X things should simply be ignored. > Well, that's easy. I just didn't want to change existing behavior. If that is your policy decision then I'm fine with that. We don't even need a new function; it is actually an even smaller change to the code than this patchset version, so I'll rev the patchset. It WOULD be good to have a global function to parse boolean arguments in a kernel-coherent manner, but that is out of scope for this patchset. >> I agree. In general, we shouldn't even need special command line >> parameters to *disable* features. clearcpuid=fred would have been >> equivalent to fred=off if it didn't taint the kernel. I don't know the >> exact history about why the taint is needed. > > Because you should not poke at clearing CPUID features unless you know what > you're doing and this cmdline option should not exist at all. But we have it > so... > Well, it is useful for testing code paths for legacy hardware. -hpa