|
Red Hat Bugzilla – Full Text Bug Listing |
| Summary: | running 'dmidecode' in DomU throws thousands of xen printk's | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Matt C <wago> | ||||
| Component: | xen | Assignee: | Steven Rostedt <srostedt> | ||||
| Status: | CLOSED RAWHIDE | QA Contact: | Brian Brock <bbrock> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 5 | CC: | bjmason, bstein, katzj, riel, wago | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| URL: | https://www.redhat.com/archives/fedora-xen/2006-August/msg00042.html | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2006-10-04 13:01:38 EDT | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | ||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 150224, 185595 | ||||||
| Attachments: |
|
||||||
|
Description
Matt C
2006-08-08 17:52:48 EDT
With kernel 2.6.17-1.2519.el5xen on x86-64 I get only one "(XEN) DOM32:
(file=mm.c, line=578) Non-privileged attempt to map I/O space 000000f0" warning
by the hypervisor.
Stracing dmidecode shows this:
write(1, "# dmidecode 2.7\n", 16# dmidecode 2.7
) = 16
open("/dev/mem", O_RDONLY) = 3
brk(0) = 0x60f000
brk(0x640000) = 0x640000
mmap(NULL, 65536, PROT_READ, MAP_SHARED, 3, 0xf0000) = -1 EFAULT (Bad address)
write(2, "/dev/mem: ", 10/dev/mem: ) = 10
write(2, "mmap: Bad address\n", 18mmap: Bad address
) = 18
brk(0x630000) = 0x630000
exit_group(1) = ?
Process 23451 detached
I'll try to reproduce the problem with the latest FC6 Test2 kernel.
OK, the latest rawhide and rhel5 kernels both show the better behaviour - only one hypervisor message. To get rid of it completely I guess we could disable mmaping /dev/mem in domU. I don't think I was clear enough with my test case, sorry. This happens with older dmidecode-2.2. The newer dmidecode-2.7 that you tested seems to be more intelligent and aborts immediately if the smbios structure isn't present. The older/broken 2.2 version scans through the entire smbios memory range, structure or not. The problem is that the vhosts that I'm supporting are based on RHEL3, which shipped with dmidecode-2.2. I agree that disabling /dev/mem access in domU would be a good consideration. At a minimum, just blocking the smbios region would be acceptable to me. If you want to reproduce, just pull down and run: http://download.savannah.gnu.org/releases/dmidecode/dmidecode-2.2.tar.gz I found that if I run this repeatedly and concurrently on multiple vhosts, my box will eventually lose access to it's local storage as well. I suspect that this is an interaction with the 3w-9xxx driver. Also, I'm testing on 32bit, not sure if that makes any difference here or not. Thanks. Ahhhhhhhh ok. Good point. I'll work on a /dev/mem hack :) Ahhhhhhhh ok. Good point. Hacking /dev/mem is not the right fix though, because in some cases the guest has access to actual IO devices. Instead, we should limit the printing of the message by the hypervisor, which should happen automagically by not having all the debugging options on for the FC6 and RHEL5 final builds. So, I'm not crazy about relying on disabling debug to make this go away. This'll make it impossible for us to enable debug on our xen nodes in the future, since these printks are aggressive enough to bring down our xen parent host when a couple of virtual hosts run dmidecode concurrently. I put together a quick-n-dirty patch that traps the /dev/mem access from unprivileged domains earlier on to avoid the hypervisor failure. However, I'm not sure if it solves the guest direct I/O access problem or not. Patch is will be attached... Created attachment 134173 [details]
Linux kernel patch to catch unprivileged access to /dev/mem early
It really should be fixed on the hypervisor side, otherwise a malicious guest could still bring down the host. Rate-limiting the print on the hypervisor side should probably work just fine. Steven, this is one to verify with your ratelimit patch :) It may already be fixed, but it may also be a different printk you need to add ratelimiting to. Should be fixed in current rawhide via xen printk ratelimiting. The console output from both fc5 and rawhide guest dmidecode is minimised now. |