Bug 10246
Summary: | "in" after successful ioperm() results in SEGV after kvm use | ||
---|---|---|---|
Product: | Virtualization | Reporter: | Kees Cook (kees) |
Component: | kvm | Assignee: | Avi Kivity (avi) |
Status: | CLOSED CODE_FIX | ||
Severity: | normal | CC: | avi, randy.dunlap |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.25-rc5 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: |
example reproducer
restore tss size after guest exit |
Description
Kees Cook
2008-03-14 18:48:14 UTC
Created attachment 15270 [details]
example reproducer
Reply-To: akpm@linux-foundation.org On Fri, 14 Mar 2008 18:48:15 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=10246 > > Summary: "in" after successful ioperm() results in SEGV after kvm > use > Product: Memory Management > Version: 2.5 > KernelVersion: 2.6.25-rc5 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Other > AssignedTo: akpm@osdl.org > ReportedBy: kees@outflux.net > > > Latest working kernel version: N/A > Earliest failing kernel version: 2.6.24 > Distribution: Ubuntu, but tested with mainline > Hardware Environment: intel mobo, Intel(R) Core(TM)2 Quad CPU Q6600@2.40GHz > Software Environment: kvm 62 (x86_64) > Problem Description: > > After a successful ioperm() call, otherwise valid "in" instructions will segv > if a kvm VM has started. > > Steps to reproduce: > > 1) run attached reproducer prior to starting a kvm VM, results are: > # ./ioperm > getting 0x3b4-0x3df permission... > fetching 0x3cc... > ok: 1 > > 2) start a kvm VM (bug exists only after actually starting a guest VM) > > 3) run reproducer, which now fails: > # ./ioperm > getting 0x3b4-0x3df permission... > fetching 0x3cc... > Segmentation fault (core dumped) > > Note that it does not always fail. Running within gdb seems to reduce the > chances that it will fail. But when it does, it is clearly the "in" that is > failing: > > Program received signal SIGSEGV, Segmentation fault. > 0x00000000004006e4 in inb () > (gdb) x/1i $pc > 0x4006e4 <inb+12>: in (%dx),%al > (gdb) info reg rdx > rdx 0x3cc 972 > > I have had the sense that running the CPUs at full load (niced) increases the > chance for failure. > There is a testcase in the bugzilla report. Does the attached patch fix? Created attachment 15283 [details]
restore tss size after guest exit
proposed fix
Yes, this appears to solve the behavior I was seeing. Thanks very much! Fixed by 5dc832628229d2736fab10523566855c3cda622d in 2.6.25-rc7. |