On 2/13/19 5:12 AM, Petr Mladek wrote:
On Tue 2019-02-12 09:52:04, Joe Lawrence wrote:
On 2/12/19 5:15 AM, Petr Mladek wrote:
On Mon 2019-02-11 11:05:16, Joe Lawrence wrote:
Add a simple livepatch versioning policy to the livepatch core. For
those klp_patches with non-zero version, only load those with higher
versions than the livepatch core's latest-version. Livepatches may opt
out of the policy altogether (i.e. patches always load and do not update
latest-version) by specifying klp_patch.version=0.
Hi Petr,
Thanks for having a look...
I think that a more practical would be a per-feature/per-callback-set
versions.
We currently support many code streams. By definition, there are more
released livepatches for older kernels that for recent ones. It might
be error prone to decide about a particular feature by a global
version that would be different in different code streams.
The RFC livepatch versioning should only pertain to the same kernel version,
and is more accurate to think of it as only "version N+1 must be safe to
load if version N is loaded". Making a strong association with a particular
feature may lead to errors as you pointed out.
I remember that we also want to support downgrade. It is safe as long
as the cumulative patches are compatible.
It is doable event with the global version. We could bump it only
with incompatible changes. But then it won't be a real version.
In each case, I do not want to block the global version. It is
better than nothing. But I want to point out that we might want
to replace it with something more safe-to-use in the future.
Gotcha. I'm not in any rush to push this further than RFC at the moment.
I had some time last week to put it together as a thought experiment
to see which cases it would cover.
If we wanted to reuse versioning data across kernel versions, I would
suggest using 'feature' enumerations. So a vendor could define
KLP_FEATURE_L1TF and then reuse that in a common header file for all
livepatches for all kernels. (Jumping ahead, I'm guessing the idea would be
that patches would supply a list of features and then subsequent ones must
include features of previous ones?)
My idea is to create something similar to the shadow variables API.
Something like:
Let me comment on klp_features in another reply with an amended subject
line...
-- Joe
