linux-kernel - Re: [PATCH] LoongArch: Correct the calculation logic of thread

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <EF30F5A4B2075D4A+9d7c2fe9-b621-46e1-8dc0-6a0dea42292c@uniontech.com>
Date: Wed, 26 Nov 2025 19:06:45 +0800
From: Qiang Ma <maqianga@...ontech.com>
To: Hengqi Chen <hengqi.chen@...il.com>
Cc: loongarch@...ts.linux.dev, linux-kernel@...r.kernel.org,
 Huacai Chen <chenhuacai@...nel.org>, kernel@...0n.name
Subject: Re: [PATCH] LoongArch: Correct the calculation logic of thread_count


在 2025/11/26 18:14, Qiang Ma 写道:
>
> 在 2025/11/26 18:06, Hengqi Chen 写道:
>> On Wed, Nov 26, 2025 at 5:47 PM Qiang Ma <maqianga@...ontech.com> wrote:
>>>
>>> On Wed, Nov 26, 2025 at 10:37 AM Qiang Ma<maqianga@...ontech.com> 
>>> wrote:
>>>
>>>>    For thread_count, the current calculation method has a maximum 
>>>> of 255,
>>>>    which may not be sufficient in the future. Therefore, we are 
>>>> correcting
>>>>    it now.
>>>>
>>>>    Reference: SMBIOS Specification, 7.5 Processor Information (Type 
>>>> 4)[1]
>>>>
>>>> [1]:https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.9.0.pdf
>>>>
>>>>    Signed-off-by: Qiang Ma<maqianga@...ontech.com>
>>>>    ---
>>>>     arch/loongarch/kernel/setup.c | 9 ++++++++-
>>>>     1 file changed, 8 insertions(+), 1 deletion(-)
>>>>
>>>>    diff --git a/arch/loongarch/kernel/setup.c 
>>>> b/arch/loongarch/kernel/setup.c
>>>>    index 25a87378e48e..760f5ce44384 100644
>>>>    --- a/arch/loongarch/kernel/setup.c
>>>>    +++ b/arch/loongarch/kernel/setup.c
>>>>    @@ -56,6 +56,7 @@
>>>>     #define SMBIOS_FREQLOW_MASK            0xFF
>>>>     #define SMBIOS_CORE_PACKAGE_OFFSET     0x23
>>>>     #define SMBIOS_THREAD_PACKAGE_OFFSET   0x25
>>>>    +#define SMBIOS_THREAD_PACKAGE_2_OFFSET 0x2E
>>>>     #define LOONGSON_EFI_ENABLE            (1 << 3)
>>>>
>>>>     unsigned long fw_arg0, fw_arg1, fw_arg2;
>>>>    @@ -120,13 +121,19 @@ static void __init parse_cpu_table(const 
>>>> struct dmi_header *dm)
>>>>     {
>>>>            long freq_temp = 0;
>>>>            char *dmi_data = (char *)dm;
>>>>    +       u8 thread_count;
>>>>    +       u16 thread_count2;
>>>>
>>>>            freq_temp = ((*(dmi_data + SMBIOS_FREQHIGH_OFFSET) << 8) +
>>>>                            ((*(dmi_data + SMBIOS_FREQLOW_OFFSET)) & 
>>>> SMBIOS_FREQLOW_MASK));
>>>>            cpu_clock_freq = freq_temp * 1000000;
>>>>
>>>>            loongson_sysconf.cpuname = (void *)dmi_string_parse(dm, 
>>>> dmi_data[16]);
>>>>    -       loongson_sysconf.cores_per_package = *(dmi_data + 
>>>> SMBIOS_THREAD_PACKAGE_OFFSET);
>>>>    +       thread_count = *(dmi_data + SMBIOS_THREAD_PACKAGE_OFFSET);
>>>>    +       thread_count2 = *(u16 *)(dmi_data + 
>>>> SMBIOS_THREAD_PACKAGE_2_OFFSET);
>>>>
>>>> You have `dm->length >= 0x30` below but the memory load already 
>>>> done here.
>>> After reading thread_count2, it cannot be guaranteed that the data 
>>> is valid.
>>>
>>> 'dm->length >= 0x30' can detect that thread_count2 is an available 
>>> data,
>>> right?
>>>
>> I mean you should perform the check before doing memory load.
> It doesn't matter whether it's before or after.
My understanding was wrong. I will fix it in v2.
>
> Anyway, here it's just reading. Before it's actually used later,
> it will check this length.
>>>>    +       if (thread_count != 0)
>>>>    +               loongson_sysconf.cores_per_package = dm->length 
>>>> >= 0x30 && thread_count == 0xFF ?
>>>>    + thread_count2 : thread_count;
>>>>
>>>>            pr_info("CpuClock = %llu\n", cpu_clock_freq);
>>>>     }
>>>>    --
>>>>    2.20.1
>
>