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 _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx
