linux-kernel - Re: [PATCH v2 0/4] futex: Drop ROBUST_LIST

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <df74a144-c925-410b-804c-c223793d08cf@igalia.com>
Date: Tue, 28 Jan 2025 11:28:10 -0300
From: André Almeida <andrealmeid@...lia.com>
To: Florian Weimer <fweimer@...hat.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
 Peter Zijlstra <peterz@...radead.org>, Darren Hart <dvhart@...radead.org>,
 Davidlohr Bueso <dave@...olabs.net>, Arnd Bergmann <arnd@...db.de>,
 linux-kernel@...r.kernel.org, kernel-dev@...lia.com,
 Vinicius Peixoto <vpeixoto@...amp.dev>
Subject: Re: [PATCH v2 0/4] futex: Drop ROBUST_LIST_LIMIT

Hi Florian,

Em 28/01/2025 04:50, Florian Weimer escreveu:
> * André Almeida:
> 
>> As requested by Peter at [1], this patchset drops the
>> ROBUST_LIST_LIMIT. This is achieve by simply rewriting the processed
>> list element ->next to point to the head->list address, destroying the
>> linked list to avoid any circular list.
> 
> Doesn't this turn a robust mutex overwrite or a TCB overwrite into a
> write-anything-anywhere primitive?  Furthermore, I'm not entirely sure
> if this is entirely backwards-compatible.
> 

The robust list is meant to be a private resource, per-process, and this 
patch only rewrites it after the process exits, so I believe that any 
changes done in this memory should be safe given that the process will 
soon disappear anyway, right?

Do you think you can point out a scenario that wouldn't be 
backwards-compatible? I would like to try to test it.

> Could you use the tortoise/hare approach instead?
> 

I believe that you want the approach to be "slow and steady" but I'm not 
sure what you have in mind, if you could you please elaborate :)

> Thanks,
> Florian
>