linux-kernel - Re: [PATCH v5 21/23] rv: Add rtapp

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: <20250430083819.-UXxRu1U@linutronix.de>
Date: Wed, 30 Apr 2025 10:38:19 +0200
From: Nam Cao <namcao@...utronix.de>
To: Gabriele Monaco <gmonaco@...hat.com>
Cc: Steven Rostedt <rostedt@...dmis.org>,
	linux-trace-kernel@...r.kernel.org, linux-kernel@...r.kernel.org,
	john.ogness@...utronix.de, Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>,
	Boqun Feng <boqun.feng@...il.com>, Waiman Long <longman@...hat.com>
Subject: Re: [PATCH v5 21/23] rv: Add rtapp_sleep monitor

On Wed, Apr 30, 2025 at 10:05:07AM +0200, Gabriele Monaco wrote:
> I've got one more small remark though, the name ALLOWLIST doesn't give
> justice to what you explained above.
> It suggests me something potentially wrong that we can't do much about,
> while in case of RT mutexes and futex lock, we just don't want the
> monitor to yell in a perfectly RT-compliant scenario.
> 
> What is happening here, from what I see, is that the kernel is handling
> the RT behaviour and your monitor is just meant to tell when userspace
> is doing something it could do better (unless we deal with kthreads,
> there we are in fact whitelisting the ones we know are not complying).
> 
> What about calling it RT_KERNEL_MANAGED_SLEEP or something along the
> line to say we just trust what the kernel is doing?

That would also work. The generated automaton should be exactly the same.

But I think this is quite subjective, so let's not argue too much about it.
In short, I prefer it as is, sorry.

I think "ALLOWLIST" is a suitable name. From Wikipedia: "A whitelist or
allowlist is a list or register of entities that are being provided a
particular privilege, service, mobility, access or recognition. Entities on
the list will be accepted, approved and/or recognized".

We trust rt_mutex and futex_lock_pi to do the right things, so I think they
belong to the allowlist. We also trust the RCU thread and the migration/
threads to be correct.

Best regards,
Nam