linux-kernel - Re: [PATCH RFC 1/1] futex: Create set_robust

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: <1e62e083-f97c-4157-8d50-c3655edda97b@igalia.com>
Date: Thu, 24 Oct 2024 15:03:12 -0300
From: André Almeida <andrealmeid@...lia.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
 Davidlohr Bueso <dave@...olabs.net>, Darren Hart <dvhart@...radead.org>,
 Peter Zijlstra <peterz@...radead.org>, sonicadvance1@...il.com,
 linux-kernel@...r.kernel.org, kernel-dev@...lia.com,
 linux-api@...r.kernel.org
Subject: Re: [PATCH RFC 1/1] futex: Create set_robust_list2

Hi Arnd,

Em 24/10/2024 12:57, Arnd Bergmann escreveu:
> On Thu, Oct 24, 2024, at 14:57, André Almeida wrote:
>> This new syscall allows to set multiple list to the same process. There
>> are two list types: 32 and 64 bit lists.
>>
>> It supports up to 10 lists per process (see ROBUST_LISTS_PER_TASK). The
>> lists are dynamically allocated on demand, as part of a linked list.
>> This is the proposed interface:
>>
>> 	long set_robust_list2(void *head, int index, unsigned int flags)
>>
>> Userspace can ask to set the head of a new list using (index = -1).
>> Kernel will allocate a new list, place in the linked list and return the
>> new index to userspace.
>>
>> Userspace can modify an existing head by using an index >= 0. If the
>> requested list doesn't exist, an error is returned.
>>
>> Userspace cannot remove a robust list.
>>
>> For now, flag is for the list type:
>>
>> 	enum robust_list_type {
>> 	 	ROBUST_LIST_32BIT,
>> 		ROBUST_LIST_64BIT,
>> 	 };
>>
>> Signed-off-by: André Almeida <andrealmeid@...lia.com>
> 
> Hi André,
> 
> I have no opinion on the syscall itself, but I'll comment on
> the way you hook it up:
> 
>>   arch/arm/tools/syscall.tbl             |  1 +
>>   arch/x86/entry/syscalls/syscall_64.tbl |  1 +
> 
> If we agree on the number, this should be added to all
> architectures at the same time. In particular, when
> you add it to 32-bit arm, it also needs to be in the
> corresponding arch/arm64/tools/syscall_32.tbl for
> compat mode.

Ok

> 
>>   include/uapi/asm-generic/unistd.h      |  5 +-
> 
> This reminds me that I need to send the patch to remove this
> file, nothing should use it any more, though we still have
> the copy in tools/include/uapi/asm-generic/unistd.h that
> still gets referenced until the scripts are changed to
> use the syscall.tbl format.
> 
>> +	if (unlikely(!list_empty(list2))) {
>> +		list_for_each_entry_safe(curr, n, list2, list) {
>> +			if (curr->head != NULL) {
>> +				if (curr->list_type == ROBUST_LIST_64BIT)
>> +					exit_robust_list(tsk, curr->head);
>> +				else if (curr->list_type == ROBUST_LIST_32BIT)
>> +					compat_exit_robust_list(tsk, curr->head);
>> +				curr->head = NULL;
>> +			}
> 
> This looks like the behavior of a 32-bit task using
> ROBUST_LIST_64BIT is different on native 32-bit kernels
> compared to running on compat mode.
> 
> Assuming we want them to behave the same way, did you intend
> ROBUST_LIST_64BIT to refer to 64-bit pointers on 32-bit
> tasks, or should they use normal word-size pointers?

Oh right, I haven't covered that indeed. I think I would need to have 
something like:

static void exit_robust_list_64()
static void exit_robust_list_32()

And then each function would use explicit sizes for pointers. Also, I 
would rewrite the conditions to make that every combination of 64/32bit 
kernel/app calls the appropriated function.

Alternatively, we could just disable 32bit kernel/app to use the 
ROBUST_LIST_64BIT option.

Thank you for your feedback!
	André