On 17-04-20 01:58 PM, David Miller wrote:
From: Jamal Hadi Salim <j...@mojatatu.com>
Date: Thu, 20 Apr 2017 13:38:14 -0400
There are no examples of such issues with bitmasks encapsulated in
TLVs
It does not make much sense to have a TLV for each of these
bits when i can fit a bunch of them in u16/32/64.
I have not ruled out bitmasks. I'm only saying that the kernel must
properly reject bits it doesn't recognize when they are set.
It is the other way round from what i see: It ignores them.
This allows new bits to be added over time.
Note: It is a bug - which must be fixed - if user space sets
something the kernel doesnt want it to set. Even then, the only good
use case i can think of for something like this is the kernel
is exposing something to user space for read-only and user space
is being silly and setting read-only bits on requests to the kernel.
But even that is not a catastrophic issue; kernel should just ignore it.
Each bit must have a strict semantic, even unused ones, otherwise
unused ones may never safely be used in the future.
I think we are pretty good at this.
It would be interesting to have a fuzzer which sets random bits on a
TLV bitmask and see what bugs show up.
cheers,
jamal
