[lkml]   [2004]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: secure computing for 2.6.7
In article <20040801102231.GB6295@dualathlon.random> you wrote:
> /proc/sys/kernel/security_sequence [1] or anything like that that we
> could increase every time we fix a kernel bug (note, it's not mandatory
> to increase it every time, and we could increase it even weeks after the
> bug has been fixed after somebody ask for it, and it would still work
> fine)

Hmm.. yes, kind of patchlevel/build number.

I feel that you miss a solution for different branches, backporting and
partial fixes. Since that way it can only work for the official branches of
the kernel, it would be enough to check the minor number.

Personally I think it is better to keep that in the utsname.release. If you
realy want to have an integer, then add it for easy parsing and allow it to
have multiple parallel issuers:

For example like:


where this has applied fix 3501 in the 2.6 branch and 123 according to
vendor MM, so you do not need to understand vendors XXX schema. However I am
not sure if you are willing to accept the fact, that backporters will then
raise the level to a value you will only expect for more recent versions,

-> security bug1 is discoverd and fixed
-> security bug2 is discoverd and fixed
-> features are added

Now somebody decides to backport the bug1 fix:


and the bug2 fix:

2.6.9-3(linux26.3503) <- is level 3503 but does not have all 2.6.10 features?!

And it gets even more hairy: if only the bug2 fix is
backported, how can an application state that it needs that (without
impliciteley also reling on bug1 to be fixed)

eckes privat -
Project Freefire -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:04    [W:0.166 / U:6.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site