On November 28, 2022 2:51:55 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > On Sun, Nov 27, 2022 at 10:48:53PM -0500, Paul Moore wrote: >> On Fri, Nov 25, 2022 at 11:19 AM Mickaël Salaün <mic@xxxxxxxxxxx> wrote: >>> On 24/11/2022 06:40, Greg KH wrote: >>>> On Wed, Nov 23, 2022 at 12:15:44PM -0800, Casey Schaufler wrote: >>>>> 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. > > Then that reasoning and explaination needs to be here in the changelog > so that we understand and have a chance to agree/disagree with that. > Otherwise we, and everyone else, are left to just be confused. > > thanks, > > greg k-h The patch author should have done that considering I made my comments on the last revision. -- paul-moore.com
