From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 DDAB218AE2 for ; Tue, 17 Mar 2026 02:33:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773714786; cv=none; b=hNYcGymIuWEIQ9LtdyjxYYTv+4zmvcGI/KWIA8j7uxroRbRwHgA6D+gxWKaJYjLntIktJ4D9uRbPPMiXXXDkyhYwAYXM1qSftQcxCWXHVDD+LgDc5OSuUnhT1QSo0/XJ7hsvl7r/xWSV7kzqi8a71ZFsRlrhS81+EAwYYFNF56E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773714786; c=relaxed/simple; bh=VCeY6D/4cQ1HkxnpoFOg7p4rM6qQxbg2LRwf7xYnC5c=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=KHu3l/OlCTiwrMK6FD2DLkadUL02cJ0nJ6vsaO90P9jtjSPQZEiXVcTvHchOLYTb1qN7kfKF2IIpo1KgYpQHFAbaOPTRSbdMk8Fq0QBcD62VVd9Q1KwmeSRMUwb2NaOqyt0dujfrIKVkEPWkSV3x8qrT0A+5ieciHo2oWx3zuqc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rYPeFGlv; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rYPeFGlv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 11492C19421; Tue, 17 Mar 2026 02:33:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773714786; bh=VCeY6D/4cQ1HkxnpoFOg7p4rM6qQxbg2LRwf7xYnC5c=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=rYPeFGlvzsS87ljDZwAvVbdGu8/HqPUTzScxlbsnM2VkchOGV59QwnCxCa/2y+3tH 5V5sh5zw3mqXFvGEFWqFdq80SlrUIHdORbBfwZySc9BbBT2h2xDVpcpkx/cTPKUdfk 3kvNtq3DxX5TF8sXVAhwFSR0ZJsjY/L174fFhtCgrF8dQjpdrie2ITk9snGAZj25S3 yZb/g+2PaNa5YVBIbH2iRtLAfFKzGgsMorZF7TbyJ8Z3k/ld0fy6PvSJhScp9jmb41 elyFakiSCrE2wOyOL+c2KjpFdswE5E6RXEaTInp19oRujoCwkCNoijmkMPtu48j7o8 TF1YCPGc9FHUA== Message-ID: <24dfdd62-add4-47dd-a759-916d030b8306@kernel.org> Date: Mon, 16 Mar 2026 21:33:04 -0500 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 v5 5/5] x86/CPU/AMD: Print AGESA string from DMI additional information entry To: Borislav Petkov Cc: Yazen Ghannam , Jean Delvare , linux-kernel@vger.kernel.org References: <20260123213056.861317-1-superm1@kernel.org> <20260123213056.861317-6-superm1@kernel.org> <20260315131416.GVabawqKuPkYKShXpn@fat_crate.local> <20260315205629.GBabcc_aHtsl8QS5vL@fat_crate.local> Content-Language: en-US From: Mario Limonciello In-Reply-To: <20260315205629.GBabcc_aHtsl8QS5vL@fat_crate.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 3/15/26 3:56 PM, Borislav Petkov wrote: > On Sun, Mar 15, 2026 at 10:14:48AM -0500, Mario Limonciello wrote: >> FYI - you're replying to the v5 not the v6 [1]. > > Whoops, sorry about that. > > It looks I've still used the right set tho: > > v6_20260307_superm1_print_agesa_version_at_bootup.mbx > > :) > >> I did add a check for info->count < 1, but that's not what you were actually >> looking for. Do you have a suggestion for an upper limit to bound things? >> >> I was thinking something like this: >> >> #define DMI_LIMIT 10 >> int limit = info -> count > DMI_LIMIT ? DMI_LIMIT : info->count; >> end = (void *)info + limit * info->header.length; > > So that Zen5 laptop here says: > > [ 0.853836] dmi_scan_additional: next: 0xffffc9000051950c, end: 0xffffc90000519515, hdr length: 14 > [ 0.854364] entry 0: length: 9 > [ 0.854576] AGESA: StrixPI-FP8 1.0.0.1d > > So after that first loop pass we have > > next = 0xffffc9000051950c + 9 = 0xffffc90000519515 > > And we should terminate. So I guess that's not a lot of entries. > > In terms of limiting, I'd do something like: > > /* A generous max size for the additional DMI entries */ > #define MAX_DMI_ADDITIONAL_ENTRIES_LEN 256 > > if (info->header.length > MAX_DMI_ADDITIONAL_ENTRIES_LEN) > info->header.length = MAX_DMI_ADDITIONAL_ENTRIES_LEN; > > And now you have a sane upper limit and we don't rely on any numbers the BIOS > is telling us. > > Thx. > But that can't actually happen. info->header.length is u8. So we're never going to end up with that many entries such that it would exhaust the check.