On 11/9/2022 3:33 PM, Paul Moore wrote: > On Fri, Oct 28, 2022 at 12:55 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: >> On 10/26/2022 11:31 PM, Greg KH wrote: >>> On Wed, Oct 26, 2022 at 12:36:34PM -0700, Casey Schaufler wrote: >>>>>> + * >>>>>> + * Copyright (C) 2022 Casey Schaufler <casey@xxxxxxxxxxxxxxxx> >>>>>> + * Copyright (C) Intel Corporation >>>>> No date for Intel? >>>> The latest guidance I have received is that Intel does not want a date. >>> Ok, then I need to have an Intel lawyer sign off on a patch that does >>> this in order to have that be their official statement. Otherwise, it >>> needs a date. >> Seems I misunderstood something. The date will be there. >> >>>>>> + */ >>>>>> + >>>>>> +#ifndef _UAPI_LINUX_LSM_H >>>>>> +#define _UAPI_LINUX_LSM_H >>>>>> + >>>>>> +/* >>>>>> + * ID values to identify security modules. >>>>>> + * A system may use more than one security module. >>>>>> + * >>>>>> + * LSM_ID_XXX values 0 - 31 are reserved for future use >>>>> Reserved for what? Why? >>>> You're not the first person to ask. >>> And the answer is? >> There hasn't been an argument for it beyond "just in case". >> I can't see a rational reason to reserve specific numbers as >> I don't see value in LSM ranges. >> >>>> I'll remove the reserved values for the next version. >>> Because we asked it will be removed? >> Because I don't have a good reason for including it and it >> has been called into question. If a reviewer has a legitimate >> case for reserved values they may be back. > Sorry for the delay, I was away for a couple of weeks and limiting my > patch review to bug fixes, critical stuff, etc. but normal service is > resuming this week ... > > I was the one who originally added the note on reserved values in my > original strawman proposal and I suspect Casey just carried that > forward into his patches, so feel free to blame me. Done! > My reason for > doing so is rather simple, we're going to treat the ID as a 32-bit > value so we have *plenty* of room (just the thought of supporting +4 > billion unique LSMs is comically insane), and I'd like to try and > leave some space for yet-undetermined "special" things that we might > need to convey in the LSM syscalls. For example, this would allow us > to convey additional information to userspace when an application > asked for labeling information using one of these reserved LSM IDs; > applications which did not know (or care) about the special ID would > continue to function normally but augmented/new applications would be > able to make sense of the additional information ... and we wouldn't > have to add a new syscall to do it. I don't see how #define LSM_ID_SPECIAL 2 is better than #define LSM_ID_SPECIAL 13 There's no reason to "group" LSM_ID values, nor have a range of them. Really, I don't care one way or the other. I will bend to whatever will is stronger. > It's basically really cheap futureproofing with little downside (we > can always reclaim it at a later date if really necessary). I've done > similar things on other projects and it has proven to be useful in a > few, and in none of the cases has it proven to be a problem. > > -- > paul-moore.com
