Re: [PATCH v3 2/5] security: Count the LSMs enabled at compile time

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2023/09/19 6:24, KP Singh wrote:
> These macros are a clever trick to determine a count of the number of
> LSMs that are enabled in the config to ascertain the maximum number of
> static calls that need to be configured per LSM hook.

As a LKM-based LSM user, indirect function calls using a linked list have
an advantage which this series kills. There always is a situation where a
LSM cannot be built into vmlinux (and hence has to be loaded as a LKM-based
LSM) due to distributor's support policy. Therefore, honestly speaking,
I don't want LSM infrastructure to define the maximum number of "slots" or
"static calls"...

> 
> Without this one would need to generate static calls for (number of
> possible LSMs * number of LSM hooks) which ends up being quite wasteful
> especially when some LSMs are not compiled into the kernel.

I can't interpret "number of possible LSMs * number of LSM hooks" part.
Is this tokenized as "number of possible LSMs" (an integer) * (multipled by)
"number of LSM hooks" (an integer) ? But the next patch includes

  struct lsm_static_calls_table {
  #define LSM_HOOK(RET, DEFAULT, NAME, ...) \
  		struct lsm_static_call NAME[MAX_LSM_COUNT];
  	#include <linux/lsm_hook_defs.h>
  	#undef LSM_HOOK
  } __randomize_layout;

which seems to me that lsm_static_calls_table will get "number of possible
LSMs" static calls for each LSM hook defined in linux/lsm_hook_defs.h .
How did this patch help reducing static calls? What does "possible LSMs" mean?
Should "number of possible LSMs" be replaced with "number of built-in LSMs" ?

> Suggested-by: Andrii Nakryiko <andrii@xxxxxxxxxx

Trailing ">" is missing.

> +/*
> + * Macros to count the number of LSMs enabled in the kernel at compile time.
> + */
> +#define MAX_LSM_COUNT			\
> +	___COUNT_COMMAS(		\
> +		CAPABILITIES_ENABLED	\
> +		SELINUX_ENABLED		\
> +		SMACK_ENABLED		\
> +		APPARMOR_ENABLED	\
> +		TOMOYO_ENABLED		\
> +		YAMA_ENABLED		\
> +		LOADPIN_ENABLED		\
> +		LOCKDOWN_ENABLED	\
> +		BPF_LSM_ENABLED		\
> +		LANDLOCK_ENABLED)

Since IS_ENABLED(CONFIG_FOO) is evaluated to either 1 or 0, why can't you directly
do like IS_ENABLED(CONFIG_FOO) + IS_ENABLED(CONFIG_BAR) + IS_ENABLED(CONFIG_BUZ) ?
If you can't do direct "+", can't you still do indirect "+" like something below?

#if IS_ENABLED(CONFIG_FOO)
#define FOO_ENABLED 1
#else
#define FOO_ENABLED 0
#endif





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux