GPF while testing fwts msr

[Colin Ian King]

I believe the GPF is expected if we try and access a MSR that doesn't 
exist, so this is normal behaviour here, especially inside kvm where we 
don't have support for this MSR.

I suspect this is returning something like -EINVAL to the pread() being 
used on the MSR, and this ripples back up as a FWTS_ERROR and the test 
failing to run.  It doesn't break/abort fwts does it?

Colin


On 30/01/12 06:41, Alex Hung wrote:
> On 01/29/2012 05:59 AM, Chris Van Hoof wrote:
>> Hey guys,
>> While testing the latest fwts-live image[0] (3.2.0-11.19) in a kvm
>> instance I noticed that when the msr test is executed I'm seeing a GPF:
>>
>> [ 19.495910] general protection fault: 0000 [#1] SMP
>> [ 19.496033] CPU 0
>> [ 19.496068] Modules linked in: msr ppdev parport_pc parport mac_hid
>> psmouse serio_raw i2c_piix4 squashfs overlayfs nls_iso8859_1 nls_cp437
>> vfat fat floppy 8139too 8139cp zram(C)
>> [ 19.496461]
>> [ 19.496490] Pid: 2052, comm: fwts Tainted: G C
>> 3.2.0-11-generic #19-Ubuntu Bochs Bochs
>> [ 19.496640] RIP: 0010:[<ffffffff8103bf5d>] [<ffffffff8103bf5d>]
>> native_read_msr_safe+0xd/0x30
>> [ 19.496990] RSP: 0018:ffff88001ba73db0 EFLAGS: 00000086
>> [ 19.497170] RAX: 0000000012a40000 RBX: ffff88001ba73e58 RCX:
>> 0000000000000480
>> [ 19.497376] RDX: 00000000ffff8800 RSI: ffff88001ba73dcc RDI:
>> 0000000000000480
>> [ 19.497576] RBP: ffff88001ba73db0 R08: 0000000000000000 R09:
>> 0000000000000000
>> [ 19.497576] R10: 0000000000000480 R11: 0000000000000246 R12:
>> ffffffff81326400
>> [ 19.497576] R13: 0000000000000000 R14: ffffffff81cdc000 R15:
>> 0000000000000008
>> [ 19.497576] FS: 00007f43dabb6720(0000) GS:ffff88001f400000(0000)
>> knlGS:0000000000000000
>> [ 19.497576] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> [ 19.497576] CR2: 00007f43dabbc000 CR3: 000000001bc9a000 CR4:
>> 00000000000006f0
>> [ 19.497576] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
>> 0000000000000000
>> [ 19.497576] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
>> 0000000000000400
>> [ 19.497576] Process fwts (pid: 2052, threadinfo ffff88001ba72000,
>> task ffff88001da00000)
>> [ 19.497576] Stack:
>> [ 19.497576] ffff88001ba73dd8 ffffffff8132641c ffffffff81187063
>> ffff88001b9da600
>> [ 19.497576] 0000000000000246 ffff88001ba73e48 ffffffff810a0ec7
>> 0000000000000000
>> [ 19.497576] 0000000000000000 ffff88001d87d950 0000000000000000
>> 0000000000000000
>> [ 19.497576] Call Trace:
>> [ 19.497576] [<ffffffff8132641c>] __rdmsr_safe_on_cpu+0x1c/0x40
>> [ 19.497576] [<ffffffff81187063>] ? user_path_at_empty+0x63/0xa0
>> [ 19.497576] [<ffffffff810a0ec7>] smp_call_function_single+0x147/0x160
>> [ 19.497576] [<ffffffff813265ce>] rdmsr_safe_on_cpu+0x4e/0x70
>> [ 19.497576] [<ffffffffa00900d8>] msr_read+0x98/0xd0 [msr]
>> [ 19.497576] [<ffffffff8129b723>] ? security_file_permission+0x93/0xb0
>> [ 19.497576] [<ffffffff81177650>] vfs_read+0xb0/0x180
>> [ 19.497576] [<ffffffff811778e2>] sys_pread64+0xa2/0xb0
>> [ 19.497576] [<ffffffff8165e2c2>] system_call_fastpath+0x16/0x1b
>> [ 19.497576] Code: 89 e5 66 66 66 66 90 0f 01 f9 48 89 c6 48 89 d0 89
>> 0f 48 c1 e0 20 48 09 f0 5d c3 0f 1f 00 55 48 89 e5 66 66 66 66 90 89 f9
>> 0f 32<45> 31 c0 89 c7 48 89 d0 44 89 06 48 c1 e0 20 89 f9 48 09 c8 5d
>> [ 19.497576] RIP [<ffffffff8103bf5d>] native_read_msr_safe+0xd/0x30
>> [ 19.497576] RSP<ffff88001ba73db0>
>> [ 19.497576] ---[ end trace abd45dfe942fc0ed ]---
>>
>> ... this was of course while running with the fwts-live frontend, but
>> can also be easily reproduced with `sudo fwts msr`.
>>
>> On the host machine (Precise based) I noticed this is generated when I
>> hit the GPF:
>>
>> [592075.713605] kvm: 25101: cpu0 unhandled rdmsr: 0x1fa
>> [592075.714107] kvm: 25101: cpu0 unhandled rdmsr: 0x3f1
>> [592080.880260] kvm_get_msr_common: 10 callbacks suppressed
>>
>> I then tried to reproduce this on real hardware and cannot reproduce the
>> failure which got me looking at:
>>
>> https://lkml.org/lkml/2012/1/6/173
>>
>> ... although I'm not sure if it's relevant here.
>>
>> Also to note, I'm running fwts version 0.24.16.
>>
>> Cheers,
>> Chris
>>
>> [0] --
>> http://hwe.ubuntu.com/fwts-live/images/fwts-live-oneiric-amd64-usb-hdd-20120127-0.img.bz2
>>
>>
>>
>>
>>
>>
>>
> Not all MSR registers are supported in all CPUs and some read/write of
> MSR may depend on others. Read/Write to unsupported MSR will generate GPF.
>
> 1FAH (IA32_DCA_0_CAP) DCA type 0 Status and Control register
> 3F1H (MSR_PEBS_ENABLE PEBS) Control (R/W)
>
> It could be KVM does not support the MSR registers. Many CPUs support
> these MSR and the error will not be duplicated with real hardware.
>
> Cheers,
> Alex Hung
>