Bug 456175

Summary:	ptrace: PTRACE_SINGLEBLOCK crashes i586 (as not having DEBUGCTLMSR=0x1d9)
Product:	[Fedora] Fedora	Reporter:	Jan Kratochvil <jan.kratochvil>
Component:	kernel	Assignee:	Roland McGrath <roland>
Status:	CLOSED UPSTREAM	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	low
Version:	9	CC:	kernel-maint
Target Milestone:	---
Target Release:	---
Hardware:	i586
OS:	Linux
URL:	http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/tests/ptrace-tests/tests/block-step.c?cvsroot=systemtap
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-07-22 12:19:59 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jan Kratochvil 2008-07-21 22:21:01 UTC

+++ This bug was initially created as a clone of Bug #437028 +++

Description of problem:
If you run unprivileged testcase `block-step' on i586 it will crash the kernel.
It is both upstream+Fedora bug.

Version-Release number of selected component (if applicable):
upstream-2.6.25.4 #2 PREEMPT on K6-3 (test by Mikulas Patocka from RH)
kernel-2.6.25.9-76.fc9.x86_64 (host+guest) on kvm-65-7.fc9.x86_64 on Intel T7200

How reproducible:
Always.

Steps to Reproduce:
1. Boot i586 kernel.
2. Run
http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/tests/ptrace-tests/tests/block-step.c?cvsroot=systemtap
   (best as unprivileged user)

Actual results:
Kernel crash.

Expected results:
No crash, detected missing hardware support for PTRACE_SINGLEBLOCK.

Additional info:
A confirmation the generated exception for the unsupported wrmsr registers is right:
RDMSR
http://www.cs.inf.ethz.ch/stricker/lab/doc/intel-part1.pdf
#GP(0) If the value in ECX specifies a reserved or unimplemented MSR address.

WRMSR
http://www.cs.inf.ethz.ch/stricker/lab/doc/intel-part2.pdf
#GP(0) If the value in ECX specifies a reserved or unimplemented MSR address.

Just the guest kernel should not crash on unsupported MSR register as it may
happen for DEBUGCTLMSR=0x1d9 on real silicon i586.

The problem was verified on i586 K6-3 by Mikulas Patocka from RH on a build of
upstream 2.6.25.4 #2 PREEMPT reportedly scrolling uncaught kernel crashes.
cpuinfo of K6-3 used for this test:
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 5
model           : 13
model name      : AMD-K6(tm)-III Processor
stepping        : 0
cpu MHz         : 451.033
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr cx8 pge mmx syscall 3dnowext 3dnow
k6_mtrr ts fid vid
bogomips        : 902.83
clflush size    : 32

MSR is supported for >= Pentium
DEBUGCTLMSR is supported for >= Pentium Pro

Therefore for Pentium some kernel code needs to detect presence of
DEBUGCTLMSR=0x1d9.

The detection would be best by a real caught segfault than a CPU model check to
support various virtualizations out there:
* qemu-0.9.1-6.fc9.x86_64 qemu-system-x86_64 violates the CPU specification as
  it treats wrmsr to an unknown register as a nop.
* kvm-65-7.fc9.x86_64 does not support DEBUGCTLMSR=0x1d9 while correctly
  generating the exception and thus currently crashes the guest kernel
  (expecting the same way as on real i586) - this dump follows:
kernel-2.6.25.9-76.fc9.x86_64 (host+guest) on kvm-65-7.fc9.x86_64 on Intel T7200
kernel: kvm: 7569: cpu0 unhandled wrmsr: 0x1d9 data 2
kernel: kvm: 7569: cpu0 unhandled wrmsr: 0x1d9 data 0
general protection fault: 0000 [1] SMP 
CPU 0 
Modules linked in: ip6_tables x_tables snd_usb_audio snd_usb_lib snd_rawmidi
snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq
snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc
snd_hwdep snd soundcore nfs lockd nfs_acl sunrpc loop uinput ppdev parport_pc
8139too sg parport floppy pcspkr 8139cp i2c_piix4 i2c_core mii button ata_piix
ahci libata sd_mod scsi_mod sha256_generic cbc aes_x86_64 aes_generic dm_crypt
crypto_blkcipher dm_snapshot dm_zero dm_mirror dm_mod ext3 jbd mbcache uhci_hcd
ohci_hcd ehci_hcd [last unloaded: scsi_wait_scan]
Pid: 3501, comm: block-step Not tainted 2.6.25.9-76.fc9.x86_64 #1
RIP: 0010:[<ffffffff810148b8>]  [<ffffffff810148b8>] enable_step+0x12e/0x1ac
RSP: 0018:ffff81000e9cfc48  EFLAGS: 00000246
RAX: 0000000000000002 RBX: ffff81000e9cfc48 RCX: 00000000000001d9
RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffffffff8136049d
RBP: ffff81000e9cfc78 R08: 0000000000000000 R09: 0000000000000001
R10: 0000000000000000 R11: ffff81000da4d008 R12: ffff81000e9cc000
R13: ffff81000e9cff58 R14: 0000000000000001 R15: ffff810016982d00
FS:  00007f0f486466f0(0000) GS:ffffffff813f2000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000003f2d0dd380 CR3: 000000000de45000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process block-step (pid: 3501, threadinfo ffff81000e9ce000, task ffff81000e9cc000)
Stack:  74c00900000016b8 ff200fc705899009 000000000007e56c ffff81000e9cc000
 ffff810016982d00 0000000000000000 ffff81000e9cfc88 ffffffff81014944
 ffff81000e9cfcd8 ffffffff8106f30a ffff810016982d20 ffff81000e9cfd38
Call Trace:
 [<ffffffff81014944>] user_enable_block_step+0xe/0x10
 [<ffffffff8106f30a>] utrace_quiescent+0x1fc/0x278
 [<ffffffff8106f81b>] utrace_get_signal+0x495/0x4a6
 [<ffffffff81087148>] ? handle_mm_fault+0x33e/0x6fc
 [<ffffffff810404f0>] get_signal_to_deliver+0xa6/0x28e
 [<ffffffff8100b1d2>] do_notify_resume+0xc3/0x8d6
 [<ffffffff81070200>] ? utrace_set_flags+0xe9/0x248
 [<ffffffff8103b124>] ? ptrace_setup_finish+0x15/0x30
 [<ffffffff8103c062>] ? ptrace_start+0xeb/0x406
 [<ffffffff8128f224>] paranoid_userspace1+0x3b/0x3e


Code: 00 00 00 49 89 b4 24 08 07 00 00 65 48 8b 04 25 00 00 00 00 49 39 c4 0f 85
81 00 00 00 48 89 f2 b9 d9 01 00 00 89 f0 48 c1 ea 20 <0f> 30 eb 6f 49 8b 84 24
08 07 00 00 48 89 c6 48 83 e6 fd 48 39 
RIP  [<ffffffff810148b8>] enable_step+0x12e/0x1ac
 RSP <ffff81000e9cfc48>
---[ end trace e4144827225bea2d ]---

Comment 1 Roland McGrath 2008-07-22 01:57:48 UTC

There is no x86-64 hardware without debugctlmsr, so that is just a kvm issue. 
All that crash output is just a red herring wholly unrelated to this bug.
It's rather confusing to have that output from an entirely unrelated kernel in
the same initial report with the cpuinfo from a real i586 case where the real
problem exists.

The existing code (now upstream) checks >= 6 against the same number that's
shown in "cpu family".  So that check would not let the K6 try it, and
PTRACE_SINGLEBLOCK would get EIO.

The model check is compiled away by CONFIG_X86_DEBUGCTLMSR.  For the i586 kernel
where this problem actually happens, check if its .config got this.  If so, the
fix is to consult upstream with what the right set of kconfig dependencies to
use for CONFIG_X86_DEBUGCTLMSR is.

Comment 2 Chuck Ebbert 2008-07-22 02:48:30 UTC

i586 .config does not have CONFIG_X86_DEBUGCTLMSR set, here's why:

config X86_DEBUGCTLMSR
        def_bool y
        depends on !(M586MMX || M586TSC || M586 || M486 || M386)

Comment 3 Jan Kratochvil 2008-07-22 12:19:59 UTC

Kconfig.cpu fix posted upstream:
http://marc.info/?l=linux-kernel&m=121672860614868

Just it does not fix the KVM debugctlmsr Bug 437028 (which was my original
intention).

Comment 4 Mikuláš Patočka 2008-07-24 16:39:23 UTC

I tested the patch and I confirm that it fixes the crash.