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.
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?)
Best Regards,
Petr
PS: I would like to start working on the support soon. Of course,
it depends how many things come into my way.
Cool, it will be interesting to see how per-feature/per-callback-sets
tackle these problems.
-- Joe
