linux-kernel - Re: [PATCH] KVM: Handle MSR_IA32_PERF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20160531130510.GA30721@potion>
Date:	Tue, 31 May 2016 15:05:10 +0200
From:	Radim Krčmář <rkrcmar@...hat.com>
To:	Paolo Bonzini <pbonzini@...hat.com>
Cc:	kmeaw@...dex-team.ru, "Gabriel L. Somlo" <gsomlo@...il.com>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org, gleb@...nel.org
Subject: Re: [PATCH] KVM: Handle MSR_IA32_PERF_CTL

2016-05-31 03:53-0400, Paolo Bonzini:
> > 2016-05-27 17:22+0200, Radim Krčmář:
> > > (I wonder why MacOS X doesn't read IA32_PERF_STATUS, though.)
> > 
> > Oh, it maybe does ... we already emulate status and return 0x1000 in its
> > bottom 16 bits.  I have no idea what is that supposed to mean, but I
> > think we should return 0x1000 in IA32_PERF_CTL then.
> 
> It's 1000, not 0x1000 (instead, on real hardware the value is typically a
> multiple of 256).  It was added for Darwin too.

Ah, thanks.  (Drivers say that bottom 8 bits are not used.)

> Returning different values is okay, because they are different on real
> hardware too:
> 
> (sudo dd if=/dev/cpu/0/msr skip=$((0x198)) iflag=skip_bytes bs=8 count=1;
>  sudo dd if=/dev/cpu/0/msr skip=$((0x199)) iflag=skip_bytes bs=8 count=1) | od -tx8
> 0000000 00001f3900001100 0000000000001300
>         ^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^
>         PERF_STATUS      PERF_CTL
> 
> And perhaps if we returned non-zero values for PERF_CTL Darwin would try to
> write to it.  So returning zero is fine, I think.  There is no correct answer...

Yeah, 0 seems fine.  PERF_CTL the target value for PERF_STATUS, but OS
shouldn't put much trust in those values ... especially under KVM, where
those MSRs make little sense.