On Fri, Nov 13, 2020 at 10:09:04AM +0100, Jiri Benc wrote: > 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. Let me clear here, there's absolutely no intention of keeping things downstream, but there may be changes that won't be accepted upstream because they only make sense for this particular use case. > > 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. We're not "playing a catch up game". Porting the changes to 5.10 [1] took less than one hour, because the changes are small and reasonably isolated (it'll be even more isolated once we reimplement the Transparent Socket Impersonation part as an independent address family). The only reason we don't have a version based on 5.9 is because we didn't had the need for it. We want 5.10 because it incorporates the patch series for DAX support in virtio-fs, and also because it's LTS. > > 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. As I wrote in the original email, in addition of the downstream patches, the kernel is bundled in a different binary format so it can be directly injected into a KVM memory region. > > 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. No. Security issues in the VMM (Virtual Machine Monitor) or other functionality implemented in "libkrun" (which is a separate library and package than "libkrunfw", the one bundling the kernel) may have an impact on the host and must (and will be) promptly fixed. Security issues in the bundled kernel can't have an impact on the host and it's _very_ unlikely the would have it on isolated application, as is operating within the security boundary of the VMM/VM, and the latter under the security context of the original application (in fact, a stricter context with a better seccomp profile). This doesn't mean we can nor will be careless with what's bundled in libkrunfw, but it's definitely a few orders of magnitude less critical from a security perspective than a common, bootable kernel. Thanks, Sergio. [1] https://github.com/containers/libkrunfw/tree/linux-5.10
_______________________________________________ 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
