This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:
Single allocations: kmalloc(sizeof(TYPE), ...)
are replaced with: kmalloc_obj(TYPE, ...)
Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with: kmalloc_objs(TYPE, COUNT, ...)
Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...)
(where TYPE may also be *VAR)
The resulting allocations no longer return "void *", instead returning
"TYPE *".
Signed-off-by: Kees Cook <kees@kernel.org>
Convert lock initialization to scoped guarded initialization where
lock-guarded members are initialized in the same scope.
This ensures the context analysis treats the context as active during member
initialization. This is required to avoid errors once implicit context
assertion is removed.
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/20260119094029.1344361-6-elver@google.com
Enable context analysis for security/tomoyo.
This demonstrates a larger conversion to use Clang's context
analysis. The benefit is additional static checking of locking rules,
along with better documentation.
Tomoyo makes use of several synchronization primitives, yet its clear
design made it relatively straightforward to enable context analysis.
One notable finding was:
security/tomoyo/gc.c:664:20: error: reading variable 'write_buf' requires holding mutex '&tomoyo_io_buffer::io_sem'
664 | is_write = head->write_buf != NULL;
For which Tetsuo writes:
"Good catch. This should be data_race(), for tomoyo_write_control()
might concurrently update head->write_buf from non-NULL to non-NULL
with head->io_sem held."
Signed-off-by: Marco Elver <elver@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/20251219154418.3592607-35-elver@google.com
Commit 08ae2487b2 ("tomoyo: automatically use patterns for several
situations in learning mode") replaced only $PID part of procfs pathname
with \$ pattern. But it turned out that we need to also replace $TID part
and $FD part to make this functionality useful for e.g. /bin/lsof .
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
The "file_pattern" keyword was used for automatically recording patternized
pathnames when using the learning mode. This keyword was removed in TOMOYO
2.4 because it is impossible to predefine all possible pathname patterns.
However, since the numeric part of proc:/$PID/ , pipe:[$INO] and
socket:[$INO] has no meaning except $PID == 1, automatically replacing
the numeric part with \$ pattern helps reducing frequency of restarting
the learning mode due to hitting the quota.
Since replacing one digit with \$ pattern requires enlarging string buffer,
and several programs access only $PID == 1, replace only two or more digits
with \$ pattern.
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
syzbot is reporting too large allocation warning at tomoyo_write_control(),
for one can write a very very long line without new line character. To fix
this warning, I use __GFP_NOWARN rather than checking for KMALLOC_MAX_SIZE,
for practically a valid line should be always shorter than 32KB where the
"too small to fail" memory-allocation rule applies.
One might try to write a valid line that is longer than 32KB, but such
request will likely fail with -ENOMEM. Therefore, I feel that separately
returning -EINVAL when a line is longer than KMALLOC_MAX_SIZE is redundant.
There is no need to distinguish over-32KB and over-KMALLOC_MAX_SIZE.
Reported-by: syzbot+7536f77535e5210a5c76@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=7536f77535e5210a5c76
Reported-by: Leo Stone <leocstone@gmail.com>
Closes: https://lkml.kernel.org/r/20241216021459.178759-2-leocstone@gmail.com
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
This patch reverts two TOMOYO patches that were merged into Linus' tree
during the v6.12 merge window:
8b985bbfab ("tomoyo: allow building as a loadable LSM module")
268225a1de ("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 <john.johansen@canonical.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
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 <penguin-kernel@I-love.SAKURA.ne.jp>
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 <cgzones@googlemail.com>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
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 <vbabka@suse.cz>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Idiomatic way to find how much space sprintf output would take is
len = snprintf(NULL, 0, ...) + 1;
Once upon a time there'd been libc implementations that blew chunks
on that and somebody had come up with the following "cute" trick:
len = snprintf((char *) &len, 1, ...) + 1;
for doing the same. However, that's unidiomatic, harder to follow
*and* any such libc implementation would violate both C99 and POSIX
(since 2001).
IOW, this kludge is best buried along with such libc implementations,
nevermind getting cargo-culted into newer code. Our vsnprintf() does not
suffer that braindamage, TYVM.
Acked-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Since tomoyo_memory_ok() will check for null pointer returned by
kzalloc() in tomoyo_assign_profile(), tomoyo_assign_namespace(),
tomoyo_get_name() and tomoyo_commit_ok(), then emit OOM warnings
if needed. And this is the expected behavior as informed by
Tetsuo Handa.
Let's add __GFP_NOWARN to kzalloc() in those related functions.
Besides, to achieve this goal, remove the null check for entry
right after kzalloc() in tomoyo_assign_namespace().
Reported-by: Hulk Robot <hulkci@huawei.com>
Suggested-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Pull tomoyo update from Tetsuo Handa:
"One patch for suppressing coccicheck's warning"
* tag 'tomoyo-pr-20200601' of git://git.osdn.net/gitroot/tomoyo/tomoyo-test1:
tomoyo: use true for bool variable
John Garry has reported that allmodconfig kernel on arm64 causes flood of
"RCU-list traversed in non-reader section!!" warning. I don't know what
change caused this warning, but this warning is safe because TOMOYO uses
SRCU lock instead. Let's suppress this warning by explicitly telling that
the caller is holding SRCU lock.
Reported-and-tested-by: John Garry <john.garry@huawei.com>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Kees Cook
Marco ElverandPeter Zijlstra
Tetsuo Handa
Paul Moore
Christian GöttscheandTetsuo Handa
Vlastimil BabkaandTetsuo Handa
Al Viro
Lucas De Marchi
Zheng ZengkaiandTetsuo Handa
Gustavo A. R. Silva
Zou WeiandTetsuo Handa
