qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/5] linux-user: add open() hijack infrastructur


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH 2/5] linux-user: add open() hijack infrastructure
Date: Thu, 3 Nov 2011 11:33:01 -0700

On 03.11.2011, at 02:34, David Gilbert <address@hidden> wrote:

> On 2 November 2011 19:23, Alexander Graf <address@hidden> wrote:
>> There are a number of files in /proc that expose host information
>> to the guest program. This patch adds infrastructure to override
>> the open() syscall for guest programs to enable us to on the fly
>> generate guest sensible files.
>> 
>> Signed-off-by: Alexander Graf <address@hidden>
>> ---
>>  linux-user/syscall.c |   52 
>> +++++++++++++++++++++++++++++++++++++++++++++++--
>>  1 files changed, 49 insertions(+), 3 deletions(-)
>> 
>> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
>> index 9f5da36..38953ba 100644
>> --- a/linux-user/syscall.c
>> +++ b/linux-user/syscall.c
>> @@ -4600,6 +4600,52 @@ int get_osversion(void)
>>     return osversion;
>>  }
>> 
>> +static int do_open(void *cpu_env, const char *pathname, int flags, mode_t 
>> mode)
> 
> Once you open the pandoras-box that is emulating /proc, I think you'll 
> probably
> need to hook it in more places and be more general; although you may
> well get away
> with it for this particular case.
> 
> Isn't it better to put the filename interception code somewhere more general
> so that it can also be misused by other calls - e.g. stat().

We can move it when we get there :).

> 
> I guess you're also going to need to be able to do /proc/pid/* instead
> of /proc/self;
> something is bound to use that.

I was hoping to get away with a bit less involving. Sure, we could actually 
open the pandora box of emulating all of /proc, but I really don't want to go 
down that route.

Since all these files already do exist on the host view, I don't think we have 
to fake stat(). The file size will be wrong either way.

So yes, eventually we might have to use the big sledge hammer of emulating all 
of /proc, but as long as I can refrain from it I will :). It's just a _lot_ of 
work.

Alex

> 
> Dave



reply via email to

[Prev in Thread] Current Thread [Next in Thread]