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