kernel/security/tomoyo/common.h, branch 0x221E-v0.0.1-v6.19

tomoyo: move initcalls to the LSM framework

2025-10-22T23:24:26Z

Reviewed-by: Kees Cook Reviewed-by: John Johansen Acked-by: Tetsuo Handa Signed-off-by: Paul Moore

tomoyo: revert CONFIG_SECURITY_TOMOYO_LKM support

2024-10-04T15:41:22Z

This patch reverts two TOMOYO patches that were merged into Linus' tree during the v6.12 merge window: 8b985bbfabbe ("tomoyo: allow building as a loadable LSM module") 268225a1de1a ("tomoyo: preparation step for building as a loadable LSM module") Together these two patches introduced the CONFIG_SECURITY_TOMOYO_LKM Kconfig build option which enabled a TOMOYO specific dynamic LSM loading mechanism (see the original commits for more details). Unfortunately, this approach was widely rejected by the LSM community as well as some members of the general kernel community. Objections included concerns over setting a bad precedent regarding individual LSMs managing their LSM callback registrations as well as general kernel symbol exporting practices. With little to no support for the CONFIG_SECURITY_TOMOYO_LKM approach outside of Tetsuo, and multiple objections, we need to revert these changes. Link: https://lore.kernel.org/all/0c4b443a-9c72-4800-97e8-a3816b6a9ae2@I-love.SAKURA.ne.jp Link: https://lore.kernel.org/all/CAHC9VhR=QjdoHG3wJgHFJkKYBg7vkQH2MpffgVzQ0tAByo_wRg@mail.gmail.com Acked-by: John Johansen Signed-off-by: Paul Moore

tomoyo: allow building as a loadable LSM module

2024-09-24T13:35:30Z

One of concerns for enabling TOMOYO in prebuilt kernels is that distributor wants to avoid bloating kernel packages. Although boot-time kernel command line options allows selecting built-in LSMs to enable, file size increase of vmlinux and memory footprint increase of vmlinux caused by builtin-but- not-enabled LSMs remains. If it becomes possible to make LSMs dynamically appendable after boot using loadable kernel modules, these problems will go away. Another of concerns for enabling TOMOYO in prebuilt kernels is that who can provide support when distributor cannot provide support. Due to "those who compiled kernel code is expected to provide support for that kernel code" spell, TOMOYO is failing to get enabled in Fedora distribution [1]. The point of loadable kernel module is to share the workload. If it becomes possible to make LSMs dynamically appendable after boot using loadable kernel modules, as with people can use device drivers not supported by distributors but provided by third party device vendors, we can break this spell and can lower the barrier for using TOMOYO. This patch is intended for demonstrating that there is nothing difficult for supporting TOMOYO-like loadable LSM modules. For now we need to live with a mixture of built-in part and loadable part because fully loadable LSM modules are not supported since Linux 2.6.24 [2] and number of LSMs which can reserve static call slots is determined at compile time in Linux 6.12. Major changes in this patch are described below. There are no behavior changes as long as TOMOYO is built into vmlinux. Add CONFIG_SECURITY_TOMOYO_LKM as "bool" instead of changing CONFIG_SECURITY_TOMOYO from "bool" to "tristate", for something went wrong with how Makefile is evaluated if I choose "tristate". Add proxy.c for serving as a bridge between vmlinux and tomoyo.ko . Move callback functions from init.c to proxy.c when building as a loadable LSM module. init.c is built-in part and remains for reserving static call slots. proxy.c contains module's init function and tells init.c location of callback functions, making it possible to use static call for tomoyo.ko . By deferring initialization of "struct tomoyo_task" until tomoyo.ko is loaded, threads created between init.c reserved LSM hooks and proxy.c updates LSM hooks will have NULL "struct tomoyo_task" instances. Assuming that tomoyo.ko is loaded by the moment when the global init process starts, initialize "struct tomoyo_task" instance for current thread as a kernel thread when tomoyo_task(current) is called for the first time. There is a hack for exporting currently not-exported functions. This hack will be removed after all relevant functions are exported. Link: https://bugzilla.redhat.com/show_bug.cgi?id=542986 [1] Link: https://lkml.kernel.org/r/caafb609-8bef-4840-a080-81537356fc60@I-love.SAKURA.ne.jp [2] Signed-off-by: Tetsuo Handa

