Received-SPF: pass (google.com: domain of linux-kernel+bounces-46776-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Wed, 31 Jan 2024 11:17:27 -0500
From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: Borislav Petkov <bp@alien8.de>
Cc: X86 ML <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/4] x86/alternatives: Do NOPs optimization on a
 temporary buffer
Message-ID: <Zbpylz6ep3skWF9d@windriver.com>
References: <20240130105941.19707-1-bp@alien8.de>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240130105941.19707-1-bp@alien8.de>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: 
	=?us-ascii?Q?xv5PQxRCSnhgJvO2c76IjJeUBHL2c6MW+452Z95Z6FAeL5cQ4tOvwU7dmOS8?=
 =?us-ascii?Q?ApXYgYubxGGT8bM0RT+22f0Xpa1jkOh+1VLKiR9YW/2TS9OqMCsGs738revH?=
 =?us-ascii?Q?tlyU/PsKFYAvizsHi/2igJiRduoPAqzt9D4D7X93cM9ZspsGg1aVD4fqvB0v?=
 =?us-ascii?Q?lqF/AnGAtstYRPWyhqHxpR7JcPnFgYjBVR+UwYrmuUJClhQWQa3lj3RO3c3A?=
 =?us-ascii?Q?l3LO7ySAsQl9t/FqYVDSEhrPY1BLIs87bk2FUBC9xQGX+ng391vl1HfTfAqg?=
 =?us-ascii?Q?+CfYC+cF7zN7iB61iKv8m70IVyPa6u8xvf20GRSXhN/W2mOupgz9rSvkODvF?=
 =?us-ascii?Q?M1NG9WxcBD5ViUnKrwxcVf50CQycPtl1UbkWaSgG51EoO+joCr+94ymqKx0d?=
 =?us-ascii?Q?qz+OkeaRvxSPJw4W6JljcDKispVU0hC5LHuUpMUxf+4ZCixVnqMVy8XbcyCN?=
 =?us-ascii?Q?mxUuEDCu5Zz38ncbwd6euDTATTzgNSjkGkW99P3KS36w7gBJYmE0UOau/gmJ?=
 =?us-ascii?Q?Sl2sfBz08bMbMmsf8emriBl8hEQaR1clQQPzr5lhV1j+j38BKLfErhxKOjdx?=
 =?us-ascii?Q?JVuFCTX1u0o5PLgbl/0nA+8LHvl4rbr97AdfaptKOtL6M46BLnYNSqSsA0KG?=
 =?us-ascii?Q?nGmrYBocsBh66ewZrW2VFcpgMf7ZM7XbFoD8tyjA7GwgnV1PJTURq6ahyn+I?=
 =?us-ascii?Q?zeOG85VbT2WmAAwhVVVF+dhUIwoA70JqqzgNN5HV1goi4gwS1p1nrj+9DYAR?=
 =?us-ascii?Q?lDlQjTQCNm4M17YZX4436uNEKu4SFMVS4XTrUhCCAMIovOOdsHdjBCnMXdK2?=
 =?us-ascii?Q?1P891YVxKF6dbbouMZjCss+nja5JrluzRnnZsWAXempn0CciR2Vi+F9654aP?=
 =?us-ascii?Q?+rmh+ZITpqwNrxgiIhzU9elY69TU0cRMl8ydAtkPrCdSYv2FoGGKQugQ7AhW?=
 =?us-ascii?Q?j8IfMF0jd6SabJ7l/OUPKQEq7HVamtRPAGFQt7Saf1LKRa7/mz8UvWaGv0Ls?=
 =?us-ascii?Q?HsWAcx30qip0AMDXsr0GuhZMr+OFsSjDUaFr4tnUwkt5Vp4EyAiDqCa6h3yX?=
 =?us-ascii?Q?tA96PNrLC8Sqd/JdX1cw9HZ3MEijoFD44n8hu9yaxEUqFepF/dIkCx6kOHOD?=
 =?us-ascii?Q?E/ZAJ42XI+OtvlU6T1acKvSH1pNQpQes6WQT52Klq9/RJwYNrKHLx4/DkaxP?=
 =?us-ascii?Q?wHtROhNQ1YVgTLweQVoMsUt0rtZwdkth3KC2ULy/sUTVAw8xeTdLS/9IQs3h?=
 =?us-ascii?Q?1J3yrmHpFepfHltbDCCYt+zE4P/9qwkW82iD2uQETdds9kPCXzeO9kfYrdu3?=
 =?us-ascii?Q?lbU60t/H/U2p3kR6jI3k1Kd5Se/r0tkI3uT1LD78sBV7+1soCjLx/m1wvwmn?=
 =?us-ascii?Q?LJGepYIeTG6fJn1+KavVffCVHzPHF2GGk+wSeo91UhIhTg3Qnmz5kWNi9duH?=
 =?us-ascii?Q?1s9bYN5taknY5XhAhbNXdaY1WgItHbwVb35kkysTbBQepUf705t7kHmFhjPn?=
 =?us-ascii?Q?KM3apjR0l1ZQ114XdQd/ZOqII6FtmgIjX7ukTGhY9ct9c+cVP80BGwxxquVV?=
 =?us-ascii?Q?rF5enUxwSDabQ/8/pFR9CSo/r7klgtEQbPrPUSoid2d6DBy6eqxrv003XQGC?=
 =?us-ascii?Q?Pw=3D=3D?=
