From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754029AbYIYFCT (ORCPT ); Thu, 25 Sep 2008 01:02:19 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751568AbYIYFCJ (ORCPT ); Thu, 25 Sep 2008 01:02:09 -0400 Received: from smtp-outbound-1.vmware.com ([65.113.40.141]:38546 "EHLO smtp-outbound-1.vmware.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751369AbYIYFCI (ORCPT ); Thu, 25 Sep 2008 01:02:08 -0400 Subject: Re: [PATCH 1/2] VMware detection support for x86 and x86-64 From: Alok Kataria Reply-To: akataria@vmware.com To: "H. Peter Anvin" Cc: Alok kataria , Ingo Molnar , Yan Li , "linux-kernel@vger.kernel.org" , "joerg.roedel@amd.com" , "rjmaomao@gmail.com" , Yinghai Lu , Thomas Gleixner , Daniel Hecht , Zach Amsden In-Reply-To: <48DB1984.8020704@zytor.com> References: <20080221115452.GB13948@elte.hu> <20080907234510.GA24133@yantp.cn.ibm.com> <20080908140423.GG11993@elte.hu> <35f686220809241928k3669e30bi8a98b440443c4bff@mail.gmail.com> <48DB15DB.8040501@zytor.com> <1222317978.23524.117.camel@alok-dev1> <48DB1984.8020704@zytor.com> Content-Type: text/plain Organization: VMware INC. Date: Wed, 24 Sep 2008 22:02:08 -0700 Message-Id: <1222318928.23524.121.camel@alok-dev1> Mime-Version: 1.0 X-Mailer: Evolution 2.8.0 (2.8.0-40.el5_1.1) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2008-09-24 at 21:54 -0700, H. Peter Anvin wrote: > Alok Kataria wrote: > > On Wed, 2008-09-24 at 21:38 -0700, H. Peter Anvin wrote: > >> Alok kataria wrote: > >>> Even if there is anything on that port on native hardware it would > >>> work perfectly well and is _safe_. > >>> First let me post the code to access this backdoor port (the way it > >>> should really be done ) > >>> > >>> So whenever we query port 0x5658 , with the GETVERSION command (which > >>> is the first thing we do with this port), we expect that eax != > >>> 0xFFFFFFFF and ebx has a VMWARE specific MAGIC value. Please note > >>> that ebx has been initialized to zero in the code above. > >>> > >> You have no idea what you just did to a real piece of hardware. > > Why ? what do you mean ? > > ebx is a local variable in the code above that i posted. > > Only when on hypervisor will we write the magic value over there. > > How can this affect native hardware, i fail to understand. > > Please explain. > > > > You accessed a bloody I/O port! > > If you think it's harmless because it was an IN, you're sorely mistaken. Hi Peter, It would be really helpful if you could explain me when can this go wrong or what kinds of problems can this cause on native hardware. Thanks, Alok > > -hpa >