Security considerations with using old kernel
-
I don't understand too well how the Linux kernel interacts with the user space programs that I typically interact with so pardon my ignorance with these questions:
I understand that Android device manufacturers implement their drivers in userspace and do not open source them, so it is very difficult to update a device's kernel from the version it originally shipped with without breaking all of the drivers. What are the security implications of using an old kernel in this way? For example, the Nexus 5 uses kernel 3.4 which was last updated in 2015 (according to https://mirrors.edge.kernel.org/pub/linux/kernel/v3.x/). Have any major vulnerabilities in the kernel been discovered since then that are relevant to Ubuntu Touch and is it feasible to backport fixes for them?
OTA-4 got Ubuntu Touch onto a 16.04 base, so I assume that everything besides the kernel gets supported security patches from Canonical (other than the Ubuntu Touch specific bits). The main Ubuntu 16.04 used kernel 4.4. Are there any problems with using it on an older kernel?
-
@wsha I think that's a very good question for the next Q&A (https://forums.ubports.com/topic/1665/q-a-36-this-saturday-15-09-at-19-00-utc)
-
Not sure about the security implications of using the kernels provided, but a lot of patches can be backported (and are) from newer kernels and compiled in. I can't quite recall what what version was showing as a backport option when I compiled my kernel for the Flo, but I believe it was 4.4.x based. So we are getting SOME improvements from newer kernel patches, even if we are stuck on the device's base kernel.
I think that's why there's been such a huge push to mainline Android into the kernel.
As for if there are any problems using 16.04 on your device's kernel, not likely if your kernel is already 4.x.x+, we Flo users are still stuck on 3.5.0 and can't actually use LXC atm (so Anbox is a no-go unless someone figures out how to backport the features required.) but I haven't found any other kernel related issues running 16.04 on it.
-
@tonoxis how can this be, the Android container in UT is already using lxc, so if UT runs on flo, also lxc must work...
BR
-
@flohack Perhaps I misread the canonical write-up as to why snaps couldn't run then, but I was under the assumption that snaps couldn't work on the Flo because of some LXC features being unavailable. If that's incorrect, that's awesome and makes me wanna try to get Anbox up and running on the Flo!
I was also unable to create a LXC container when I attempted on my Flo last, claimed it was missing some sort of kernel support (I can't remember the exact message, but I'm going to be reinstalling UT here soon, so I can attempt again!) and was the same reason Libertine hardcoded itself to chroot if running on a vivid-based device iirc (unless I misunderstood that requirement, in which case, my apologies for the misinformation then!)
Also, I mis-spoke in my previous reply, Flo is on 3.4.0, not 3.5.0 ^_^; (EDIT: I also want to mention that I had forgotten to state that I was writing using what I had thought was the case from Vivid, I admit I haven't tried LXC on Xenial yet)
Btw, I'm literally ALWAYS happy to learn, so if I'm incorrect about ANYthing, please don't hesitate to correct me and let me know. I realize I'm human and can misunderstand what I read a lot.
EDIT: just finished attempting LXC inside UT, nope. fails initializing CGroup support, and libertine-container-manager claims "System kernel does not support lxc type containers. Please either use chroot or omit the -t option."
