On Fri, 2019-04-26 at 20:28 -0600, David Ahern wrote: > > I agree with this set and will help moving forward. As I recall it > requires follow up patches for each policy to set strict_start_type > opting in to the strict checking. With that in place new userspace on > old kernels will get a failure trying to configure a feature the old > kernel does not recognize.
Actually, that part you had already handled with nla_parse_strict() (now nla_parse_strict_deprecated()) - and I'm not sure we can make this even stricter because existing code might be setting future attributes already, expecting them to be ignored. This is already fishy of applications to expect though, but I'm not sure we really can change that? I don't think I'm actually changing something here, but I'm certainly open to suggestions - after all, when we actually do get around to adding that future attribute it almost certainly will have a different type than a (buggy) application would be using now. However, what I did already do is that adding strict_start_type to policies means that all future attributes added to those policies will be handled in a strict fashion, i.e. if you add strict_start_type and then add a new u32 attribute >= strict_start_type, that new u32 attribute will not be permitted to have a size other than 4 octets. johannes