X-OriginatorOrg: windriver.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4a5c57d7-b919-48b4-fa0f-08dc22782066
X-MS-Exchange-CrossTenant-AuthSource: BN7PR11MB2802.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jan 2024 16:17:31.7038
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 8ddb2873-a1ad-4a18-ae4e-4644631433be
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: XjabntU7sT+ERGEjaroOKI281yc1Aflxlmd7//NsYc2PPq7LqCTqNTyQurWOikAC1/2DefJEnDbrezxmFpsXBap9z0l7FslhmeXBFEB4k4E=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB7470
X-Proofpoint-ORIG-GUID: C6ezdTos_YclXlhU5eJRHBVkglWThdBm
X-Proofpoint-GUID: C6ezdTos_YclXlhU5eJRHBVkglWThdBm
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2024-01-31_09,2024-01-31_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501
 adultscore=0 clxscore=1011 impostorscore=0 mlxlogscore=563 suspectscore=0
 phishscore=0 bulkscore=0 lowpriorityscore=0 mlxscore=0 spamscore=0
 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.19.0-2401190000 definitions=main-2401310123

[[PATCH 0/4] x86/alternatives: Do NOPs optimization on a temporary buffer] On 30/01/2024 (Tue 11:59) Borislav Petkov wrote:

> From: "Borislav Petkov (AMD)" <bp@alien8.de>
> 
> Hi,
> 
> here's a small set which sprang out from my reacting to the fact that
> NOPs optimization in the alternatives code needs to happen on
> a temporary buffer like the other alternative operations - not in-place
> and cause all kinds of fun.
> 
> The result is this, which makes the alternatives code simpler and it is
> a net win, size-wise:
> 
>  1 file changed, 50 insertions(+), 72 deletions(-)
> 
> 
> Constructive feedback is always welcome!

So, I figured I would set up the same reproducer, on the same machine;
build and test a known broken NOP rewrite kernel like v6.5.0 to confirm
I could still reproduce the boot fail in approximately 2% of runs.  And
then move to testing this series.

Well, much to my annoyance my plan broke down at step one.  After about
three hours and over 400 runs, I didn't get a single fail. I still had a
known broken build from the original reporting in October of v6.5.7, so
I let that run for over 300 iterations, and also didn't get any
failures.

I have to assume that even though I'm using the same host, same scripts,
that because I was testing on Yocto master, other things have changed
since October - maybe binutils, qemu, the runqemu script,  ...  In
theory, I could try and reset Yocto back to October-ish but that is
probably of diminishing returns.  And I can't unwind the host machine
distro updates that have happened since October.

With hindsight and knowledge of what the issue was and how narrow the
window was to trigger it, I guess this shouldn't be a surprise.

So as a "next best" effort, I let this rc1-alt-v2 branch run overnight,
and after over 2200 iterations, I didn't get any boot fails.

Paul.
--

> 
> Thx.
> 
> Borislav Petkov (AMD) (4):
>   x86/alternatives: Use a temporary buffer when optimizing NOPs
>   x86/alternatives: Get rid of __optimize_nops()
>   x86/alternatives: Optimize optimize_nops()
>   x86/alternatives: Sort local vars in apply_alternatives()
> 
>  arch/x86/kernel/alternative.c | 122 ++++++++++++++--------------------
>  1 file changed, 50 insertions(+), 72 deletions(-)
> 
> -- 
> 2.43.0
>