ksrc: Improve method of detecting patched kernels

[fgyanz]

Currently patched kernels are found by checking which kernel tags contain the patch's commit, previously obtained from the respective SLE main branch.

The new approach directly checks each kernel's tag for the patch itself. By doing so, it covers edge cases in which each kernel contains a different commit. The old method will still be used, but as a fallback.

For more information, see https://github.com/SUSE/klp-build/issues/19

For instance, CVE-2023-52846:

Old way (incorrectly labels 15.6rtu0 as vulnerable):

Searching for already patched codestreams...
Skipping already patched codestreams:
    15.4u28-29 15.5rtu18 15.5u17 15.6rtu1-2 15.6u2-3
Skipping unaffected codestreams (missing backports):
    12.5u47-59 15.2u39-51 15.3u35-47
All affected codestreams:
    15.4u16-27 15.5rtu3-16 15.5u3-15 15.6rtu0 15.6u0-1
Checking filter and skips...
Checking files, symbols, modules...
Done. Setup finished.

New way:

Searching for already patched codestreams...

15.4u28 (5.14.21-150400.24.125):
74c7662a961ccba6dac0505059ed7f0dc25e453a

15.4u29 (5.14.21-150400.24.128):
74c7662a961ccba6dac0505059ed7f0dc25e453a

15.5u17 (5.14.21-150500.55.73):
74c7662a961ccba6dac0505059ed7f0dc25e453a

15.5rtu18 (5.14.21-150500.13.64):
74c7662a961ccba6dac0505059ed7f0dc25e453a

15.6u2 (6.4.0-150600.23.14):
cf63988c516f2ec586a9997415dd21876467150b

15.6u3 (6.4.0-150600.23.17):
cf63988c516f2ec586a9997415dd21876467150b

15.6rtu0 (6.4.0-150600.8):
4f322b5c2575152ba2fba232c363ba8d1fee55f7

15.6rtu1 (6.4.0-150600.10.5):
cf63988c516f2ec586a9997415dd21876467150b

15.6rtu2 (6.4.0-150600.10.8):
4f322b5c2575152ba2fba232c363ba8d1fee55f7
cf63988c516f2ec586a9997415dd21876467150b

Skipping already patched codestreams:
    15.4u28-29 15.5rtu18 15.5u17 15.6rtu0-2 15.6u2-3
Skipping unaffected codestreams (missing backports):
    12.5u47-59 15.2u39-51 15.3u35-47
All affected codestreams:
    15.4u16-27 15.5rtu3-16 15.5u3-15 15.6u0-1

[marcosps]

(just to document here our private chat)

I believe that we can add your new way to detect patched kernel, and have the older method as a fallback, since we can have the fix backported proactively, and thus doesn't contain the CVE number.

[fgyanz]

Thanks, and done. As proposed, I added the old technique as a fallback in case no commits are found with the new method. I also reworked the code, having each technique as separate function.

[marcosps]

Hey @fgyanz ! Thanks for the update! I'm checking your new update to the PR, and now we check both the tag and the commit hash. What I had in mind was to first check the commit tag using git grep, and ir we can't find it then to fallback to the old method. I believe that this would make the process faster, since a codestream that matches the check for git log --grep --tags don't need the git tag --contains , and vice versa. If if find in one place, we don't need to check the other.

What do you think about it?

[marcosps]

The good news is that with this version it matches the number of affected/patched cases from bsc#1226325 that I tested before, thanks!!!

[marcosps]

Well, let's merge it. We can always come back and rework if the delays in searching vulnerable codestreams is taking too much time. Thanks a lot for implementing this functionality!