linux-kernel - Re: [PATCH v4] x86/split_lock: fix delayed detection enabling

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 for Android: free password hash cracker in your pocket

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

Message-ID: <4db72ef6-e83c-4600-a85a-a15e483a4632@yandex-team.ru>
Date: Thu, 19 Dec 2024 18:10:02 +0300
From: Maksim Davydov <davydov-max@...dex-team.ru>
To: "Guilherme G. Piccoli" <gpiccoli@...lia.com>
Cc: den-plotnikov@...dex-team.ru, x86@...nel.org, mingo@...hat.com,
 bp@...en8.de, linux-kernel@...r.kernel.org, dave.hansen@...ux.intel.com,
 tglx@...utronix.de, hpa@...or.com
Subject: Re: [PATCH v4] x86/split_lock: fix delayed detection enabling

Thanks a lot!

On 12/19/24 01:20, Guilherme G. Piccoli wrote:
> On 17/12/2024 11:54, Maksim Davydov wrote:
>> Hi!
>> Ping
>>
>> On 11/26/24 01:11, Maksim Davydov wrote:
>>> If the warn mode with disabled mitigation mode is used, then on each
>>> CPU where the split lock occurred detection will be disabled in order to
>>> make progress and delayed work will be scheduled, which then will enable
>>> detection back. Now it turns out that all CPUs use one global delayed
>>> work structure. This leads to the fact that if a split lock occurs on
>>> several CPUs at the same time (within 2 jiffies), only one CPU will
>>> schedule delayed work, but the rest will not. The return value of
>>> schedule_delayed_work_on() would have shown this, but it is not checked
>>> in the code.
>>>
>>> A diagram that can help to understand the bug reproduction:
>>> https://lore.kernel.org/all/2cd54041-253b-4e78-b8ea-dbe9b884ff9b@yandex-team.ru/
>>>
>>> In order to fix the warn mode with disabled mitigation mode, delayed work
>>> has to be a per-CPU.
>>>
>>> v4 -> v3:
>>> * rebased the patch onto the latest master
>>>
>>> v3 -> v2:
>>> * place and time of the per-CPU structure initialization were changed.
>>>     initcall doesn't seem to be a good place for it, so deferred
>>>     initialization is used.
>>>
>>> Fixes: 727209376f49 ("x86/split_lock: Add sysctl to control the misery mode")
>>> Signed-off-by: Maksim Davydov <davydov-max@...dex-team.ru>
>>> ---
> 
> Hi Maksim, I've just tested this patch on top of v6.13-rc3, in a laptop
> with Intel CPU that has the split lock detection - I have a quick test
> case for that. Everything works fine, so feel free to add my:
> 
> Tested-by: Guilherme G. Piccoli <gpiccoli@...lia.com>
> 
> Dave / others, anything else we need to get this fix merged?
> I'd be glad to help in other tests, etc.
> 
> Cheers,
> 
> 
> Guilherme

-- 
Best regards,
Maksim Davydov