* Re: [PATCH 2/3] lsm: introduce security_lsm_manage_policy hook
From: Casey Schaufler @ 2025-05-08 16:54 UTC (permalink / raw)
To: John Johansen, Paul Moore, Maxime Bélair
Cc: Tetsuo Handa, linux-security-module, jmorris, serge, mic, kees,
stephen.smalley.work, takedakn, linux-api, apparmor, linux-kernel,
Casey Schaufler
In-Reply-To: <120954c2-87b7-4bda-958b-2b4f0180a736@canonical.com>
On 5/8/2025 1:29 AM, John Johansen wrote:
> On 5/7/25 13:25, Paul Moore wrote:
>> On Wed, May 7, 2025 at 6:41 AM Tetsuo Handa
>> <penguin-kernel@i-love.sakura.ne.jp> wrote:
>>> On 2025/05/06 23:32, Maxime Bélair wrote:
>>>> diff --git a/security/lsm_syscalls.c b/security/lsm_syscalls.c
>>>> index dcaad8818679..b39e6635a7d5 100644
>>>> --- a/security/lsm_syscalls.c
>>>> +++ b/security/lsm_syscalls.c
>>>> @@ -122,5 +122,10 @@ SYSCALL_DEFINE3(lsm_list_modules, u64 __user
>>>> *, ids, u32 __user *, size,
>>>> SYSCALL_DEFINE5(lsm_manage_policy, u32, lsm_id, u32, op, void
>>>> __user *, buf, u32
>>>> __user *, size, u32, flags)
>>>> {
>>>> - return 0;
>>>> + size_t usize;
>>>> +
>>>> + if (get_user(usize, size))
>>>> + return -EFAULT;
>>>> +
>>>> + return security_lsm_manage_policy(lsm_id, op, buf, usize,
>>>> flags);
>>>> }
>>>
>>> syzbot will report user-controlled unbounded huge size memory
>>> allocation attempt. ;-)
>>>
>>> This interface might be fine for AppArmor, but TOMOYO won't use this
>>> interface because
>>> TOMOYO's policy is line-oriented ASCII text data where the
>>> destination is switched via
>>> pseudo‑filesystem's filename ...
>>
>> While Tetsuo's comment is limited to TOMOYO, I believe the argument
>> applies to a number of other LSMs as well. The reality is that there
>> is no one policy ideal shared across LSMs and that complicates things
>> like the lsm_manage_policy() proposal. I'm intentionally saying
>> "complicates" and not "prevents" because I don't want to flat out
>> reject something like this, but I think there needs to be a larger
>> discussion among the different LSM groups about what such an API
>> should look like. We may not need to get every LSM to support this
>> new API, but we need to get something that would work for a
>> significant majority and would be general/extensible enough that we
>> would expect it to work with the majority of future LSMs (as much as
>> we can predict the future anyway).
>>
>
> yep, I look at this is just a starting point for discussion. There
> isn't going to be any discussion without some code, so here is a v1
> that supports a single LSM let the bike shedding begin.
Aside from the issues with allocating a buffer for a big policy
I don't see a problem with this proposal. The system call looks
a lot like the other LSM interfaces, so any developer who likes
those ought to like this one. The infrastructure can easily check
the lsm_id and only call the appropriate LSM hook, so no one
is going to be interfering with other modules.
^ permalink raw reply
* Re: [PATCH 2/3] lsm: introduce security_lsm_manage_policy hook
From: Tetsuo Handa @ 2025-05-08 15:07 UTC (permalink / raw)
To: John Johansen, Maxime Bélair, linux-security-module
Cc: paul, jmorris, serge, mic, kees, stephen.smalley.work, casey,
takedakn, linux-api, apparmor, linux-kernel
In-Reply-To: <07a496b2-ed1f-4a18-88d1-7be36dba3a8a@canonical.com>
On 2025/05/08 23:44, John Johansen wrote:
> On 5/8/25 05:55, Tetsuo Handa wrote:
>> On 2025/05/08 17:25, John Johansen wrote:
>>> That is fine. But curious I am curious what the interface would look like to fit TOMOYO's
>>> needs.
>>
>> Stream (like "FILE *") with restart from the beginning (like rewind(fp)) support.
>> That is, the caller can read/write at least one byte at a time, and written data
>> is processed upon encountering '\n'.
>>
>
> that can be emulated within the current sycall, where the lsm maintains a buffer.
That cannot be emulated, for there is no event that is automatically triggered when
the process terminates (i.e. implicit close() upon exit()) in order to release the
buffer the LSM maintains.
> Are you asking to also read data back out as well, that could be added, but doing
> a syscall per byte here or through the fs is going to have fairly high overhead.
At least one byte means arbitrary bytes; that is, the caller does not need to read
or write the whole policy at one syscall.
>
> Without understanding the requirement it would seem to me, that it would be
> better to emulate that file buffer manipulation in userspace similar say C++
> stringstreams, and then write the syscall when done.
The size of the whole policy in byte varies a lot.
^ permalink raw reply
* Re: The "make headers" requirement, revisited: [PATCH v3 3/3] selftests: pidfd: add tests for PIDFD_SELF_*
From: Shuah Khan @ 2025-05-08 15:06 UTC (permalink / raw)
To: Sean Christopherson
Cc: John Hubbard, Peter Zijlstra, Shuah Khan, Liam R . Howlett,
Suren Baghdasaryan, Vlastimil Babka, pedro.falcato,
linux-kselftest, linux-mm, linux-fsdevel, linux-api, linux-kernel,
Oliver Sang, Christian Brauner, Lorenzo Stoakes, Shuah Khan
In-Reply-To: <aBy5503w_GuNTu9B@google.com>
On 5/8/25 08:04, Sean Christopherson wrote:
> On Wed, May 07, 2025, Shuah Khan wrote:
>> The issues Peter is seeing regarding KHDR_INCLUDES in the following
>> tests can be easily fixed by simply changing the test Makefile. These
>> aren't framework related.
>>
>> kvm/Makefile.kvm: -I ../rseq -I.. $(EXTRA_CFLAGS) $(KHDR_INCLUDES)
>
> ...
>
>> You can make the change to remove the reference to KHDR_INCLUDES.
>> If don't have the time/bandwidth to do it, I will take care of it.
>
> Please don't remove the KHDR_INCLUDES usage in KVM's selftests, KVM routinely
> adds tests for new uAPI. Having to manually install headers is annoying, but
> IMO it's the least awful solution we have.
Thank you for confirming that KHDR_INCLUDES customization is necessary
for some tests such as kvm.
thanks,
-- Shuah
^ permalink raw reply
* Re: [PATCH 2/3] lsm: introduce security_lsm_manage_policy hook
From: John Johansen @ 2025-05-08 14:44 UTC (permalink / raw)
To: Tetsuo Handa, Maxime Bélair, linux-security-module
Cc: paul, jmorris, serge, mic, kees, stephen.smalley.work, casey,
takedakn, linux-api, apparmor, linux-kernel
In-Reply-To: <75c0385c-b649-46b0-907f-903e2217f460@I-love.SAKURA.ne.jp>
On 5/8/25 05:55, Tetsuo Handa wrote:
> On 2025/05/08 17:25, John Johansen wrote:
>> That is fine. But curious I am curious what the interface would look like to fit TOMOYO's
>> needs.
>
> Stream (like "FILE *") with restart from the beginning (like rewind(fp)) support.
> That is, the caller can read/write at least one byte at a time, and written data
> is processed upon encountering '\n'.
>
that can be emulated within the current sycall, where the lsm maintains a buffer.
Are you asking to also read data back out as well, that could be added, but doing
a syscall per byte here or through the fs is going to have fairly high overhead.
Without understanding the requirement it would seem to me, that it would be
better to emulate that file buffer manipulation in userspace similar say C++
stringstreams, and then write the syscall when done.
^ permalink raw reply
* Re: The "make headers" requirement, revisited: [PATCH v3 3/3] selftests: pidfd: add tests for PIDFD_SELF_*
From: Sean Christopherson @ 2025-05-08 14:04 UTC (permalink / raw)
To: Shuah Khan
Cc: John Hubbard, Peter Zijlstra, Shuah Khan, Liam R . Howlett,
Suren Baghdasaryan, Vlastimil Babka, pedro.falcato,
linux-kselftest, linux-mm, linux-fsdevel, linux-api, linux-kernel,
Oliver Sang, Christian Brauner, Lorenzo Stoakes
In-Reply-To: <e87bbc68-0403-4d67-ae2d-64065e36a011@linuxfoundation.org>
On Wed, May 07, 2025, Shuah Khan wrote:
> The issues Peter is seeing regarding KHDR_INCLUDES in the following
> tests can be easily fixed by simply changing the test Makefile. These
> aren't framework related.
>
> kvm/Makefile.kvm: -I ../rseq -I.. $(EXTRA_CFLAGS) $(KHDR_INCLUDES)
...
> You can make the change to remove the reference to KHDR_INCLUDES.
> If don't have the time/bandwidth to do it, I will take care of it.
Please don't remove the KHDR_INCLUDES usage in KVM's selftests, KVM routinely
adds tests for new uAPI. Having to manually install headers is annoying, but
IMO it's the least awful solution we have.
^ permalink raw reply
* Re: [PATCH 2/3] lsm: introduce security_lsm_manage_policy hook
From: Tetsuo Handa @ 2025-05-08 12:55 UTC (permalink / raw)
To: John Johansen, Maxime Bélair, linux-security-module
Cc: paul, jmorris, serge, mic, kees, stephen.smalley.work, casey,
takedakn, linux-api, apparmor, linux-kernel
In-Reply-To: <6d785712-6d8e-491c-86d4-1cbe5895778f@canonical.com>
On 2025/05/08 17:25, John Johansen wrote:
> That is fine. But curious I am curious what the interface would look like to fit TOMOYO's
> needs.
Stream (like "FILE *") with restart from the beginning (like rewind(fp)) support.
That is, the caller can read/write at least one byte at a time, and written data
is processed upon encountering '\n'.
^ permalink raw reply
* Re: [PATCH 2/3] lsm: introduce security_lsm_manage_policy hook
From: John Johansen @ 2025-05-08 8:29 UTC (permalink / raw)
To: Paul Moore, Maxime Bélair
Cc: Tetsuo Handa, linux-security-module, jmorris, serge, mic, kees,
stephen.smalley.work, casey, takedakn, linux-api, apparmor,
linux-kernel
In-Reply-To: <CAHC9VhRKwB4quqBtYQyxRqCX2C6fCgTbyAP3Ov+NdQ06t1aFdA@mail.gmail.com>
On 5/7/25 13:25, Paul Moore wrote:
> On Wed, May 7, 2025 at 6:41 AM Tetsuo Handa
> <penguin-kernel@i-love.sakura.ne.jp> wrote:
>> On 2025/05/06 23:32, Maxime Bélair wrote:
>>> diff --git a/security/lsm_syscalls.c b/security/lsm_syscalls.c
>>> index dcaad8818679..b39e6635a7d5 100644
>>> --- a/security/lsm_syscalls.c
>>> +++ b/security/lsm_syscalls.c
>>> @@ -122,5 +122,10 @@ SYSCALL_DEFINE3(lsm_list_modules, u64 __user *, ids, u32 __user *, size,
>>> SYSCALL_DEFINE5(lsm_manage_policy, u32, lsm_id, u32, op, void __user *, buf, u32
>>> __user *, size, u32, flags)
>>> {
>>> - return 0;
>>> + size_t usize;
>>> +
>>> + if (get_user(usize, size))
>>> + return -EFAULT;
>>> +
>>> + return security_lsm_manage_policy(lsm_id, op, buf, usize, flags);
>>> }
>>
>> syzbot will report user-controlled unbounded huge size memory allocation attempt. ;-)
>>
>> This interface might be fine for AppArmor, but TOMOYO won't use this interface because
>> TOMOYO's policy is line-oriented ASCII text data where the destination is switched via
>> pseudo‑filesystem's filename ...
>
> While Tetsuo's comment is limited to TOMOYO, I believe the argument
> applies to a number of other LSMs as well. The reality is that there
> is no one policy ideal shared across LSMs and that complicates things
> like the lsm_manage_policy() proposal. I'm intentionally saying
> "complicates" and not "prevents" because I don't want to flat out
> reject something like this, but I think there needs to be a larger
> discussion among the different LSM groups about what such an API
> should look like. We may not need to get every LSM to support this
> new API, but we need to get something that would work for a
> significant majority and would be general/extensible enough that we
> would expect it to work with the majority of future LSMs (as much as
> we can predict the future anyway).
>
yep, I look at this is just a starting point for discussion. There
isn't going to be any discussion without some code, so here is a v1
that supports a single LSM let the bike shedding begin.
^ permalink raw reply
* Re: [PATCH 2/3] lsm: introduce security_lsm_manage_policy hook
From: John Johansen @ 2025-05-08 8:25 UTC (permalink / raw)
To: Tetsuo Handa, Maxime Bélair, linux-security-module
Cc: paul, jmorris, serge, mic, kees, stephen.smalley.work, casey,
takedakn, linux-api, apparmor, linux-kernel
In-Reply-To: <9c68743f-5efa-4a77-a29b-d3e8f2b2a462@I-love.SAKURA.ne.jp>
On 5/7/25 03:40, Tetsuo Handa wrote:
> On 2025/05/06 23:32, Maxime Bélair wrote:
>> diff --git a/security/lsm_syscalls.c b/security/lsm_syscalls.c
>> index dcaad8818679..b39e6635a7d5 100644
>> --- a/security/lsm_syscalls.c
>> +++ b/security/lsm_syscalls.c
>> @@ -122,5 +122,10 @@ SYSCALL_DEFINE3(lsm_list_modules, u64 __user *, ids, u32 __user *, size,
>> SYSCALL_DEFINE5(lsm_manage_policy, u32, lsm_id, u32, op, void __user *, buf, u32
>> __user *, size, u32, flags)
>> {
>> - return 0;
>> + size_t usize;
>> +
>> + if (get_user(usize, size))
>> + return -EFAULT;
>> +
>> + return security_lsm_manage_policy(lsm_id, op, buf, usize, flags);
>> }
>
> syzbot will report user-controlled unbounded huge size memory allocation attempt. ;-)
>
> This interface might be fine for AppArmor, but TOMOYO won't use this interface because
> TOMOYO's policy is line-oriented ASCII text data where the destination is switched via
> pseudo‑filesystem's filename; use of filename helps restricting which type of policy
> can be manipulated by which process.
>
That is fine. But curious I am curious what the interface would look like to fit TOMOYO's
needs. I look at the current implementation as an opening discussion of what the syscall
should look like. I have no delusions that we are going to get something that will fit
all LSMs but without requirements, we won't be able to even attempt to hash something
better out.
^ permalink raw reply
* Re: [PATCH 2/3] lsm: introduce security_lsm_manage_policy hook
From: John Johansen @ 2025-05-08 8:20 UTC (permalink / raw)
To: Maxime Bélair, Song Liu
Cc: linux-security-module, paul, jmorris, serge, mic, kees,
stephen.smalley.work, casey, takedakn, penguin-kernel, linux-api,
apparmor, linux-kernel
In-Reply-To: <bc252425-2703-48c4-a1fa-9268124c2386@canonical.com>
On 5/7/25 08:37, Maxime Bélair wrote:
>
>
> On 5/7/25 08:19, Song Liu wrote:
>> On Tue, May 6, 2025 at 7:40 AM Maxime Bélair
>> <maxime.belair@canonical.com> wrote:
>>>
>>> Define a new LSM hook security_lsm_manage_policy and wire it into the
>>> lsm_manage_policy() syscall so that LSMs can register a unified interface
>>> for policy management. This initial, minimal implementation only supports
>>> the LSM_POLICY_LOAD operation to limit changes.
>>>
>>> Signed-off-by: Maxime Bélair <maxime.belair@canonical.com>
>> [...]
>>> diff --git a/security/security.c b/security/security.c
>>> index fb57e8fddd91..256104e338b1 100644
>>> --- a/security/security.c
>>> +++ b/security/security.c
>>> @@ -5883,6 +5883,27 @@ int security_bdev_setintegrity(struct block_device *bdev,
>>> }
>>> EXPORT_SYMBOL(security_bdev_setintegrity);
>>>
>>> +/**
>>> + * security_lsm_manage_policy() - Manage the policies of LSMs
>>> + * @lsm_id: id of the lsm to target
>>> + * @op: Operation to perform (one of the LSM_POLICY_XXX values)
>>> + * @buf: userspace pointer to policy data
>>> + * @size: size of @buf
>>> + * @flags: lsm policy management flags
>>> + *
>>> + * Manage the policies of a LSM. This notably allows to update them even when
>>> + * the lsmfs is unavailable is restricted. Currently, only LSM_POLICY_LOAD is
>>> + * supported.
>>> + *
>>> + * Return: Returns 0 on success, error on failure.
>>> + */
>>> +int security_lsm_manage_policy(u32 lsm_id, u32 op, void __user *buf,
>>> + size_t size, u32 flags)
>>> +{
>>> + return call_int_hook(lsm_manage_policy, lsm_id, op, buf, size, flags);
>>
>> If the LSM doesn't implement this hook, sys_lsm_manage_policy will return 0
>> for any inputs, right? This is gonna be so confusing for users.
>
> Indeed, that was an oversight. It will return -EOPNOTSUPP in the next patch revision.
>
I think it needs to do more than that. I don't think this should call each LSM, the
infrastructure should filter it and only send it to the LSM identified by the lsm_id
^ permalink raw reply
* Re: [PATCH 1/3] Wire up the lsm_manage_policy syscall
From: John Johansen @ 2025-05-08 8:18 UTC (permalink / raw)
To: Song Liu, Maxime Bélair
Cc: linux-security-module, paul, jmorris, serge, mic, kees,
stephen.smalley.work, casey, takedakn, penguin-kernel, linux-api,
apparmor, linux-kernel
In-Reply-To: <CAPhsuW4FVMS7v8p_C-QzE8nBxCb6xDRhEecm_KHZ3KbKUjOXrQ@mail.gmail.com>
On 5/7/25 23:06, Song Liu wrote:
> On Wed, May 7, 2025 at 8:37 AM Maxime Bélair
> <maxime.belair@canonical.com> wrote:
> [...]
>>>
>>> These two do not feel like real benefits:
>>> - One syscall cannot fit all use cases well...
>>
>> This syscall is not intended to cover every case, nor to replace existing kernel
>> interfaces.
>>
>> Each LSM can decide which operations it wants to support (if any). For example, when
>> loading policies, an LSM may choose to allow only policies that further restrict
>> privileges.
>>
>>> - Not working in containers is often not an issue, but a feature.
>>
>> Indeed, using this syscall requires appropriate capabilities and will not permit
>> unprivileged containers to manage policies arbitrarily.
>>
>> With this syscall, capability checks remain the responsibility of each LSM.
>>
>> For instance, in the AppArmor patch, a profile can be loaded only if
>> aa_policy_admin_capable() succeeds (which requires CAP_MAC_ADMIN). Moreover, by design,
>> policies can be loaded only in the current namespace.
>>
>> I see this syscall as a middle point between exposing the entire sysfs, creating a large
>> attack surface, and blocking everything.
>>
>> Landlock’s existing syscalls already improve security by allowing processes to further
>> restrict their ambient rights while adding only a modest attack surface.
>>
>> This syscall is a further step in that direction: it lets LSMs add restrictive policies
>> without requiring exposing every other interface.
>
> I don't think a syscall makes the API more secure. If necessary, we can add
It exposes a different attack surface. Requiring mounting of the fs to where it is visible
in the container, provides attack surface, and requires additional external configuration.
Then there is the whole issue of getting the various LSMs to allow another LSM in the
stack to be able manage its own policy.
> permission check to each pseudo file. The downside of the syscall, however,
> is that all the permission checks are hard-coded in the kernel (except for
The permission checks don't have to be hard coded. Each LSM can define how it handles
or manages the syscall. The default is that it isn't supported, but if an lsm decides
to support it, there is now reason that its policy can't determine the use of the
syscall.
> BPF LSM); while the sys admin can configure permissions of the pseudo
> files in user space.
>
Other LSMs also have policy that can control access to pseudo filesystems and
other resources. Again, the control doesn't have to be hard coded. And seccomp can
be used to block the syscall.
>> Again, each module decides which operations to expose through this syscall. In many cases
>> the operation will still require CAP_SYS_ADMIN or a similar capability, so environments
>> that choose this interface remain secure while gaining its advantages.
>>
>>>> - Avoids overhead of other kernel interfaces for better efficiency
>>>
>>> .. and it is is probably less efficient, because everything need to
>>> fit in the same API.
>>
>> As shown below, the syscall can significantly improve the performance of policy management.
>> A more detailed benchmark is available in [1].
>>
>> The following table presents the time required to load an AppArmor profile.
>>
>> For every cell, the first value is the total time taken by aa-load, and the value in
>> parentheses is the time spent to load the policy in the kernel only (total - dry‑run).
>>
>> Results are in microseconds and are averaged over 10 000 runs to reduce variance.
>>
>>
>> | t (µs) | syscall | pseudofs | Speedup |
>> |-----------|-------------|-------------|---------------|
>> | 1password | 4257 (1127) | 3333 (192) | x1.28 (x5.86) |
>> | Xorg | 6099 (2961) | 5167 (2020) | x1.18 (x1.47) |
>>
>
> I am not sure the performance of loading security policies is on any
> critical path.
generally speaking I agree, but I am also not going to turn down a
performance improvement either. Its a nice to have, but not a strong
argument for need.
> The implementation calls the hook for each LSM, which is why I think the
> syscall is not efficient.
>
it should only call the LSM identified by the lsmid in the call.
> Overall, I am still not convinced a syscall for all LSMs is needed. To
> justify such
its not needed by all LSMs, just a subset of them, and some nebulous
subset of potentially future LSMs that is entirely undefinable.
If we had had appropriate LSM syscalls landlock wouldn't have needed
to have landlock specific syscalls. Having another LSM go that route
feels wrong especially now that we have some LSM syscalls. If a
syscall is needed by an LSM its better to try hashing something out
that might have utility for multiple LSMs or at the very least,
potentially have utility in the future.
> a syscall, I think we need to show that it is useful in multiple LSMs.
> Also, if we
> really want to have single set of APIs for all LSMs, we may also need
> get_policy,
We are never going to get a single set of APIs for all LSMs. I will
settle for an api that has utility for a subset
> remove_policy, etc. This set as-is appears to be an incomplete design. The
To have a complete design, there needs to be feedback and discussion
from multiple LSMs. This is a starting point.
> implementation, with call_int_hook, is also problematic. It can easily
> cause some> controversial behaviors.
>
agreed it shouldn't be doing a straight call_int_hook, it should only
call it against the lsm identified by the lsmid
^ permalink raw reply
* Re: [PATCH 1/3] Wire up the lsm_manage_policy syscall
From: John Johansen @ 2025-05-08 7:52 UTC (permalink / raw)
To: Tetsuo Handa, Maxime Bélair, Song Liu
Cc: linux-security-module, paul, jmorris, serge, mic, kees,
stephen.smalley.work, casey, takedakn, linux-api, apparmor,
linux-kernel
In-Reply-To: <470689f0-223e-4d26-a919-8d48f383883b@I-love.SAKURA.ne.jp>
On 5/7/25 15:04, Tetsuo Handa wrote:
> On 2025/05/08 0:37, Maxime Bélair wrote:
>> Again, each module decides which operations to expose through this syscall. In many cases
>> the operation will still require CAP_SYS_ADMIN or a similar capability, so environments
>> that choose this interface remain secure while gaining its advantages.
>
> If the interpretation of "flags" argument varies across LSMs, it sounds like ioctl()'s
yes that does feel like ioctls(), on the other hand defining them at the LSM level won't
offer LSMs flexibility making it so the syscall covers fewer use cases. I am not opposed
to either, it just hashing out what people want, and what is acceptable.
> "cmd" argument. Also, there is prctl() which can already carry string-ish parameters
> without involving open(). Why can't we use prctl() instead of lsm_manage_policy() ?
>
prctl() can be used, I used it for the unprivileged policy demo. It has its own set of
problems. While LSM policy could be associated with the process doing the load/replacement
or what ever operation, it isn't necessarily tied to it. A lot of LSM policy is not
process specific making prctl() a poor fit.
prctl() requires allocating a global prctl()
prctl() are already being filtered/controlled by LSMs making them a poort fit for
use by an LSM in a stacking situation as it requires updating the policy of other
LSMs on the system. Yes seccomp can filter the syscall but that still is an easier
barrier to overcome than having to have instruction for how to allow your LSMs
prctl() in multiple LSMs.
Mickaël already argued the need for landlock to have syscalls. See
https://lore.kernel.org/lkml/20200511192156.1618284-7-mic@digikod.net/
and the numerous iterations before that.
Ideally those could have been LSM syscalls, with landlock leveraging them. AppArmor
is getting to where it has similar needs to landlock. Yes we can use ioctls, prctls,
netlink, the fs, etc. it doesn't mean that those are the best interfaces to do so,
and ideally any interface we use will be of benefit to some other LSMs in the future.
^ permalink raw reply
* Re: [PATCH 1/3] Wire up the lsm_manage_policy syscall
From: John Johansen @ 2025-05-08 7:12 UTC (permalink / raw)
To: Song Liu, Maxime Bélair
Cc: linux-security-module, paul, jmorris, serge, mic, kees,
stephen.smalley.work, casey, takedakn, penguin-kernel, linux-api,
apparmor, linux-kernel
In-Reply-To: <CAPhsuW4qY9B3KdhqrUOZoNBWQmO_RDwbH46my314WxrFwxbwkQ@mail.gmail.com>
On 5/6/25 23:26, Song Liu wrote:
> On Tue, May 6, 2025 at 7:40 AM Maxime Bélair
> <maxime.belair@canonical.com> wrote:
>>
>> Add support for the new lsm_manage_policy syscall, providing a unified
>> API for loading and modifying LSM policies without requiring the LSM’s
>> pseudo-filesystem.
>>
>> Benefits:
>> - Works even if the LSM pseudo-filesystem isn’t mounted or available
>> (e.g. in containers)
>> - Offers a logical and unified interface rather than multiple
>> heterogeneous pseudo-filesystems.
>
> These two do not feel like real benefits:
> - Not working in containers is often not an issue, but a feature.
and the LSM doesn't have to allow the syscall to function in a container
where appropriate. Its up to the LSM if the syscall is supported and
what kind of permissions are needed.
However having the ability to function in a container and not having to
mount securityfs, or procfs into a container. similar to what landlock
gets with its syscall can be beneficial.
> - One syscall cannot fit all use cases well...
>
of course not, and for those other use cases new syscalls can be added.
>> - Avoids overhead of other kernel interfaces for better efficiency
>
> .. and it is is probably less efficient, because everything need to
> fit in the same API.
>
no not everything, just what fits into the syscall. Nor does an LSM
have to use the syscall it is still use what works for it.
This could be a little more efficient than the current fs interface
used by apparmor/selinux/smack but I don't think efficiency is going
to be a huge win for this.
> Overall, this set doesn't feel like a good change to me.
>
> Thanks,
> Song
^ permalink raw reply
* Re: [PATCH 1/3] Wire up the lsm_manage_policy syscall
From: Song Liu @ 2025-05-08 6:06 UTC (permalink / raw)
To: Maxime Bélair
Cc: linux-security-module, john.johansen, paul, jmorris, serge, mic,
kees, stephen.smalley.work, casey, takedakn, penguin-kernel,
linux-api, apparmor, linux-kernel
In-Reply-To: <aa3c41f9-6b25-4871-a4be-e08430e59730@canonical.com>
On Wed, May 7, 2025 at 8:37 AM Maxime Bélair
<maxime.belair@canonical.com> wrote:
[...]
> >
> > These two do not feel like real benefits:
> > - One syscall cannot fit all use cases well...
>
> This syscall is not intended to cover every case, nor to replace existing kernel
> interfaces.
>
> Each LSM can decide which operations it wants to support (if any). For example, when
> loading policies, an LSM may choose to allow only policies that further restrict
> privileges.
>
> > - Not working in containers is often not an issue, but a feature.
>
> Indeed, using this syscall requires appropriate capabilities and will not permit
> unprivileged containers to manage policies arbitrarily.
>
> With this syscall, capability checks remain the responsibility of each LSM.
>
> For instance, in the AppArmor patch, a profile can be loaded only if
> aa_policy_admin_capable() succeeds (which requires CAP_MAC_ADMIN). Moreover, by design,
> policies can be loaded only in the current namespace.
>
> I see this syscall as a middle point between exposing the entire sysfs, creating a large
> attack surface, and blocking everything.
>
> Landlock’s existing syscalls already improve security by allowing processes to further
> restrict their ambient rights while adding only a modest attack surface.
>
> This syscall is a further step in that direction: it lets LSMs add restrictive policies
> without requiring exposing every other interface.
I don't think a syscall makes the API more secure. If necessary, we can add
permission check to each pseudo file. The downside of the syscall, however,
is that all the permission checks are hard-coded in the kernel (except for
BPF LSM); while the sys admin can configure permissions of the pseudo
files in user space.
> Again, each module decides which operations to expose through this syscall. In many cases
> the operation will still require CAP_SYS_ADMIN or a similar capability, so environments
> that choose this interface remain secure while gaining its advantages.
>
> >> - Avoids overhead of other kernel interfaces for better efficiency
> >
> > .. and it is is probably less efficient, because everything need to
> > fit in the same API.
>
> As shown below, the syscall can significantly improve the performance of policy management.
> A more detailed benchmark is available in [1].
>
> The following table presents the time required to load an AppArmor profile.
>
> For every cell, the first value is the total time taken by aa-load, and the value in
> parentheses is the time spent to load the policy in the kernel only (total - dry‑run).
>
> Results are in microseconds and are averaged over 10 000 runs to reduce variance.
>
>
> | t (µs) | syscall | pseudofs | Speedup |
> |-----------|-------------|-------------|---------------|
> | 1password | 4257 (1127) | 3333 (192) | x1.28 (x5.86) |
> | Xorg | 6099 (2961) | 5167 (2020) | x1.18 (x1.47) |
>
I am not sure the performance of loading security policies is on any
critical path.
The implementation calls the hook for each LSM, which is why I think the
syscall is not efficient.
Overall, I am still not convinced a syscall for all LSMs is needed. To
justify such
a syscall, I think we need to show that it is useful in multiple LSMs.
Also, if we
really want to have single set of APIs for all LSMs, we may also need
get_policy,
remove_policy, etc. This set as-is appears to be an incomplete design. The
implementation, with call_int_hook, is also problematic. It can easily
cause some
controversial behaviors.
Thanks,
Song
^ permalink raw reply
* Re: [PATCH 1/3] Wire up the lsm_manage_policy syscall
From: Tetsuo Handa @ 2025-05-07 22:04 UTC (permalink / raw)
To: Maxime Bélair, Song Liu
Cc: linux-security-module, john.johansen, paul, jmorris, serge, mic,
kees, stephen.smalley.work, casey, takedakn, linux-api, apparmor,
linux-kernel
In-Reply-To: <aa3c41f9-6b25-4871-a4be-e08430e59730@canonical.com>
On 2025/05/08 0:37, Maxime Bélair wrote:
> Again, each module decides which operations to expose through this syscall. In many cases
> the operation will still require CAP_SYS_ADMIN or a similar capability, so environments
> that choose this interface remain secure while gaining its advantages.
If the interpretation of "flags" argument varies across LSMs, it sounds like ioctl()'s
"cmd" argument. Also, there is prctl() which can already carry string-ish parameters
without involving open(). Why can't we use prctl() instead of lsm_manage_policy() ?
^ permalink raw reply
* Re: The "make headers" requirement, revisited: [PATCH v3 3/3] selftests: pidfd: add tests for PIDFD_SELF_*
From: Shuah Khan @ 2025-05-07 20:50 UTC (permalink / raw)
To: John Hubbard, Peter Zijlstra
Cc: Shuah Khan, Liam R . Howlett, Suren Baghdasaryan, Vlastimil Babka,
pedro.falcato, linux-kselftest, linux-mm, linux-fsdevel,
linux-api, linux-kernel, Oliver Sang, Christian Brauner,
Lorenzo Stoakes
In-Reply-To: <3687348f-7ee0-4fe1-a953-d5a2edd02ce8@nvidia.com>
On 10/17/24 10:47, John Hubbard wrote:
> On 10/17/24 9:33 AM, Shuah Khan wrote:
>> On 10/16/24 20:01, John Hubbard wrote:
>>> On 10/16/24 1:00 PM, Shuah Khan wrote:
>>>> On 10/16/24 04:20, Lorenzo Stoakes wrote:
> ...
>>> The requirement to do "make headers" is not a keeper. Really.
>>
>> The reason we added the requirement to avoid duplicate defines
>> such as this one added to kselftest source files. These are
>> error prone and hard to resolve.
>>
>> In some cases, these don't become uapi and don't make it into
>> system headers. selftests are in a category of depending on
>> kernel headers to be able to test some features.
>>
>> Getting rid of this dependency mean, tests will be full of local
>> defines such as this one which will become unmanageable overtime.
>
> Not if we do it correctly...Please do look at the reference I provided
> for how that works. Here is is again: [1].
>
> The basic idea, which has been discussed and reviewed, is to take
> very occasional snapshots and drop them into a static location where
> they are available for kselftests, without disurbing other things:
> $(top_srcdir)/tools/include/uapi
>
> This has worked well so far.
>
>>
>> The discussion should be: "How do we get rid of the dependency without
>> introducing local defines?" not just "Let's get rid of the dependency"
>>
>
> Yes. Good. We are apparently in violent agreement, because a few lines above,
> I wrote:
>
> The requirement to do "make headers" is not a keeper.
>
> The "make headers" is the problem, not the fact that we need to depend
> on various includes. And so the solution stops requiring "make headers".
> It gets the includes from a less volatile location.
>
> Yes?
>
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e076eaca5906
>
> thanks,
Posting this on this thread as well -
Peter, John,
There seems to be confusion regarding KHDR_INCLUDES. Tests don't have
to use KHDR_INCLUDES if they don't want to.
There are 4623 test Makefiles (excluding the main Makefile) under selftests/.
Out of those 73 Makefiles reference KHDR_INCLUDES exported by lib.mk and
selftests/Makefile. The rest are happy with system headers.
The support for this KHDR_INCLUDES was added just for the case when a new
test depends on header change. This is the reason why only a few
test Makefiles use it. When test rings ran into issues related to
dependencies between header changes, we recommended installing headers
to solve the problem and introduced KHDR_INCLUDES so test Makefiles
can use it in their Makefiles overriding the framework defaults.
If your test doesn't need it, you can simply stop referencing it or
use the approach used in mm test.
It is a manual step. Works well for developers who know what they are doing.
This isn't ideal for test rings. This isn't an ideal solution really.
It works for the mm developers.
# In order to use newer items that haven't yet been added to the user's system
# header files, add $(TOOLS_INCLUDES) to the compiler invocation in each
# each selftest.
# You may need to add files to that location, or to refresh an existing file. In
# order to do that, run "make headers" from $(top_srcdir), then copy the
# header file that you want from $(top_srcdir)/usr/include/... , to the matching
# subdir in $(TOOLS_INCLUDE).
TOOLS_INCLUDES := -isystem $(top_srcdir)/tools/include/uapi
The issues Peter is seeing regarding KHDR_INCLUDES in the following
tests can be easily fixed by simply changing the test Makefile. These
aren't framework related.
kvm/Makefile.kvm: -I ../rseq -I.. $(EXTRA_CFLAGS) $(KHDR_INCLUDES)
x86/Makefile:CFLAGS := -O2 -g -std=gnu99 -pthread -Wall $(KHDR_INCLUDES)
futex/functional/Makefile:INCLUDES := -I../include -I../../ $(KHDR_INCLUDES)
futex/functional/Makefile:CFLAGS := $(CFLAGS) -g -O2 -Wall -pthread $(INCLUDES) $(KHDR_INCLUDES)
You can make the change to remove the reference to KHDR_INCLUDES.
If don't have the time/bandwidth to do it, I will take care of it.
If test build fails, you can then figure out how to address that.
Hopefully build issues related to header changes are infrequent.
thanks,
-- Shuah
^ permalink raw reply
* Re: [PATCH v3 3/3] selftests: pidfd: add tests for PIDFD_SELF_*
From: Shuah Khan @ 2025-05-07 20:49 UTC (permalink / raw)
To: John Hubbard, Peter Zijlstra
Cc: Lorenzo Stoakes, Christian Brauner, Shuah Khan, Liam R . Howlett,
Suren Baghdasaryan, Vlastimil Babka, pedro.falcato,
linux-kselftest, linux-mm, linux-fsdevel, linux-api, linux-kernel,
Oliver Sang, seanjc, Shuah Khan
In-Reply-To: <8f765dc8-421f-420f-bd3e-1a0d889238a1@nvidia.com>
On 5/6/25 15:34, John Hubbard wrote:
> On 5/6/25 2:18 PM, Shuah Khan wrote:
>> On 5/1/25 05:42, Peter Zijlstra wrote:
>>> On Wed, Oct 16, 2024 at 07:14:34PM -0700, John Hubbard wrote:
>>>> On 10/16/24 3:06 PM, Lorenzo Stoakes wrote:
>>>>> On Wed, Oct 16, 2024 at 02:00:27PM -0600, Shuah Khan wrote:
>>>>>> On 10/16/24 04:20, Lorenzo Stoakes wrote:
>>>> ...
>>> Please fix this fucking selftests shit to just build. This is unusable
>>> garbage.
>>
Peter, John,
There seems to be confusion regarding KHDR_INCLUDES. Tests don't have
to use KHDR_INCLUDES if they don't want to.
There are 4623 test Makefiles (excluding the main Makefile) under selftests/.
Out of those 73 Makefiles reference KHDR_INCLUDES exported by lib.mk and
selftests/Makefile. The rest are happy with system headers.
The support for this KHDR_INCLUDES was added just for the case when a new
test depends on header change. This is the reason why only a few
test Makefiles use it. When test rings ran into issues related to
dependencies between header changes, we recommended installing headers
to solve the problem and introduced KHDR_INCLUDES so test Makefiles
can use it in their Makefiles overriding the framework defaults.
If your test doesn't need it, you can simply stop referencing it or
use the approach used in mm test.
It is a manual step. Works well for developers who know what they are doing.
This isn't ideal for test rings. This isn't an ideal solution really.
It works for the mm developers.
# In order to use newer items that haven't yet been added to the user's system
# header files, add $(TOOLS_INCLUDES) to the compiler invocation in each
# each selftest.
# You may need to add files to that location, or to refresh an existing file. In
# order to do that, run "make headers" from $(top_srcdir), then copy the
# header file that you want from $(top_srcdir)/usr/include/... , to the matching
# subdir in $(TOOLS_INCLUDE).
TOOLS_INCLUDES := -isystem $(top_srcdir)/tools/include/uapi
The issues Peter is seeing regarding KHDR_INCLUDES in the following
tests can be easily fixed by simply changing the test Makefile. These
aren't framework related.
kvm/Makefile.kvm: -I ../rseq -I.. $(EXTRA_CFLAGS) $(KHDR_INCLUDES)
x86/Makefile:CFLAGS := -O2 -g -std=gnu99 -pthread -Wall $(KHDR_INCLUDES)
futex/functional/Makefile:INCLUDES := -I../include -I../../ $(KHDR_INCLUDES)
futex/functional/Makefile:CFLAGS := $(CFLAGS) -g -O2 -Wall -pthread $(INCLUDES) $(KHDR_INCLUDES)
You can make the change to remove the reference to KHDR_INCLUDES.
If don't have the time/bandwidth to do it, I will take care of it.
If test build fails, you can then figure out how to address that.
Hopefully build issues related to header changes are infrequent.
thanks,
-- Shuah
^ permalink raw reply
* Re: [PATCH 2/3] lsm: introduce security_lsm_manage_policy hook
From: Paul Moore @ 2025-05-07 20:25 UTC (permalink / raw)
To: Maxime Bélair
Cc: Tetsuo Handa, linux-security-module, john.johansen, jmorris,
serge, mic, kees, stephen.smalley.work, casey, takedakn,
linux-api, apparmor, linux-kernel
In-Reply-To: <9c68743f-5efa-4a77-a29b-d3e8f2b2a462@I-love.SAKURA.ne.jp>
On Wed, May 7, 2025 at 6:41 AM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
> On 2025/05/06 23:32, Maxime Bélair wrote:
> > diff --git a/security/lsm_syscalls.c b/security/lsm_syscalls.c
> > index dcaad8818679..b39e6635a7d5 100644
> > --- a/security/lsm_syscalls.c
> > +++ b/security/lsm_syscalls.c
> > @@ -122,5 +122,10 @@ SYSCALL_DEFINE3(lsm_list_modules, u64 __user *, ids, u32 __user *, size,
> > SYSCALL_DEFINE5(lsm_manage_policy, u32, lsm_id, u32, op, void __user *, buf, u32
> > __user *, size, u32, flags)
> > {
> > - return 0;
> > + size_t usize;
> > +
> > + if (get_user(usize, size))
> > + return -EFAULT;
> > +
> > + return security_lsm_manage_policy(lsm_id, op, buf, usize, flags);
> > }
>
> syzbot will report user-controlled unbounded huge size memory allocation attempt. ;-)
>
> This interface might be fine for AppArmor, but TOMOYO won't use this interface because
> TOMOYO's policy is line-oriented ASCII text data where the destination is switched via
> pseudo‑filesystem's filename ...
While Tetsuo's comment is limited to TOMOYO, I believe the argument
applies to a number of other LSMs as well. The reality is that there
is no one policy ideal shared across LSMs and that complicates things
like the lsm_manage_policy() proposal. I'm intentionally saying
"complicates" and not "prevents" because I don't want to flat out
reject something like this, but I think there needs to be a larger
discussion among the different LSM groups about what such an API
should look like. We may not need to get every LSM to support this
new API, but we need to get something that would work for a
significant majority and would be general/extensible enough that we
would expect it to work with the majority of future LSMs (as much as
we can predict the future anyway).
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH 2/3] lsm: introduce security_lsm_manage_policy hook
From: Maxime Bélair @ 2025-05-07 15:37 UTC (permalink / raw)
To: Tetsuo Handa, linux-security-module
Cc: john.johansen, paul, jmorris, serge, mic, kees,
stephen.smalley.work, casey, takedakn, linux-api, apparmor,
linux-kernel
In-Reply-To: <9c68743f-5efa-4a77-a29b-d3e8f2b2a462@I-love.SAKURA.ne.jp>
On 5/7/25 12:40, Tetsuo Handa wrote:
> On 2025/05/06 23:32, Maxime Bélair wrote:
>> diff --git a/security/lsm_syscalls.c b/security/lsm_syscalls.c
>> index dcaad8818679..b39e6635a7d5 100644
>> --- a/security/lsm_syscalls.c
>> +++ b/security/lsm_syscalls.c
>> @@ -122,5 +122,10 @@ SYSCALL_DEFINE3(lsm_list_modules, u64 __user *, ids, u32 __user *, size,
>> SYSCALL_DEFINE5(lsm_manage_policy, u32, lsm_id, u32, op, void __user *, buf, u32
>> __user *, size, u32, flags)
>> {
>> - return 0;
>> + size_t usize;
>> +
>> + if (get_user(usize, size))
>> + return -EFAULT;
>> +
>> + return security_lsm_manage_policy(lsm_id, op, buf, usize, flags);
>> }
>
> syzbot will report user-controlled unbounded huge size memory allocation attempt. ;-)
>
> This interface might be fine for AppArmor, but TOMOYO won't use this interface because
> TOMOYO's policy is line-oriented ASCII text data where the destination is switched via
> pseudo‑filesystem's filename; use of filename helps restricting which type of policy
> can be manipulated by which process.
First, like any LSM, TOMOYO is not obliged to implement every operation. It can simply
expose the one that makes sense for its use case. For instance, I don't think it needs an
equivalent of the manager interface.
If TOMOYO wants to support several sub‑operations, it can distinguish them with the
syscall’s flags parameter instead of filenames (as securityfs_if.c does today) and reuse
the code already employed by its pseudo‑fs, as in the AppArmor patch. Supporting this
syscall would therefore require only minimal changes.
Line‑oriented ASCII text is not a barrier, either. The syscall can pass that format just
fine. Because a typical TOMOYO line is very small, the performance gains from using the
syscall are actually greater. A brief benchmark is available in [1].
Thanks,
Maxime
[1] https://gitlab.com/-/snippets/4840792
^ permalink raw reply
* Re: [PATCH 2/3] lsm: introduce security_lsm_manage_policy hook
From: Maxime Bélair @ 2025-05-07 15:37 UTC (permalink / raw)
To: Song Liu
Cc: linux-security-module, john.johansen, paul, jmorris, serge, mic,
kees, stephen.smalley.work, casey, takedakn, penguin-kernel,
linux-api, apparmor, linux-kernel
In-Reply-To: <CAPhsuW7q1hvOG7-uG2C8d_wWnOhEmvTmwnBcXZYVX-oJ8=5FJQ@mail.gmail.com>
On 5/7/25 08:19, Song Liu wrote:
> On Tue, May 6, 2025 at 7:40 AM Maxime Bélair
> <maxime.belair@canonical.com> wrote:
>>
>> Define a new LSM hook security_lsm_manage_policy and wire it into the
>> lsm_manage_policy() syscall so that LSMs can register a unified interface
>> for policy management. This initial, minimal implementation only supports
>> the LSM_POLICY_LOAD operation to limit changes.
>>
>> Signed-off-by: Maxime Bélair <maxime.belair@canonical.com>
> [...]
>> diff --git a/security/security.c b/security/security.c
>> index fb57e8fddd91..256104e338b1 100644
>> --- a/security/security.c
>> +++ b/security/security.c
>> @@ -5883,6 +5883,27 @@ int security_bdev_setintegrity(struct block_device *bdev,
>> }
>> EXPORT_SYMBOL(security_bdev_setintegrity);
>>
>> +/**
>> + * security_lsm_manage_policy() - Manage the policies of LSMs
>> + * @lsm_id: id of the lsm to target
>> + * @op: Operation to perform (one of the LSM_POLICY_XXX values)
>> + * @buf: userspace pointer to policy data
>> + * @size: size of @buf
>> + * @flags: lsm policy management flags
>> + *
>> + * Manage the policies of a LSM. This notably allows to update them even when
>> + * the lsmfs is unavailable is restricted. Currently, only LSM_POLICY_LOAD is
>> + * supported.
>> + *
>> + * Return: Returns 0 on success, error on failure.
>> + */
>> +int security_lsm_manage_policy(u32 lsm_id, u32 op, void __user *buf,
>> + size_t size, u32 flags)
>> +{
>> + return call_int_hook(lsm_manage_policy, lsm_id, op, buf, size, flags);
>
> If the LSM doesn't implement this hook, sys_lsm_manage_policy will return 0
> for any inputs, right? This is gonna be so confusing for users.
Indeed, that was an oversight. It will return -EOPNOTSUPP in the next patch revision.
>
> Thanks,
> Song
Thanks,
Maxime
^ permalink raw reply
* Re: [PATCH 1/3] Wire up the lsm_manage_policy syscall
From: Maxime Bélair @ 2025-05-07 15:37 UTC (permalink / raw)
To: Song Liu
Cc: linux-security-module, john.johansen, paul, jmorris, serge, mic,
kees, stephen.smalley.work, casey, takedakn, penguin-kernel,
linux-api, apparmor, linux-kernel
In-Reply-To: <CAPhsuW4qY9B3KdhqrUOZoNBWQmO_RDwbH46my314WxrFwxbwkQ@mail.gmail.com>
On 5/7/25 08:26, Song Liu wrote:
> On Tue, May 6, 2025 at 7:40 AM Maxime Bélair
> <maxime.belair@canonical.com> wrote:
>>
>> Add support for the new lsm_manage_policy syscall, providing a unified
>> API for loading and modifying LSM policies without requiring the LSM’s
>> pseudo-filesystem.
>>
>> Benefits:
>> - Works even if the LSM pseudo-filesystem isn’t mounted or available
>> (e.g. in containers)
>> - Offers a logical and unified interface rather than multiple
>> heterogeneous pseudo-filesystems.
>
> These two do not feel like real benefits:
> - One syscall cannot fit all use cases well...
This syscall is not intended to cover every case, nor to replace existing kernel
interfaces.
Each LSM can decide which operations it wants to support (if any). For example, when
loading policies, an LSM may choose to allow only policies that further restrict
privileges.
> - Not working in containers is often not an issue, but a feature.
Indeed, using this syscall requires appropriate capabilities and will not permit
unprivileged containers to manage policies arbitrarily.
With this syscall, capability checks remain the responsibility of each LSM.
For instance, in the AppArmor patch, a profile can be loaded only if
aa_policy_admin_capable() succeeds (which requires CAP_MAC_ADMIN). Moreover, by design,
policies can be loaded only in the current namespace.
I see this syscall as a middle point between exposing the entire sysfs, creating a large
attack surface, and blocking everything.
Landlock’s existing syscalls already improve security by allowing processes to further
restrict their ambient rights while adding only a modest attack surface.
This syscall is a further step in that direction: it lets LSMs add restrictive policies
without requiring exposing every other interface.
Again, each module decides which operations to expose through this syscall. In many cases
the operation will still require CAP_SYS_ADMIN or a similar capability, so environments
that choose this interface remain secure while gaining its advantages.
>> - Avoids overhead of other kernel interfaces for better efficiency
>
> .. and it is is probably less efficient, because everything need to
> fit in the same API.
As shown below, the syscall can significantly improve the performance of policy management.
A more detailed benchmark is available in [1].
The following table presents the time required to load an AppArmor profile.
For every cell, the first value is the total time taken by aa-load, and the value in
parentheses is the time spent to load the policy in the kernel only (total - dry‑run).
Results are in microseconds and are averaged over 10 000 runs to reduce variance.
| t (µs) | syscall | pseudofs | Speedup |
|-----------|-------------|-------------|---------------|
| 1password | 4257 (1127) | 3333 (192) | x1.28 (x5.86) |
| Xorg | 6099 (2961) | 5167 (2020) | x1.18 (x1.47) |
If an LSM wants to allow several operations for a single LSM_POLICY_XXX it can multiplex a sub‑opcode in flags, and select the appropriate handler, this incurs negligible overhead.
Thanks,
Maxime
[1] https://gitlab.com/-/snippets/4840792
^ permalink raw reply
* Re: [PATCH v12 17/17] xfs: allow sysadmins to specify a maximum atomic write limit at mount time
From: John Garry @ 2025-05-07 15:14 UTC (permalink / raw)
To: brauner, djwong, hch, viro, jack, cem
Cc: linux-fsdevel, dchinner, linux-xfs, linux-kernel, ojaswin,
ritesh.list, martin.petersen, linux-ext4, linux-block,
catherine.hoang, linux-api
In-Reply-To: <20250506090427.2549456-18-john.g.garry@oracle.com>
On 06/05/2025 10:04, John Garry wrote:
> From: "Darrick J. Wong"<djwong@kernel.org>
>
> Introduce a mount option to allow sysadmins to specify the maximum size
> of an atomic write. If the filesystem can work with the supplied value,
> that becomes the new guaranteed maximum.
>
> The value mustn't be too big for the existing filesystem geometry (max
> write size, max AG/rtgroup size). We dynamically recompute the
> tr_atomic_write transaction reservation based on the given block size,
> check that the current log size isn't less than the new minimum log size
> constraints, and set a new maximum.
>
> The actual software atomic write max is still computed based off of
> tr_atomic_ioend the same way it has for the past few commits. Note also
> that xfs_calc_atomic_write_log_geometry is non-static because mkfs will
> need that.
>
> Signed-off-by: Darrick J. Wong<djwong@kernel.org>
> Signed-off-by: John Garry<john.g.garry@oracle.com>
Reviewed-by: John Garry <john.g.garry@oracle.com>
^ permalink raw reply
* Re: [PATCH 1/3] Wire up the lsm_manage_policy syscall
From: kernel test robot @ 2025-05-07 13:58 UTC (permalink / raw)
To: Maxime Bélair, linux-security-module
Cc: llvm, oe-kbuild-all, john.johansen, paul, jmorris, serge, mic,
kees, stephen.smalley.work, casey, takedakn, penguin-kernel,
linux-api, apparmor, linux-kernel, Maxime Bélair
In-Reply-To: <20250506143254.718647-2-maxime.belair@canonical.com>
Hi Maxime,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 9c32cda43eb78f78c73aee4aa344b777714e259b]
url: https://github.com/intel-lab-lkp/linux/commits/Maxime-B-lair/Wire-up-the-lsm_manage_policy-syscall/20250506-224212
base: 9c32cda43eb78f78c73aee4aa344b777714e259b
patch link: https://lore.kernel.org/r/20250506143254.718647-2-maxime.belair%40canonical.com
patch subject: [PATCH 1/3] Wire up the lsm_manage_policy syscall
config: s390-allnoconfig (https://download.01.org/0day-ci/archive/20250507/202505072131.ogtsaLPI-lkp@intel.com/config)
compiler: clang version 21.0.0git (https://github.com/llvm/llvm-project f819f46284f2a79790038e1f6649172789734ae8)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250507/202505072131.ogtsaLPI-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202505072131.ogtsaLPI-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> <stdin>:1618:2: warning: syscall lsm_manage_policy not implemented [-W#warnings]
1618 | #warning syscall lsm_manage_policy not implemented
| ^
1 warning generated.
--
>> <stdin>:1618:2: warning: syscall lsm_manage_policy not implemented [-W#warnings]
1618 | #warning syscall lsm_manage_policy not implemented
| ^
1 warning generated.
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 2/3] lsm: introduce security_lsm_manage_policy hook
From: kernel test robot @ 2025-05-07 12:04 UTC (permalink / raw)
To: Maxime Bélair, linux-security-module
Cc: oe-kbuild-all, john.johansen, paul, jmorris, serge, mic, kees,
stephen.smalley.work, casey, takedakn, penguin-kernel, linux-api,
apparmor, linux-kernel, Maxime Bélair
In-Reply-To: <20250506143254.718647-3-maxime.belair@canonical.com>
Hi Maxime,
kernel test robot noticed the following build errors:
[auto build test ERROR on 9c32cda43eb78f78c73aee4aa344b777714e259b]
url: https://github.com/intel-lab-lkp/linux/commits/Maxime-B-lair/Wire-up-the-lsm_manage_policy-syscall/20250506-224212
base: 9c32cda43eb78f78c73aee4aa344b777714e259b
patch link: https://lore.kernel.org/r/20250506143254.718647-3-maxime.belair%40canonical.com
patch subject: [PATCH 2/3] lsm: introduce security_lsm_manage_policy hook
config: riscv-allnoconfig (https://download.01.org/0day-ci/archive/20250507/202505071924.MeIKUbEX-lkp@intel.com/config)
compiler: riscv64-linux-gcc (GCC) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250507/202505071924.MeIKUbEX-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202505071924.MeIKUbEX-lkp@intel.com/
All error/warnings (new ones prefixed by >>):
include/linux/perf_event.h:2034:1: note: in expansion of macro 'DECLARE_STATIC_CALL'
2034 | DECLARE_STATIC_CALL(perf_snapshot_branch_stack, perf_snapshot_branch_stack_t);
| ^~~~~~~~~~~~~~~~~~~
include/linux/static_call_types.h:15:41: error: storage class specified for parameter '__SCT__perf_snapshot_branch_stack'
15 | #define STATIC_CALL_TRAMP_PREFIX __SCT__
| ^~~~~~~
include/linux/compiler_types.h:83:23: note: in definition of macro '___PASTE'
83 | #define ___PASTE(a,b) a##b
| ^
include/linux/static_call_types.h:18:41: note: in expansion of macro '__PASTE'
18 | #define STATIC_CALL_TRAMP(name) __PASTE(STATIC_CALL_TRAMP_PREFIX, name)
| ^~~~~~~
include/linux/static_call_types.h:18:49: note: in expansion of macro 'STATIC_CALL_TRAMP_PREFIX'
18 | #define STATIC_CALL_TRAMP(name) __PASTE(STATIC_CALL_TRAMP_PREFIX, name)
| ^~~~~~~~~~~~~~~~~~~~~~~~
include/linux/static_call_types.h:39:29: note: in expansion of macro 'STATIC_CALL_TRAMP'
39 | extern typeof(func) STATIC_CALL_TRAMP(name);
| ^~~~~~~~~~~~~~~~~
include/linux/perf_event.h:2034:1: note: in expansion of macro 'DECLARE_STATIC_CALL'
2034 | DECLARE_STATIC_CALL(perf_snapshot_branch_stack, perf_snapshot_branch_stack_t);
| ^~~~~~~~~~~~~~~~~~~
include/linux/perf_event.h:2034:78: error: expected declaration specifiers before ';' token
2034 | DECLARE_STATIC_CALL(perf_snapshot_branch_stack, perf_snapshot_branch_stack_t);
| ^
include/linux/perf_event.h:2038:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
2038 | {
| ^
In file included from arch/riscv/include/asm/kvm_vcpu_pmu.h:14:
arch/riscv/include/asm/sbi.h:15:1: warning: empty declaration
15 | enum sbi_ext_id {
| ^~~~
arch/riscv/include/asm/sbi.h:48:1: warning: empty declaration
48 | enum sbi_ext_base_fid {
| ^~~~
arch/riscv/include/asm/sbi.h:58:1: warning: empty declaration
58 | enum sbi_ext_time_fid {
| ^~~~
arch/riscv/include/asm/sbi.h:62:1: warning: empty declaration
62 | enum sbi_ext_ipi_fid {
| ^~~~
arch/riscv/include/asm/sbi.h:66:1: warning: empty declaration
66 | enum sbi_ext_rfence_fid {
| ^~~~
arch/riscv/include/asm/sbi.h:76:1: warning: empty declaration
76 | enum sbi_ext_hsm_fid {
| ^~~~
arch/riscv/include/asm/sbi.h:83:1: warning: empty declaration
83 | enum sbi_hsm_hart_state {
| ^~~~
arch/riscv/include/asm/sbi.h:106:1: warning: empty declaration
106 | enum sbi_ext_srst_fid {
| ^~~~
arch/riscv/include/asm/sbi.h:110:1: warning: empty declaration
110 | enum sbi_srst_reset_type {
| ^~~~
arch/riscv/include/asm/sbi.h:116:1: warning: empty declaration
116 | enum sbi_srst_reset_reason {
| ^~~~
arch/riscv/include/asm/sbi.h:121:1: warning: empty declaration
121 | enum sbi_ext_susp_fid {
| ^~~~
arch/riscv/include/asm/sbi.h:125:1: warning: empty declaration
125 | enum sbi_ext_susp_sleep_type {
| ^~~~
arch/riscv/include/asm/sbi.h:129:1: warning: empty declaration
129 | enum sbi_ext_pmu_fid {
| ^~~~
arch/riscv/include/asm/sbi.h:140:1: warning: empty declaration
140 | union sbi_pmu_ctr_info {
| ^~~~~
arch/riscv/include/asm/sbi.h:155:1: warning: empty declaration
155 | struct riscv_pmu_snapshot_data {
| ^~~~~~
arch/riscv/include/asm/sbi.h:167:1: warning: empty declaration
167 | enum sbi_pmu_hw_generic_events_t {
| ^~~~
arch/riscv/include/asm/sbi.h:188:1: warning: empty declaration
188 | enum sbi_pmu_fw_generic_events_t {
| ^~~~
arch/riscv/include/asm/sbi.h:217:1: warning: empty declaration
217 | enum sbi_pmu_event_type {
| ^~~~
arch/riscv/include/asm/sbi.h:225:1: warning: empty declaration
225 | enum sbi_pmu_ctr_type {
| ^~~~
arch/riscv/include/asm/sbi.h:265:1: warning: empty declaration
265 | enum sbi_ext_dbcn_fid {
| ^~~~
arch/riscv/include/asm/sbi.h:272:1: warning: empty declaration
272 | enum sbi_ext_sta_fid {
| ^~~~
arch/riscv/include/asm/sbi.h:276:1: warning: empty declaration
276 | struct sbi_sta_struct {
| ^~~~~~
arch/riscv/include/asm/sbi.h:286:1: warning: empty declaration
286 | enum sbi_ext_nacl_fid {
| ^~~~
arch/riscv/include/asm/sbi.h:294:1: warning: empty declaration
294 | enum sbi_ext_nacl_feature {
| ^~~~
>> arch/riscv/include/asm/sbi.h:423:22: error: storage class specified for parameter 'sbi_spec_version'
423 | extern unsigned long sbi_spec_version;
| ^~~~~~~~~~~~~~~~
arch/riscv/include/asm/sbi.h:424:1: warning: empty declaration
424 | struct sbiret {
| ^~~~~~
>> arch/riscv/include/asm/sbi.h:442:48: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
442 | static inline void sbi_console_putchar(int ch) { }
| ^
arch/riscv/include/asm/sbi.h:443:45: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
443 | static inline int sbi_console_getchar(void) { return -ENOENT; }
| ^
arch/riscv/include/asm/sbi.h:475:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
475 | {
| ^
arch/riscv/include/asm/sbi.h:481:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
481 | {
| ^
arch/riscv/include/asm/sbi.h:488:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
488 | {
| ^
arch/riscv/include/asm/sbi.h:495:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
495 | {
| ^
arch/riscv/include/asm/sbi.h:501:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
501 | {
| ^
>> arch/riscv/include/asm/sbi.h:518:13: error: storage class specified for parameter 'sbi_debug_console_available'
518 | extern bool sbi_debug_console_available;
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/riscv/include/asm/sbi.h:539:51: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
539 | static inline bool riscv_use_sbi_for_rfence(void) { return false; }
| ^
arch/riscv/include/asm/sbi.h:540:39: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
540 | static inline void sbi_ipi_init(void) { }
| ^
arch/riscv/include/asm/kvm_vcpu_pmu.h:105:1: warning: empty declaration
105 | struct kvm_pmu {
| ^~~~~~
>> arch/riscv/include/asm/kvm_vcpu_pmu.h:111:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
111 | {
| ^
arch/riscv/include/asm/kvm_vcpu_pmu.h:123:67: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
123 | static inline void kvm_riscv_vcpu_pmu_init(struct kvm_vcpu *vcpu) {}
| ^
arch/riscv/include/asm/kvm_vcpu_pmu.h:125:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
125 | {
| ^
arch/riscv/include/asm/kvm_vcpu_pmu.h:129:69: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
129 | static inline void kvm_riscv_vcpu_pmu_deinit(struct kvm_vcpu *vcpu) {}
| ^
arch/riscv/include/asm/kvm_vcpu_pmu.h:130:68: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
130 | static inline void kvm_riscv_vcpu_pmu_reset(struct kvm_vcpu *vcpu) {}
| ^
arch/riscv/include/asm/kvm_host.h:57:1: warning: empty declaration
57 | enum kvm_riscv_hfence_type {
| ^~~~
arch/riscv/include/asm/kvm_host.h:65:1: warning: empty declaration
65 | struct kvm_riscv_hfence {
| ^~~~~~
arch/riscv/include/asm/kvm_host.h:75:1: warning: empty declaration
75 | struct kvm_vm_stat {
| ^~~~~~
arch/riscv/include/asm/kvm_host.h:79:1: warning: empty declaration
79 | struct kvm_vcpu_stat {
| ^~~~~~
arch/riscv/include/asm/kvm_host.h:97:1: warning: empty declaration
97 | struct kvm_arch_memory_slot {
| ^~~~~~
arch/riscv/include/asm/kvm_host.h:100:1: warning: empty declaration
100 | struct kvm_vmid {
| ^~~~~~
arch/riscv/include/asm/kvm_host.h:109:1: warning: empty declaration
109 | struct kvm_arch {
| ^~~~~~
arch/riscv/include/asm/kvm_host.h:124:1: warning: empty declaration
124 | struct kvm_cpu_trap {
| ^~~~~~
arch/riscv/include/asm/kvm_host.h:132:1: warning: empty declaration
132 | struct kvm_cpu_context {
| ^~~~~~
arch/riscv/include/asm/kvm_host.h:172:1: warning: empty declaration
172 | struct kvm_vcpu_csr {
| ^~~~~~
arch/riscv/include/asm/kvm_host.h:186:1: warning: empty declaration
186 | struct kvm_vcpu_config {
| ^~~~~~
arch/riscv/include/asm/kvm_host.h:192:1: warning: empty declaration
192 | struct kvm_vcpu_smstateen_csr {
| ^~~~~~
arch/riscv/include/asm/kvm_host.h:196:1: warning: empty declaration
196 | struct kvm_vcpu_arch {
| ^~~~~~
>> arch/riscv/include/asm/kvm_host.h:300:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
300 | {
| ^
>> arch/riscv/include/asm/kvm_host.h:365:13: error: section attribute not allowed for 'kvm_riscv_gstage_mode_detect'
365 | void __init kvm_riscv_gstage_mode_detect(void);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/riscv/include/asm/kvm_host.h:365:1: warning: 'cold' attribute ignored [-Wattributes]
365 | void __init kvm_riscv_gstage_mode_detect(void);
| ^~~~
>> arch/riscv/include/asm/kvm_host.h:366:22: error: section attribute not allowed for 'kvm_riscv_gstage_mode'
366 | unsigned long __init kvm_riscv_gstage_mode(void);
| ^~~~~~~~~~~~~~~~~~~~~
arch/riscv/include/asm/kvm_host.h:366:1: warning: 'cold' attribute ignored [-Wattributes]
366 | unsigned long __init kvm_riscv_gstage_mode(void);
| ^~~~~~~~
>> arch/riscv/include/asm/kvm_host.h:369:13: error: section attribute not allowed for 'kvm_riscv_gstage_vmid_detect'
369 | void __init kvm_riscv_gstage_vmid_detect(void);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/riscv/include/asm/kvm_host.h:369:1: warning: 'cold' attribute ignored [-Wattributes]
369 | void __init kvm_riscv_gstage_vmid_detect(void);
| ^~~~
In file included from arch/riscv/kernel/asm-offsets.c:15:
>> arch/riscv/include/asm/cpu_ops_sbi.h:13:36: error: storage class specified for parameter 'cpu_ops_sbi'
13 | extern const struct cpu_operations cpu_ops_sbi;
| ^~~~~~~~~~~
arch/riscv/include/asm/cpu_ops_sbi.h:21:1: warning: empty declaration
21 | struct sbi_hart_boot_data {
| ^~~~~~
In file included from arch/riscv/kernel/asm-offsets.c:16:
arch/riscv/include/asm/stacktrace.h:9:1: warning: empty declaration
9 | struct stackframe {
| ^~~~~~
>> arch/riscv/include/asm/stacktrace.h:14:21: error: storage class specified for parameter 'walk_stackframe'
14 | extern void notrace walk_stackframe(struct task_struct *task, struct pt_regs *regs,
| ^~~~~~~~~~~~~~~
>> arch/riscv/include/asm/stacktrace.h:14:21: error: 'no_instrument_function' attribute applies only to functions
>> arch/riscv/include/asm/stacktrace.h:16:13: error: storage class specified for parameter 'dump_backtrace'
16 | extern void dump_backtrace(struct pt_regs *regs, struct task_struct *task,
| ^~~~~~~~~~~~~~
>> arch/riscv/include/asm/stacktrace.h:20:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
20 | {
| ^
In file included from arch/riscv/kernel/asm-offsets.c:17:
arch/riscv/include/asm/suspend.h:12:1: warning: empty declaration
12 | struct suspend_context {
| ^~~~~~
>> arch/riscv/include/asm/suspend.h:31:12: error: storage class specified for parameter 'in_suspend'
31 | extern int in_suspend;
| ^~~~~~~~~~
>> arch/riscv/kernel/asm-offsets.c:22:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
22 | {
| ^
include/linux/security.h:1607:12: error: old-style parameter declarations in prototyped function definition
1607 | static int security_lsm_manage_policy(u32 lsm_id, u32 op, void __user *buf,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
>> arch/riscv/kernel/asm-offsets.c:514: error: expected '{' at end of input
>> arch/riscv/kernel/asm-offsets.c:513:1: warning: no return statement in function returning non-void [-Wreturn-type]
513 | }
| ^
include/linux/security.h: At top level:
include/linux/security.h:1607:12: warning: 'security_lsm_manage_policy' defined but not used [-Wunused-function]
1607 | static int security_lsm_manage_policy(u32 lsm_id, u32 op, void __user *buf,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
make[3]: *** [scripts/Makefile.build:98: arch/riscv/kernel/asm-offsets.s] Error 1
make[3]: Target 'prepare' not remade because of errors.
make[2]: *** [Makefile:1282: prepare0] Error 2
make[2]: Target 'prepare' not remade because of errors.
make[1]: *** [Makefile:248: __sub-make] Error 2
make[1]: Target 'prepare' not remade because of errors.
make: *** [Makefile:248: __sub-make] Error 2
make: Target 'prepare' not remade because of errors.
vim +/sbi_spec_version +423 arch/riscv/include/asm/sbi.h
6cfc624576a641 Andrew Jones 2023-12-20 275
6cfc624576a641 Andrew Jones 2023-12-20 @276 struct sbi_sta_struct {
6cfc624576a641 Andrew Jones 2023-12-20 277 __le32 sequence;
6cfc624576a641 Andrew Jones 2023-12-20 278 __le32 flags;
6cfc624576a641 Andrew Jones 2023-12-20 279 __le64 steal;
6cfc624576a641 Andrew Jones 2023-12-20 280 u8 preempted;
6cfc624576a641 Andrew Jones 2023-12-20 281 u8 pad[47];
6cfc624576a641 Andrew Jones 2023-12-20 282 } __packed;
6cfc624576a641 Andrew Jones 2023-12-20 283
3ddb6d4df67dad Atish Patra 2024-04-20 284 #define SBI_SHMEM_DISABLE -1
6cfc624576a641 Andrew Jones 2023-12-20 285
5daf89e73d77a5 Anup Patel 2024-10-21 286 enum sbi_ext_nacl_fid {
5daf89e73d77a5 Anup Patel 2024-10-21 287 SBI_EXT_NACL_PROBE_FEATURE = 0x0,
5daf89e73d77a5 Anup Patel 2024-10-21 288 SBI_EXT_NACL_SET_SHMEM = 0x1,
5daf89e73d77a5 Anup Patel 2024-10-21 289 SBI_EXT_NACL_SYNC_CSR = 0x2,
5daf89e73d77a5 Anup Patel 2024-10-21 290 SBI_EXT_NACL_SYNC_HFENCE = 0x3,
5daf89e73d77a5 Anup Patel 2024-10-21 291 SBI_EXT_NACL_SYNC_SRET = 0x4,
5daf89e73d77a5 Anup Patel 2024-10-21 292 };
5daf89e73d77a5 Anup Patel 2024-10-21 293
5daf89e73d77a5 Anup Patel 2024-10-21 @294 enum sbi_ext_nacl_feature {
5daf89e73d77a5 Anup Patel 2024-10-21 295 SBI_NACL_FEAT_SYNC_CSR = 0x0,
5daf89e73d77a5 Anup Patel 2024-10-21 296 SBI_NACL_FEAT_SYNC_HFENCE = 0x1,
5daf89e73d77a5 Anup Patel 2024-10-21 297 SBI_NACL_FEAT_SYNC_SRET = 0x2,
5daf89e73d77a5 Anup Patel 2024-10-21 298 SBI_NACL_FEAT_AUTOSWAP_CSR = 0x3,
5daf89e73d77a5 Anup Patel 2024-10-21 299 };
5daf89e73d77a5 Anup Patel 2024-10-21 300
5daf89e73d77a5 Anup Patel 2024-10-21 301 #define SBI_NACL_SHMEM_ADDR_SHIFT 12
5daf89e73d77a5 Anup Patel 2024-10-21 302 #define SBI_NACL_SHMEM_SCRATCH_OFFSET 0x0000
5daf89e73d77a5 Anup Patel 2024-10-21 303 #define SBI_NACL_SHMEM_SCRATCH_SIZE 0x1000
5daf89e73d77a5 Anup Patel 2024-10-21 304 #define SBI_NACL_SHMEM_SRET_OFFSET 0x0000
5daf89e73d77a5 Anup Patel 2024-10-21 305 #define SBI_NACL_SHMEM_SRET_SIZE 0x0200
5daf89e73d77a5 Anup Patel 2024-10-21 306 #define SBI_NACL_SHMEM_AUTOSWAP_OFFSET (SBI_NACL_SHMEM_SRET_OFFSET + \
5daf89e73d77a5 Anup Patel 2024-10-21 307 SBI_NACL_SHMEM_SRET_SIZE)
5daf89e73d77a5 Anup Patel 2024-10-21 308 #define SBI_NACL_SHMEM_AUTOSWAP_SIZE 0x0080
5daf89e73d77a5 Anup Patel 2024-10-21 309 #define SBI_NACL_SHMEM_UNUSED_OFFSET (SBI_NACL_SHMEM_AUTOSWAP_OFFSET + \
5daf89e73d77a5 Anup Patel 2024-10-21 310 SBI_NACL_SHMEM_AUTOSWAP_SIZE)
5daf89e73d77a5 Anup Patel 2024-10-21 311 #define SBI_NACL_SHMEM_UNUSED_SIZE 0x0580
5daf89e73d77a5 Anup Patel 2024-10-21 312 #define SBI_NACL_SHMEM_HFENCE_OFFSET (SBI_NACL_SHMEM_UNUSED_OFFSET + \
5daf89e73d77a5 Anup Patel 2024-10-21 313 SBI_NACL_SHMEM_UNUSED_SIZE)
5daf89e73d77a5 Anup Patel 2024-10-21 314 #define SBI_NACL_SHMEM_HFENCE_SIZE 0x0780
5daf89e73d77a5 Anup Patel 2024-10-21 315 #define SBI_NACL_SHMEM_DBITMAP_OFFSET (SBI_NACL_SHMEM_HFENCE_OFFSET + \
5daf89e73d77a5 Anup Patel 2024-10-21 316 SBI_NACL_SHMEM_HFENCE_SIZE)
5daf89e73d77a5 Anup Patel 2024-10-21 317 #define SBI_NACL_SHMEM_DBITMAP_SIZE 0x0080
5daf89e73d77a5 Anup Patel 2024-10-21 318 #define SBI_NACL_SHMEM_CSR_OFFSET (SBI_NACL_SHMEM_DBITMAP_OFFSET + \
5daf89e73d77a5 Anup Patel 2024-10-21 319 SBI_NACL_SHMEM_DBITMAP_SIZE)
5daf89e73d77a5 Anup Patel 2024-10-21 320 #define SBI_NACL_SHMEM_CSR_SIZE ((__riscv_xlen / 8) * 1024)
5daf89e73d77a5 Anup Patel 2024-10-21 321 #define SBI_NACL_SHMEM_SIZE (SBI_NACL_SHMEM_CSR_OFFSET + \
5daf89e73d77a5 Anup Patel 2024-10-21 322 SBI_NACL_SHMEM_CSR_SIZE)
5daf89e73d77a5 Anup Patel 2024-10-21 323
5daf89e73d77a5 Anup Patel 2024-10-21 324 #define SBI_NACL_SHMEM_CSR_INDEX(__csr_num) \
5daf89e73d77a5 Anup Patel 2024-10-21 325 ((((__csr_num) & 0xc00) >> 2) | ((__csr_num) & 0xff))
5daf89e73d77a5 Anup Patel 2024-10-21 326
5daf89e73d77a5 Anup Patel 2024-10-21 327 #define SBI_NACL_SHMEM_HFENCE_ENTRY_SZ ((__riscv_xlen / 8) * 4)
5daf89e73d77a5 Anup Patel 2024-10-21 328 #define SBI_NACL_SHMEM_HFENCE_ENTRY_MAX \
5daf89e73d77a5 Anup Patel 2024-10-21 329 (SBI_NACL_SHMEM_HFENCE_SIZE / \
5daf89e73d77a5 Anup Patel 2024-10-21 330 SBI_NACL_SHMEM_HFENCE_ENTRY_SZ)
5daf89e73d77a5 Anup Patel 2024-10-21 331 #define SBI_NACL_SHMEM_HFENCE_ENTRY(__num) \
5daf89e73d77a5 Anup Patel 2024-10-21 332 (SBI_NACL_SHMEM_HFENCE_OFFSET + \
5daf89e73d77a5 Anup Patel 2024-10-21 333 (__num) * SBI_NACL_SHMEM_HFENCE_ENTRY_SZ)
5daf89e73d77a5 Anup Patel 2024-10-21 334 #define SBI_NACL_SHMEM_HFENCE_ENTRY_CONFIG(__num) \
5daf89e73d77a5 Anup Patel 2024-10-21 335 SBI_NACL_SHMEM_HFENCE_ENTRY(__num)
5daf89e73d77a5 Anup Patel 2024-10-21 336 #define SBI_NACL_SHMEM_HFENCE_ENTRY_PNUM(__num)\
5daf89e73d77a5 Anup Patel 2024-10-21 337 (SBI_NACL_SHMEM_HFENCE_ENTRY(__num) + (__riscv_xlen / 8))
5daf89e73d77a5 Anup Patel 2024-10-21 338 #define SBI_NACL_SHMEM_HFENCE_ENTRY_PCOUNT(__num)\
5daf89e73d77a5 Anup Patel 2024-10-21 339 (SBI_NACL_SHMEM_HFENCE_ENTRY(__num) + \
5daf89e73d77a5 Anup Patel 2024-10-21 340 ((__riscv_xlen / 8) * 3))
5daf89e73d77a5 Anup Patel 2024-10-21 341
5daf89e73d77a5 Anup Patel 2024-10-21 342 #define SBI_NACL_SHMEM_HFENCE_CONFIG_PEND_BITS 1
5daf89e73d77a5 Anup Patel 2024-10-21 343 #define SBI_NACL_SHMEM_HFENCE_CONFIG_PEND_SHIFT \
5daf89e73d77a5 Anup Patel 2024-10-21 344 (__riscv_xlen - SBI_NACL_SHMEM_HFENCE_CONFIG_PEND_BITS)
5daf89e73d77a5 Anup Patel 2024-10-21 345 #define SBI_NACL_SHMEM_HFENCE_CONFIG_PEND_MASK \
5daf89e73d77a5 Anup Patel 2024-10-21 346 ((1UL << SBI_NACL_SHMEM_HFENCE_CONFIG_PEND_BITS) - 1)
5daf89e73d77a5 Anup Patel 2024-10-21 347 #define SBI_NACL_SHMEM_HFENCE_CONFIG_PEND \
5daf89e73d77a5 Anup Patel 2024-10-21 348 (SBI_NACL_SHMEM_HFENCE_CONFIG_PEND_MASK << \
5daf89e73d77a5 Anup Patel 2024-10-21 349 SBI_NACL_SHMEM_HFENCE_CONFIG_PEND_SHIFT)
5daf89e73d77a5 Anup Patel 2024-10-21 350
5daf89e73d77a5 Anup Patel 2024-10-21 351 #define SBI_NACL_SHMEM_HFENCE_CONFIG_RSVD1_BITS 3
5daf89e73d77a5 Anup Patel 2024-10-21 352 #define SBI_NACL_SHMEM_HFENCE_CONFIG_RSVD1_SHIFT \
5daf89e73d77a5 Anup Patel 2024-10-21 353 (SBI_NACL_SHMEM_HFENCE_CONFIG_PEND_SHIFT - \
5daf89e73d77a5 Anup Patel 2024-10-21 354 SBI_NACL_SHMEM_HFENCE_CONFIG_RSVD1_BITS)
5daf89e73d77a5 Anup Patel 2024-10-21 355
5daf89e73d77a5 Anup Patel 2024-10-21 356 #define SBI_NACL_SHMEM_HFENCE_CONFIG_TYPE_BITS 4
5daf89e73d77a5 Anup Patel 2024-10-21 357 #define SBI_NACL_SHMEM_HFENCE_CONFIG_TYPE_SHIFT \
5daf89e73d77a5 Anup Patel 2024-10-21 358 (SBI_NACL_SHMEM_HFENCE_CONFIG_RSVD1_SHIFT - \
5daf89e73d77a5 Anup Patel 2024-10-21 359 SBI_NACL_SHMEM_HFENCE_CONFIG_TYPE_BITS)
5daf89e73d77a5 Anup Patel 2024-10-21 360 #define SBI_NACL_SHMEM_HFENCE_CONFIG_TYPE_MASK \
5daf89e73d77a5 Anup Patel 2024-10-21 361 ((1UL << SBI_NACL_SHMEM_HFENCE_CONFIG_TYPE_BITS) - 1)
5daf89e73d77a5 Anup Patel 2024-10-21 362
5daf89e73d77a5 Anup Patel 2024-10-21 363 #define SBI_NACL_SHMEM_HFENCE_TYPE_GVMA 0x0
5daf89e73d77a5 Anup Patel 2024-10-21 364 #define SBI_NACL_SHMEM_HFENCE_TYPE_GVMA_ALL 0x1
5daf89e73d77a5 Anup Patel 2024-10-21 365 #define SBI_NACL_SHMEM_HFENCE_TYPE_GVMA_VMID 0x2
5daf89e73d77a5 Anup Patel 2024-10-21 366 #define SBI_NACL_SHMEM_HFENCE_TYPE_GVMA_VMID_ALL 0x3
5daf89e73d77a5 Anup Patel 2024-10-21 367 #define SBI_NACL_SHMEM_HFENCE_TYPE_VVMA 0x4
5daf89e73d77a5 Anup Patel 2024-10-21 368 #define SBI_NACL_SHMEM_HFENCE_TYPE_VVMA_ALL 0x5
5daf89e73d77a5 Anup Patel 2024-10-21 369 #define SBI_NACL_SHMEM_HFENCE_TYPE_VVMA_ASID 0x6
5daf89e73d77a5 Anup Patel 2024-10-21 370 #define SBI_NACL_SHMEM_HFENCE_TYPE_VVMA_ASID_ALL 0x7
5daf89e73d77a5 Anup Patel 2024-10-21 371
5daf89e73d77a5 Anup Patel 2024-10-21 372 #define SBI_NACL_SHMEM_HFENCE_CONFIG_RSVD2_BITS 1
5daf89e73d77a5 Anup Patel 2024-10-21 373 #define SBI_NACL_SHMEM_HFENCE_CONFIG_RSVD2_SHIFT \
5daf89e73d77a5 Anup Patel 2024-10-21 374 (SBI_NACL_SHMEM_HFENCE_CONFIG_TYPE_SHIFT - \
5daf89e73d77a5 Anup Patel 2024-10-21 375 SBI_NACL_SHMEM_HFENCE_CONFIG_RSVD2_BITS)
5daf89e73d77a5 Anup Patel 2024-10-21 376
5daf89e73d77a5 Anup Patel 2024-10-21 377 #define SBI_NACL_SHMEM_HFENCE_CONFIG_ORDER_BITS 7
5daf89e73d77a5 Anup Patel 2024-10-21 378 #define SBI_NACL_SHMEM_HFENCE_CONFIG_ORDER_SHIFT \
5daf89e73d77a5 Anup Patel 2024-10-21 379 (SBI_NACL_SHMEM_HFENCE_CONFIG_RSVD2_SHIFT - \
5daf89e73d77a5 Anup Patel 2024-10-21 380 SBI_NACL_SHMEM_HFENCE_CONFIG_ORDER_BITS)
5daf89e73d77a5 Anup Patel 2024-10-21 381 #define SBI_NACL_SHMEM_HFENCE_CONFIG_ORDER_MASK \
5daf89e73d77a5 Anup Patel 2024-10-21 382 ((1UL << SBI_NACL_SHMEM_HFENCE_CONFIG_ORDER_BITS) - 1)
5daf89e73d77a5 Anup Patel 2024-10-21 383 #define SBI_NACL_SHMEM_HFENCE_ORDER_BASE 12
5daf89e73d77a5 Anup Patel 2024-10-21 384
5daf89e73d77a5 Anup Patel 2024-10-21 385 #if __riscv_xlen == 32
5daf89e73d77a5 Anup Patel 2024-10-21 386 #define SBI_NACL_SHMEM_HFENCE_CONFIG_ASID_BITS 9
5daf89e73d77a5 Anup Patel 2024-10-21 387 #define SBI_NACL_SHMEM_HFENCE_CONFIG_VMID_BITS 7
5daf89e73d77a5 Anup Patel 2024-10-21 388 #else
5daf89e73d77a5 Anup Patel 2024-10-21 389 #define SBI_NACL_SHMEM_HFENCE_CONFIG_ASID_BITS 16
5daf89e73d77a5 Anup Patel 2024-10-21 390 #define SBI_NACL_SHMEM_HFENCE_CONFIG_VMID_BITS 14
5daf89e73d77a5 Anup Patel 2024-10-21 391 #endif
5daf89e73d77a5 Anup Patel 2024-10-21 392 #define SBI_NACL_SHMEM_HFENCE_CONFIG_VMID_SHIFT \
5daf89e73d77a5 Anup Patel 2024-10-21 393 SBI_NACL_SHMEM_HFENCE_CONFIG_ASID_BITS
5daf89e73d77a5 Anup Patel 2024-10-21 394 #define SBI_NACL_SHMEM_HFENCE_CONFIG_ASID_MASK \
5daf89e73d77a5 Anup Patel 2024-10-21 395 ((1UL << SBI_NACL_SHMEM_HFENCE_CONFIG_ASID_BITS) - 1)
5daf89e73d77a5 Anup Patel 2024-10-21 396 #define SBI_NACL_SHMEM_HFENCE_CONFIG_VMID_MASK \
5daf89e73d77a5 Anup Patel 2024-10-21 397 ((1UL << SBI_NACL_SHMEM_HFENCE_CONFIG_VMID_BITS) - 1)
5daf89e73d77a5 Anup Patel 2024-10-21 398
5daf89e73d77a5 Anup Patel 2024-10-21 399 #define SBI_NACL_SHMEM_AUTOSWAP_FLAG_HSTATUS BIT(0)
5daf89e73d77a5 Anup Patel 2024-10-21 400 #define SBI_NACL_SHMEM_AUTOSWAP_HSTATUS ((__riscv_xlen / 8) * 1)
5daf89e73d77a5 Anup Patel 2024-10-21 401
5daf89e73d77a5 Anup Patel 2024-10-21 402 #define SBI_NACL_SHMEM_SRET_X(__i) ((__riscv_xlen / 8) * (__i))
5daf89e73d77a5 Anup Patel 2024-10-21 403 #define SBI_NACL_SHMEM_SRET_X_LAST 31
5daf89e73d77a5 Anup Patel 2024-10-21 404
6cfc624576a641 Andrew Jones 2023-12-20 405 /* SBI spec version fields */
b9dcd9e415872a Atish Patra 2020-03-17 406 #define SBI_SPEC_VERSION_DEFAULT 0x1
b9dcd9e415872a Atish Patra 2020-03-17 407 #define SBI_SPEC_VERSION_MAJOR_SHIFT 24
b9dcd9e415872a Atish Patra 2020-03-17 408 #define SBI_SPEC_VERSION_MAJOR_MASK 0x7f
b9dcd9e415872a Atish Patra 2020-03-17 409 #define SBI_SPEC_VERSION_MINOR_MASK 0xffffff
6d60b6ee0c9777 Palmer Dabbelt 2017-07-10 410
b9dcd9e415872a Atish Patra 2020-03-17 411 /* SBI return error codes */
b9dcd9e415872a Atish Patra 2020-03-17 412 #define SBI_SUCCESS 0
b9dcd9e415872a Atish Patra 2020-03-17 413 #define SBI_ERR_FAILURE -1
b9dcd9e415872a Atish Patra 2020-03-17 414 #define SBI_ERR_NOT_SUPPORTED -2
b9dcd9e415872a Atish Patra 2020-03-17 415 #define SBI_ERR_INVALID_PARAM -3
b9dcd9e415872a Atish Patra 2020-03-17 416 #define SBI_ERR_DENIED -4
b9dcd9e415872a Atish Patra 2020-03-17 417 #define SBI_ERR_INVALID_ADDRESS -5
3e1d86569c210e Atish Patra 2021-11-18 418 #define SBI_ERR_ALREADY_AVAILABLE -6
90beae5185c260 Atish Patra 2022-02-18 419 #define SBI_ERR_ALREADY_STARTED -7
90beae5185c260 Atish Patra 2022-02-18 420 #define SBI_ERR_ALREADY_STOPPED -8
8f486ced2860e1 Atish Patra 2024-04-20 421 #define SBI_ERR_NO_SHMEM -9
6d60b6ee0c9777 Palmer Dabbelt 2017-07-10 422
b9dcd9e415872a Atish Patra 2020-03-17 @423 extern unsigned long sbi_spec_version;
b9dcd9e415872a Atish Patra 2020-03-17 424 struct sbiret {
b9dcd9e415872a Atish Patra 2020-03-17 425 long error;
b9dcd9e415872a Atish Patra 2020-03-17 426 long value;
b9dcd9e415872a Atish Patra 2020-03-17 427 };
6d60b6ee0c9777 Palmer Dabbelt 2017-07-10 428
641e8cd2cbf045 Kefeng Wang 2020-11-26 429 void sbi_init(void);
1ff95eb2bebda5 Alexandre Ghiti 2024-08-29 430 long __sbi_base_ecall(int fid);
16badacd8af489 Alexandre Ghiti 2024-03-22 431 struct sbiret __sbi_ecall(unsigned long arg0, unsigned long arg1,
16badacd8af489 Alexandre Ghiti 2024-03-22 432 unsigned long arg2, unsigned long arg3,
16badacd8af489 Alexandre Ghiti 2024-03-22 433 unsigned long arg4, unsigned long arg5,
16badacd8af489 Alexandre Ghiti 2024-03-22 434 int fid, int ext);
16badacd8af489 Alexandre Ghiti 2024-03-22 435 #define sbi_ecall(e, f, a0, a1, a2, a3, a4, a5) \
16badacd8af489 Alexandre Ghiti 2024-03-22 436 __sbi_ecall(a0, a1, a2, a3, a4, a5, f, e)
6d60b6ee0c9777 Palmer Dabbelt 2017-07-10 437
f503b167b66007 Anup Patel 2023-11-24 438 #ifdef CONFIG_RISCV_SBI_V01
b9dcd9e415872a Atish Patra 2020-03-17 439 void sbi_console_putchar(int ch);
b9dcd9e415872a Atish Patra 2020-03-17 440 int sbi_console_getchar(void);
f503b167b66007 Anup Patel 2023-11-24 441 #else
f503b167b66007 Anup Patel 2023-11-24 @442 static inline void sbi_console_putchar(int ch) { }
f503b167b66007 Anup Patel 2023-11-24 443 static inline int sbi_console_getchar(void) { return -ENOENT; }
f503b167b66007 Anup Patel 2023-11-24 444 #endif
183787c6fcc2c7 Vincent Chen 2021-03-22 445 long sbi_get_mvendorid(void);
183787c6fcc2c7 Vincent Chen 2021-03-22 446 long sbi_get_marchid(void);
183787c6fcc2c7 Vincent Chen 2021-03-22 447 long sbi_get_mimpid(void);
b9dcd9e415872a Atish Patra 2020-03-17 448 void sbi_set_timer(uint64_t stime_value);
b9dcd9e415872a Atish Patra 2020-03-17 449 void sbi_shutdown(void);
832f15f4264681 Anup Patel 2023-03-28 450 void sbi_send_ipi(unsigned int cpu);
26fb751ca37846 Atish Patra 2022-01-20 451 int sbi_remote_fence_i(const struct cpumask *cpu_mask);
6d60b6ee0c9777 Palmer Dabbelt 2017-07-10 452
26fb751ca37846 Atish Patra 2022-01-20 453 int sbi_remote_sfence_vma_asid(const struct cpumask *cpu_mask,
b9dcd9e415872a Atish Patra 2020-03-17 454 unsigned long start,
b9dcd9e415872a Atish Patra 2020-03-17 455 unsigned long size,
b9dcd9e415872a Atish Patra 2020-03-17 456 unsigned long asid);
26fb751ca37846 Atish Patra 2022-01-20 457 int sbi_remote_hfence_gvma(const struct cpumask *cpu_mask,
1ef46c231df4b8 Atish Patra 2020-03-17 458 unsigned long start,
1ef46c231df4b8 Atish Patra 2020-03-17 459 unsigned long size);
26fb751ca37846 Atish Patra 2022-01-20 460 int sbi_remote_hfence_gvma_vmid(const struct cpumask *cpu_mask,
1ef46c231df4b8 Atish Patra 2020-03-17 461 unsigned long start,
1ef46c231df4b8 Atish Patra 2020-03-17 462 unsigned long size,
1ef46c231df4b8 Atish Patra 2020-03-17 463 unsigned long vmid);
26fb751ca37846 Atish Patra 2022-01-20 464 int sbi_remote_hfence_vvma(const struct cpumask *cpu_mask,
1ef46c231df4b8 Atish Patra 2020-03-17 465 unsigned long start,
1ef46c231df4b8 Atish Patra 2020-03-17 466 unsigned long size);
26fb751ca37846 Atish Patra 2022-01-20 467 int sbi_remote_hfence_vvma_asid(const struct cpumask *cpu_mask,
1ef46c231df4b8 Atish Patra 2020-03-17 468 unsigned long start,
1ef46c231df4b8 Atish Patra 2020-03-17 469 unsigned long size,
1ef46c231df4b8 Atish Patra 2020-03-17 470 unsigned long asid);
41cad8284d5e6b Andrew Jones 2023-04-27 471 long sbi_probe_extension(int ext);
6d60b6ee0c9777 Palmer Dabbelt 2017-07-10 472
b9dcd9e415872a Atish Patra 2020-03-17 473 /* Check if current SBI specification version is 0.1 or not */
b9dcd9e415872a Atish Patra 2020-03-17 474 static inline int sbi_spec_is_0_1(void)
6d60b6ee0c9777 Palmer Dabbelt 2017-07-10 475 {
b9dcd9e415872a Atish Patra 2020-03-17 476 return (sbi_spec_version == SBI_SPEC_VERSION_DEFAULT) ? 1 : 0;
6d60b6ee0c9777 Palmer Dabbelt 2017-07-10 477 }
6d60b6ee0c9777 Palmer Dabbelt 2017-07-10 478
b9dcd9e415872a Atish Patra 2020-03-17 479 /* Get the major version of SBI */
b9dcd9e415872a Atish Patra 2020-03-17 480 static inline unsigned long sbi_major_version(void)
6d60b6ee0c9777 Palmer Dabbelt 2017-07-10 481 {
b9dcd9e415872a Atish Patra 2020-03-17 482 return (sbi_spec_version >> SBI_SPEC_VERSION_MAJOR_SHIFT) &
b9dcd9e415872a Atish Patra 2020-03-17 483 SBI_SPEC_VERSION_MAJOR_MASK;
6d60b6ee0c9777 Palmer Dabbelt 2017-07-10 484 }
6d60b6ee0c9777 Palmer Dabbelt 2017-07-10 485
b9dcd9e415872a Atish Patra 2020-03-17 486 /* Get the minor version of SBI */
b9dcd9e415872a Atish Patra 2020-03-17 487 static inline unsigned long sbi_minor_version(void)
6d60b6ee0c9777 Palmer Dabbelt 2017-07-10 @488 {
b9dcd9e415872a Atish Patra 2020-03-17 489 return sbi_spec_version & SBI_SPEC_VERSION_MINOR_MASK;
6d60b6ee0c9777 Palmer Dabbelt 2017-07-10 490 }
f90b43ce176c12 Atish Patra 2020-03-17 491
b579dfe71a6a5c Anup Patel 2021-06-09 492 /* Make SBI version */
b579dfe71a6a5c Anup Patel 2021-06-09 493 static inline unsigned long sbi_mk_version(unsigned long major,
b579dfe71a6a5c Anup Patel 2021-06-09 494 unsigned long minor)
b579dfe71a6a5c Anup Patel 2021-06-09 495 {
b737fc24a12ceb Atish Patra 2024-04-20 496 return ((major & SBI_SPEC_VERSION_MAJOR_MASK) << SBI_SPEC_VERSION_MAJOR_SHIFT)
b737fc24a12ceb Atish Patra 2024-04-20 497 | (minor & SBI_SPEC_VERSION_MINOR_MASK);
b579dfe71a6a5c Anup Patel 2021-06-09 498 }
b579dfe71a6a5c Anup Patel 2021-06-09 499
1ff95eb2bebda5 Alexandre Ghiti 2024-08-29 500 static inline int sbi_err_map_linux_errno(int err)
1ff95eb2bebda5 Alexandre Ghiti 2024-08-29 501 {
1ff95eb2bebda5 Alexandre Ghiti 2024-08-29 502 switch (err) {
1ff95eb2bebda5 Alexandre Ghiti 2024-08-29 503 case SBI_SUCCESS:
1ff95eb2bebda5 Alexandre Ghiti 2024-08-29 504 return 0;
1ff95eb2bebda5 Alexandre Ghiti 2024-08-29 505 case SBI_ERR_DENIED:
1ff95eb2bebda5 Alexandre Ghiti 2024-08-29 506 return -EPERM;
1ff95eb2bebda5 Alexandre Ghiti 2024-08-29 507 case SBI_ERR_INVALID_PARAM:
1ff95eb2bebda5 Alexandre Ghiti 2024-08-29 508 return -EINVAL;
1ff95eb2bebda5 Alexandre Ghiti 2024-08-29 509 case SBI_ERR_INVALID_ADDRESS:
1ff95eb2bebda5 Alexandre Ghiti 2024-08-29 510 return -EFAULT;
1ff95eb2bebda5 Alexandre Ghiti 2024-08-29 511 case SBI_ERR_NOT_SUPPORTED:
1ff95eb2bebda5 Alexandre Ghiti 2024-08-29 512 case SBI_ERR_FAILURE:
1ff95eb2bebda5 Alexandre Ghiti 2024-08-29 513 default:
1ff95eb2bebda5 Alexandre Ghiti 2024-08-29 514 return -ENOTSUPP;
1ff95eb2bebda5 Alexandre Ghiti 2024-08-29 515 };
1ff95eb2bebda5 Alexandre Ghiti 2024-08-29 516 }
f43fabf444ca3c Anup Patel 2023-11-24 517
f43fabf444ca3c Anup Patel 2023-11-24 @518 extern bool sbi_debug_console_available;
f43fabf444ca3c Anup Patel 2023-11-24 519 int sbi_debug_console_write(const char *bytes, unsigned int num_bytes);
f43fabf444ca3c Anup Patel 2023-11-24 520 int sbi_debug_console_read(char *bytes, unsigned int num_bytes);
f43fabf444ca3c Anup Patel 2023-11-24 521
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 2/3] lsm: introduce security_lsm_manage_policy hook
From: Tetsuo Handa @ 2025-05-07 10:40 UTC (permalink / raw)
To: Maxime Bélair, linux-security-module
Cc: john.johansen, paul, jmorris, serge, mic, kees,
stephen.smalley.work, casey, takedakn, linux-api, apparmor,
linux-kernel
In-Reply-To: <20250506143254.718647-3-maxime.belair@canonical.com>
On 2025/05/06 23:32, Maxime Bélair wrote:
> diff --git a/security/lsm_syscalls.c b/security/lsm_syscalls.c
> index dcaad8818679..b39e6635a7d5 100644
> --- a/security/lsm_syscalls.c
> +++ b/security/lsm_syscalls.c
> @@ -122,5 +122,10 @@ SYSCALL_DEFINE3(lsm_list_modules, u64 __user *, ids, u32 __user *, size,
> SYSCALL_DEFINE5(lsm_manage_policy, u32, lsm_id, u32, op, void __user *, buf, u32
> __user *, size, u32, flags)
> {
> - return 0;
> + size_t usize;
> +
> + if (get_user(usize, size))
> + return -EFAULT;
> +
> + return security_lsm_manage_policy(lsm_id, op, buf, usize, flags);
> }
syzbot will report user-controlled unbounded huge size memory allocation attempt. ;-)
This interface might be fine for AppArmor, but TOMOYO won't use this interface because
TOMOYO's policy is line-oriented ASCII text data where the destination is switched via
pseudo‑filesystem's filename; use of filename helps restricting which type of policy
can be manipulated by which process.
^ permalink raw reply
* Re: [PATCH 1/3] Wire up the lsm_manage_policy syscall
From: Song Liu @ 2025-05-07 6:26 UTC (permalink / raw)
To: Maxime Bélair
Cc: linux-security-module, john.johansen, paul, jmorris, serge, mic,
kees, stephen.smalley.work, casey, takedakn, penguin-kernel,
linux-api, apparmor, linux-kernel
In-Reply-To: <20250506143254.718647-2-maxime.belair@canonical.com>
On Tue, May 6, 2025 at 7:40 AM Maxime Bélair
<maxime.belair@canonical.com> wrote:
>
> Add support for the new lsm_manage_policy syscall, providing a unified
> API for loading and modifying LSM policies without requiring the LSM’s
> pseudo-filesystem.
>
> Benefits:
> - Works even if the LSM pseudo-filesystem isn’t mounted or available
> (e.g. in containers)
> - Offers a logical and unified interface rather than multiple
> heterogeneous pseudo-filesystems.
These two do not feel like real benefits:
- Not working in containers is often not an issue, but a feature.
- One syscall cannot fit all use cases well...
> - Avoids overhead of other kernel interfaces for better efficiency
.. and it is is probably less efficient, because everything need to
fit in the same API.
Overall, this set doesn't feel like a good change to me.
Thanks,
Song
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox