Re: lscpu VMWARE bdoor patch

[Mike Frysinger <vapier@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3622 bytes --]

On 03 Nov 2016 10:41, Karel Zak wrote:
> On Thu, Nov 03, 2016 at 09:04:42AM +0200, Ruediger Meier wrote:
> > On Wednesday 02 November 2016, Karel Zak wrote:
> > > On Fri, Oct 28, 2016 at 12:06:36AM +0200, Ruediger Meier wrote:
> > > > On Thursday 27 October 2016, Karel Zak wrote:
> > > > > this is lscpu output on my machine:
> > > > >
> > > > >     Virtualization:        VT-x
> > > > >     Hypervisor vendor:     VMware
> > > > >     Virtualization type:   full
> > > > >
> > > > >
> > > > > I have nothing like VMWARE. It seem the code (commit b7744730)
> > > > > does not work as expected for non-root users. What about to add
> > > >
> > > > Have you checked whether the original code in b7744730 is alreaday
> > > > broken? Not something about the later PIC/PIE patches?
> > >
> > > It's Mike's PIC/PIE patch :-(
> > >
> > > Maybe we can ifdef more precise and add getuid() check, if I good
> > > understand Mike's commit message then the problem is 32bit system.
> > 
> > BTW vmware runs on 64bit only since a few years. Maybe just disable 
> > bdoor for 32bit if it helps to make it simple.
> 
> but you can use 32bit system (guest) inside vmware. 
> 
> I'll will add getuid() for now. Maybe someone (Mike?:-) will help us
> with a better solution later.

i don't think getuid helps.  seems like if you run it on a system even as
root it'll still fail randomly.

my guess is that when the inl is run, it triggers the segfault (since it
isn't run under vmware) which happens after the ebx/esi exchange.  but the
ebx/esi aren't swapped back, and for some reason the siglongjmp doesn't
make things right (but that doesn't make sense to me either).

if you revert my patch, then you can't build lscpu as PIE on x86, which
means you're worse off than you are now :).

when i trace it in gdb by putting a break on vmware_bdoor, i see:
(gdb) info r
eax            0xa      0xa
ecx            0x5658   0x5658
edx            0x0      0x0
ebx            0x564d5868       0x564d5868
esp            0xffffb540       0xffffb540
ebp            0xffffb548       0xffffb548
esi            0x564d5868       0x564d5868
edi            0xffffd81c       0xffffd81c
eip            0x5655873a       0x5655873a <vmware_bdoor+37>
(gdb) dis
Dump of assembler code from 0x5655873a to 0x5655877a:
=> 0x5655873a <vmware_bdoor+37>:        xchg   %ebx,%esi
   0x5655873c <vmware_bdoor+39>:        in     (%dx),%eax
   0x5655873d <vmware_bdoor+40>:        xchg   %esi,%ebx
(gdb) stepi
0x5655873c      827             __asm__(
(gdb) stepi

Program received signal SIGSEGV, Segmentation fault.
0x5655873c in vmware_bdoor (eax=0xffffb574, ebx=0xffffb578, ecx=0xffffb57c, edx=0xffffb580) at sys-utils/lscpu.c:827
827             __asm__(
(gdb) stepi
segv_handler (sig=0xb, info=0xffffb04c, ignored=0xffffb0cc) at sys-utils/lscpu.c:854
854     {
(gdb) c
Continuing.
Architecture:          i686
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    2
Core(s) per socket:    2
Socket(s):             1
Vendor ID:             AuthenticAMD
CPU family:            21
Model:                 2
Model name:            AMD FX(tm)-4350 Quad-Core Processor
Stepping:              0
CPU MHz:               2000.000
CPU max MHz:           4200.0000
CPU min MHz:           1400.0000
BogoMIPS:              8427.36
Virtualization:        AMD-V
...

so the siglongjmp call hit the sigsetjmp point and made the func
return 0 which means it didn't detect as vmware at all.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]