Community Packages

Please read this before reporting a bug:
http://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

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
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Daniel Micay (thestinger)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

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
Comment by Daniel Micay (thestinger) - Sunday, 01 June 2014, 06:13 GMT
Before investigating further, it would be quite helpful to narrow this down to a more specific package upgrade.

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).
Comment by Daniel Micay (thestinger) - Tuesday, 03 June 2014, 08:24 GMT
There's a new release (3.14.5.201406021708) and it's possible (but unlikely) that this was fixed.
Comment by Jed Liu (jed) - Tuesday, 03 June 2014, 12:57 GMT
Thanks for your responses, Daniel. You are correct. The issue was introduced in 3.14.4.201405271114 and remains unfixed in 3.14.5.201406021708.
Comment by Daniel Micay (thestinger) - Saturday, 07 June 2014, 15:39 GMT
Can you try compiling the latest linux-grsec package with ABS using CONFIG_GRKERNSEC_KSTACKOVERFLOW=n in the config/config.x86_64 file?
Comment by ITwrx (andriesinfoserv) - Tuesday, 10 June 2014, 13:00 GMT
i don't know for sure that the bug is exactly the same but i tried switching to linux-grsec (linux-grsec 3.14.5.201406051310-1) on my kvm vps and it couldn't finish booting. Don't know what the host is running. It seems to fail after mentioning iptables(pls see attached). Is upstream grsec not tested with kvm? Is linux-grsec supposed to be safe for production or is this an incorrect assumption on my part? 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). thanks in advance.
Comment by Daniel Micay (thestinger) - Tuesday, 10 June 2014, 14:21 GMT
> i don't know for sure that the bug is exactly the same but i tried switching to linux-grsec (linux-grsec 3.14.5.201406051310-1) on my kvm vps and it couldn't finish booting. Don't know what the host is running.

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.
Comment by Daniel Micay (thestinger) - Tuesday, 10 June 2014, 22:35 GMT
This may be fixed by 3.14.6.201406101411-1.
Comment by ITwrx (andriesinfoserv) - Wednesday, 11 June 2014, 00:16 GMT
thanks for all the info. i don't know about the OP but just fyi, 3.14.6.201406101411-1 didn't fix my problem.
Comment by Jed Liu (jed) - Saturday, 14 June 2014, 05:02 GMT
Not fixed by 3.14.6.201406101411-1. When I get a chance to compile the kernel, I will try disabling KSTACKOVERFLOW and will report back.
Comment by Jed Liu (jed) - Wednesday, 18 June 2014, 12:52 GMT
Setting CONFIG_GRKERNSEC_KSTACKOVERFLOW=n in 3.14.5.201406051310-1 seems to have fixed the problem.
Comment by Jed Liu (jed) - Wednesday, 18 June 2014, 13:19 GMT
It looks like this has been reported upstream already: https://forums.grsecurity.net/viewtopic.php?f=3&t=3977
Comment by Daniel Micay (thestinger) - Sunday, 22 June 2014, 05:56 GMT
I'll be pushing 3.14.5.201406220132 to [community] soon and it has a fix for this issue.

@andriesinfoserv: If you still run into the problem with the new version, please open another issue.

Loading...