On Fri, Nov 25, 2022 at 11:19 AM Mickaël Salaün [off-list ref] wrote:

On 24/11/2022 06:40, Greg KH wrote:

quoted

On Wed, Nov 23, 2022 at 12:15:44PM -0800, Casey Schaufler wrote:

quoted

Create a struct lsm_id to contain identifying information
about Linux Security Modules (LSMs). At inception this contains
the name of the module and an identifier associated with the
security module. Change the security_add_hooks() interface to
use this structure. Change the individual modules to maintain
their own struct lsm_id and pass it to security_add_hooks().

The values are for LSM identifiers are defined in a new UAPI
header file linux/lsm.h. Each existing LSM has been updated to
include it's LSMID in the lsm_id.

The LSM ID values are sequential, with the oldest module
LSM_ID_CAPABILITY being the lowest value and the existing modules
numbered in the order they were included in the main line kernel.
This is an arbitrary convention for assigning the values, but
none better presents itself. The value 0 is defined as being invalid.
The values 1-99 are reserved for any special case uses which may
arise in the future.

What would be a "special case" that deserves a lower number?

I don't see any meaningful use case for these reserved numbers either.
If there are some, let's put them now, otherwise we should start with 1.
Is it inspired by an existing UAPI?
Reserving 0 as invalid is good though.

I haven't finished reviewing this latest patchset, but I wanted to
comment on this quickly while I had a moment in front of a keyboard
... I did explain my desire and reasoning for this in a previous
revision of this patchset and I still believe the
reserved-for-potential-future-use to be a valid reason so I'm going to
ask for this to remain.  Several of you may disagree, but unless you
can provide a reason why these reserved values would *seriously* break
these, or potential future syscalls, I'm going to be stubborn and
insist we retain a set of low-numbered reserved values.

-- 
paul-moore.com