On Thu, 12 Nov 2020 21:56:55 +0100, Sergio Lopez wrote:
The intention is to keep the gap as small as possible by trying
to upstream all changes. Probably there will be a some of them that
won't make upstream, but those will be super-small changes (such as
not complaining loudly if init gets killed) that only make sense for
this particular use case.
All patches should be upstream. There's no reason for keeping anything
non-upstream in your project.
The patches are based on 5.8, but will be rebased on 5.10 as soon
its
final version is released.
The fact that you're playing a catch up game and don't even have 5.9
does not bring confidence that security problems can be quickly
addressed.
To achieve that, we rely on very aggressive optimizations such as
disabling modularity, enabling options for embedded systems, reducing
the maximum number of cores and memory, disabling most options and
drivers, optimizing for size (-Os)...
What you're describing is just a different kernel config. Such kernel
should be built from Fedora kernel sources using a different kernel
config.
In other words, a CVE in the kernel bundled in libkrunfw won't
have
any impact on the host's security.
Even if this was the case, it would still be a security issue in the
application and as such should be promptly fixed.
Jiri