Update to 4.13.4 #13
Update to 4.13.4 #13
Conversation
- Resolved a few trivial patch conflicts. - yes '' | make oldconfig
|
@HW42: You're talking about the new KSPP recommended options that have appeared since 4.9 plus CONFIG_FORTIFY_SOURCE? I agree. I actually have them set in my 4.13 config, but I haven't had much time to play around with 4.13 to see how well it works (I still need to recompile it to remove CONFIG_INTEL_ATOMISP). I think the GCC plugin options appeared in 4.11 or 4.12 though, and on my personal machine, I've enabled them and haven't really encountered any issues. Fedora 23 has GCC 5.3 and Debian 8 has GCC 4.9 so if what comes with a default Qubes R3.2 system is the baseline, then enabling the RANDSTRUCT plugin option should be fine. Another one to consider enabling might be CONFIG_BUG_ON_DATA_CORRUPTION ("Select this option if the kernel should BUG when it encounters data corruption in kernel memory structures when they get checked for validity."). I've had it turned on in 4.11 and 4.12 and I haven't encountered any issues. As for hardware support, any new PCI/USB network drivers that have appeared since 4.9 and make sense on a desktop or notebook should probably be compiled as modules. The same for any accelerometer, magnetometer, orientation and other sensors that might appear in a notebook computer (some machines rely on them for suspend detection or screen rotation). Any new USB HID driver support that appears should be considered as well, especially when it comes to touchscreens, keyboards or mice. Maybe any new USB camera support as well. I've also been wondering for a while now if other Kernel Security Module support like TOMOYO or SMACK should be compiled as modules as well for anyone that might want to use them, although I personally don't have experience using those two. Currently, it's AppArmor, SELinux and Yama, and those seem to be working fine for those that use them. Anyways, those are my comments. I may have more once I've used 4.13 for a longer period of time. But it'd be good to really test 4.13 well so that hopefully the 4.14 LTS kernel testing will be a little bit easier when that gets released. |
Should not harm, but in practice most of them are unused anyway. |
Ok. Then the simple name change as done here should be enough. |
Yes. I just quickly looked at the config diff which options might be interessting. It's also quite possible that I have missed some stuff.
The package is build in Fedora 25 which currently uses gcc 4.6.1. Also with RANDSTRUCT you need to check if the package is properly generated such that one can build out of tree modules. (And of course RANDSTRUCT is quite limited for a binary distribution).
If I understand you correctly you already have played with 4.13 and the previouse versions. So do you have a updated config? If yes please open a PR once Marek has created the new branch.
I would keep it as is unless somebody actively request support for those. |
|
On my side, kernel 4.12.14 is stable thanks to disabling CONFIG_INTEL_ATOMISP (see my post https://groups.google.com/d/msg/qubes-users/yBeUJPwKwHM/1-_pseZPBgAJ) but kernel 4.13.4 seems to make Ryzen platform crashing (it is my case and also another user). |
|
4.12 is already EOL... |
|
Ooh, I have not paid attention that it was already EOL... I will test the last rc of 4.14 to see if the problem on 4.13 still happen. |
Wait, so is the build environment different than the one that ships for the various Fedoras used in dom0? I just assumed that the build system used the same gcc versions as those used in the various Release targets when they compiled the release-specific packages. I wonder if mismatched gcc versions causes issues when new kernel modules are compiled by users after installation.
I do. @fepitre's devel-4.13 branch is probably closest to what I have locally since it inherits all the changes from 4.9-4.12, but I haven't diff'ed his version and mine to see if we made different choices when migrating from 4.12 to 4.13. But part of me really wants to rebase off of Fedora's 4.13 config once it's finished its testing phase and is officially released instead, then add in the KSPP settings and other hardening features on top of that. Some users have raised issues with the 4.9 kernel that work perfectly under 4.4 and as all things seem to look fine on the surface comparing the two, the troubleshooting has become difficult. So maybe some obscure setting was missed during the 4.4 to 4.9 migration, and if the hardware works under a stock Fedora kernel, then maybe a 4.13 kernel config rebase might be worthwhile trying to see if that fixes things. If not, it might be a side effect of the extra hardening.
Works for me. |
If you haven't tried it yet, you may need to alter the build script to work with the RC nomenclature. The build scripts expect the kernel uname to be of the form X.Y.Z and if it isn't in that format, it fails (so for example, kernel 4.13 would have failed in its build but 4.13.1 would have worked fine; I suspect 4.14-rc3 will fail by default). |
No, kernel packages for dom0 are build in the same env as other packages for dom0. This also cause some issues (QubesOS/qubes-issues#2844)... |
It is there:
What do you think about doing the same with 4.9? It is LTS, so it's going to be around for a while. It looks like the latest Fedora's 4.9 is 4.9.17 for fc24. |
|
Yeah, I think I might do that. I'll try to get that done by this weekend so that it can be tested in time for R4.0 rc2. It's around time for a new update roll up anyway. |
Use v4.12.14-21 as a base.
|
I'm almost done (at least with the 4.9 branch; haven't had a chance yet to look at 4.13), but I had a question about the Qubes policy when it comes to the Fedora kernel patches that are included in the src rpm. There are a lot here, and while I haven't delved too deeply to see what they do, just running 'make prep' to see what patched in and what didn't, here are the ones that patched in cleanly against 4.9.54:
these are the ones that may need a little work to be migrated to the latest 4.9 version:
these are the ones that have already been merged upstream:
and these are the ones that don't patch in but are probably not applicable (different architecture):
Should these be included in the Qubes kernel? How has this been dealt with in the past? And if they were to be merged in, how would it run on different distro templates like Debian or Archlinux? Would there be any issues? |
|
Generally the policy is to have mostly vanilla kernel. Exceptions include things specific to Qubes OS (but it applies mostly/only to dom0), or critical fixes (like security patches, until included in upstream version). In other cases, patches should go through upstream. |
|
I've created branch |
|
Don't forget to not setting CONFIG_INTEL_ATOMISP (see in my devel-4.12 for detail) |
|
@rtiangha I have some questions about config options in your
This is the first pass of validation after rebasing on Fedora config. Probably require additional one. |
|
@marmarek Actually, the 4.12 branch on my account hasn't been rebased on Fedora's 4.9; I haven't even touched it. It was based of off @fepitre's work and I just copied his branch in its entirety and bumped it up to 4.12.14. I hadn't had a chance to rebase it, either using a migrated 4.9 config or Fedora's 4.12 (or even take out CONFIG_INTEL_ATOMISP). My intent was to migrate that to a 4.13 branch, but I got stuck on the vm kernel panic issue due to INTEL_ATOMISP and wasn't able to solve it fast enough before I had to go and work on other things. I did do a pass on my 4.9 branch using Fedora's version, but my rational was to not disable anything except for what KSPP recommended to disable, and maybe one or two other obvious things. After that, it was add in hardware support, but I didn't look too closely at each driver. But I appreciate the validation pass regardless of the lineage; it is good to debate the merits of each option. As for the hypervisor stuff like VMware and KVM, in my original 4.4 migrated config, I had disabled them. When using Fedora's 4.9 config (it and the modifications I made are currently on my stable-4.9 branch so that's the one I'll be talking about), I left them as is, even though I personally disable all hypervisor support except for Xen on the machines I run, mainly because this page states that nested hypervisors may actually work depending on the version of Xen you're running (4.8+ obviously having better support for Windows/VMware than 4.6). I don't feel strongly either way including other hypervisor support in this kernel, though. Everything else (including the Freescale support) was a Fedora 4.9 default. I hadn't had a chance to look at all of them in depth, but I agree 100% with your comments. I guess this new config will need another pass or two to ensure what needs to be enabled is actually enabled, and what doesn't need to be there isn't (like anything that applies to ARM-only stuff, for example). |
|
Ugh. For example, explicitly disabling by default various KSMs like Selinux and Apparmor. I just made a new 4.9 commit for that, but yeah, looks like some more customization may be needed. |
|
Edit: Actually, I may have read those tables wrong and misinterpreted nested hypervisor support. It looks like it's getting worse the higher the Xen version is. If that's truly the case, then there really is no reason to include support for other hypervisors in the kernel. But they still sort of work with Xen 4.6 though. Again, I don't feel strongly either way. |
|
FWIW, we don't provide easy way to enable nested virtualization, on purpose. |
|
This is offtopic here, but I'm going to upload 4.9.54 to current-testing (with #12 merged), but without this config rebase, yet. |
The config is now generated based on Fedora's config. This way we need to only track qubes specific changes and can quickly update to never Fedora configs.
|
VM crash on boot with this 4.14.6 kernel: https://gist.github.com/marmarek/ad6ace847c3ac073fe12d6327e57e713 |
By writing '-latest' or '' in the 'suffix' file we can now easily switch between the two variants.
The minimal config is not used by the package itself, but is useful when testing different kernel versions (git bisect, etc.), so store it here.
|
The crash should be fixed now. Currently the |
|
Another option, when kernel-latest will be the latest kernel, we could make obsolete and require remove the related kernel-latest version to have proper install directories. No? |
Not sure I understand what you wrote. I think the easiest solution is to add (to And the equivalent for the My question was more targeted at if we prefer this, or using separate paths? |
|
I think conflict is ok. In practice this will happen only when new LTS kernel will be released. And we can delay either package then. |
|
@HW42: yes this is why I meant. Sorry for my bad sentence. |
|
@marmarek: indeed, but just to be sure to not have duplicates files. |
|
I've reviewed new config one more time. Things to consider:
|
This should allow to assign usb device to pciback in initramfs before thos modules get loaded.
Changed.
Hope the added options are enough for the test. Those two config changes are NOT tested yet (build running ...). |
And? |
This is also needed by the qvm-usb tests.
|
Works fine. With the new commit the test can create the dummy device. But the test file is broken in R3.2 (installed for python3.4 instead of 2.7) and the driver has slightly changed so the usbproxy code needs an update (changed paths, status format (and it seems to support USB 3.0 now)). |
|
Part of QubesOS/qubes-issues#3460 |
This should not be merge but get it's own branch. Creating PR for tracking and discussion.
@marmarek: Should kernel-latest provide kernel-xen-dom0, etc.?
@rtiangha: If you have some time it would be nice if you could have a look at the new config options that have been added since 4.9. Currently it's just a simple
yes '' | make oldconfig. For example we might want to consider to set:CONFIG_SLAB_MERGE_DEFAULT=nCONFIG_GCC_PLUGIN_STRUCTLEAK=yCONFIG_GCC_PLUGIN_RANDSTRUCT=y(but requires gcc 4.7)CONFIG_FORTIFY_SOURCE=y