FS#40627 - [linux-grsec] virtio_net driver causes qemu/kvm crash
Attached to Project:
Community Packages
Opened by Jed Liu (jed) - Saturday, 31 May 2014, 20:21 GMT
Last edited by Daniel Micay (thestinger) - Sunday, 22 June 2014, 07:31 GMT
Opened by Jed Liu (jed) - Saturday, 31 May 2014, 20:21 GMT
Last edited by Daniel Micay (thestinger) - Sunday, 22 June 2014, 07:31 GMT
|
Details
Description:
When using linux-grsec in a qemu/kvm guest with virtio networking, the virtio_net driver causes qemu to exit with the message: qemu-system-x86_64: virtio: trying to map MMIO memory This happens when using linux-grsec-3.14.4.201405281922-1 in the guest. Things work fine if the guest runs linux-grsec-3.14.4.201405141623-1. The problem occurs regardless of which of the two linux-grsec kernels is used on the host. Additional info: * qemu-2.0.0-3 Steps to reproduce: * Have linux-grsec running on the host with RBAC enforcement turned off. * Set up a qemu/kvm guest with linux-grsec-3.14.4.201405141623-1 and 'MODULES="virtio_net"' in mkinitcpio.conf. * Attempt to start the guest, passing qemu the "-net nic,model=virtio" option. Observe that the kernel starts up. * Update the guest kernel to linux-grsec-3.14.4.201405281922-1 and reboot. Observe that qemu quits early in the boot sequence with "qemu-system-x86_64: virtio: trying to map MMIO memory". * Attempt to start the guest with the new kernel, this time omitting "model=virtio" to disable virtio networking. Observe that the kernel starts up. |
This task depends upon
Closed by Daniel Micay (thestinger)
Sunday, 22 June 2014, 07:31 GMT
Reason for closing: Fixed
Additional comments about closing: linux-grsec-3.14.8.201406220132-1
Sunday, 22 June 2014, 07:31 GMT
Reason for closing: Fixed
Additional comments about closing: linux-grsec-3.14.8.201406220132-1
http://seblu.net/a/arm/packages/l/linux-grsec/
After you've narrowed the upgrade introducing this problem, figuring out which grsecurity option is behind the problem can be tackled. I think there's a good chance it's the kernel stack overflow protection introduced in 3.14.4.201405271114, in which case there's a bug to report to spender (the grsecurity developer).
There's no indication that it's the same issue yet. You can follow my comments here and determine if this issue is caused by CONFIG_GRKERNSEC_KSTACKOVERFLOW. If it's not fixed by going back to the version before 3.14.4.201405271114, then it's not the same issue and belongs in a separate report.
> Is linux-grsec supposed to be safe for production or is this an incorrect assumption on my part?
It's not uncommon for vanilla kernel upgrades to bring along problems just like this. The grsecurity patched kernel will bring along additional issues in uncommon environments (virtualization, third party modules) since the exploit mitigations can have compatibility issues with other kernel components.
> I can't do much testing with this vps but if it would help, i would be happy to set up a small vps for you or upstream to test with (at least for a month or two).
In order for this to be fixed upstream, the issue needs to be narrowed down and then instructions on how to replicate the issue *may* be required. The initial debugging work (narrowing down the problematic grsecurity feature) doesn't require any expertise.
@andriesinfoserv: If you still run into the problem with the new version, please open another issue.