tomoyo: remove unused function declaration

2023-08-13T13:07:15Z

The last usage of tomoyo_check_flags() has been removed by commit 57c2590fb7fd ("TOMOYO: Update profile structure."). Clean up its residual declaration. Signed-off-by: GONG, Ruiqi Signed-off-by: Tetsuo Handa

tomoyo: add format attributes to functions

2023-07-23T12:25:28Z

Format attributes on functions taking format string can help compilers detect argument type or count mismatches. Please the compiler when building with W=1: security/tomoyo/audit.c: In function ‘tomoyo_init_log’: security/tomoyo/audit.c:290:9: error: function ‘tomoyo_init_log’ might be a candidate for ‘gnu_printf’ format attribute [-Werror=suggest-attribute=format] 290 | vsnprintf(buf + pos, len - pos, fmt, args); | ^~~~~~~~~ security/tomoyo/audit.c: In function ‘tomoyo_write_log2’: security/tomoyo/audit.c:376:9: error: function ‘tomoyo_write_log2’ might be a candidate for ‘gnu_printf’ format attribute [-Werror=suggest-attribute=format] 376 | buf = tomoyo_init_log(r, len, fmt, args); | ^~~ security/tomoyo/common.c: In function ‘tomoyo_addprintf’: security/tomoyo/common.c:193:9: error: function ‘tomoyo_addprintf’ might be a candidate for ‘gnu_printf’ format attribute [-Werror=suggest-attribute=format] 193 | vsnprintf(buffer + pos, len - pos - 1, fmt, args); | ^~~~~~~~~ Signed-off-by: Christian Göttsche Signed-off-by: Tetsuo Handa

tomoyo: replace tomoyo_round2() with kmalloc_size_roundup()

2023-03-01T14:46:12Z

It seems tomoyo has had its own implementation of what kmalloc_size_roundup() does today. Remove the function tomoyo_round2() and replace it with kmalloc_size_roundup(). It provides more accurate results and doesn't contain a while loop. Signed-off-by: Vlastimil Babka Signed-off-by: Tetsuo Handa

tomoyo: Use str_yes_no()

2022-02-07T21:04:44Z

Remove the local yesno() implementation and adopt the str_yes_no() from linux/string_helpers.h. Signed-off-by: Lucas De Marchi Reviewed-by: Sakari Ailus Link: https://patchwork.freedesktop.org/patch/msgid/20220126093951.1470898-11-lucas.demarchi@intel.com

exec: Implement kernel_execve

2020-07-21T13:24:52Z

To allow the kernel not to play games with set_fs to call exec implement kernel_execve. The function kernel_execve takes pointers into kernel memory and copies the values pointed to onto the new userspace stack. The calls with arguments from kernel space of do_execve are replaced with calls to kernel_execve. The calls do_execve and do_execveat are made static as there are now no callers outside of exec. The comments that mention do_execve are updated to refer to kernel_execve or execve depending on the circumstances. In addition to correcting the comments, this makes it easy to grep for do_execve and verify it is not used. Inspired-by: https://lkml.kernel.org/r/20200627072704.2447163-1-hch@lst.de Reviewed-by: Kees Cook Link: https://lkml.kernel.org/r/87wo365ikj.fsf@x220.int.ebiederm.org Signed-off-by: "Eric W. Biederman"

tomoyo: Bump version.

2019-02-19T22:17:25Z

Update URLs and profile version. Signed-off-by: Tetsuo Handa Signed-off-by: James Morris

tomoyo: Allow multiple use_group lines.

2019-01-24T22:50:27Z

Being able to specify multiple "use_group" lines makes it easier to write whitelisted policies. Signed-off-by: Tetsuo Handa Signed-off-by: James Morris