Mailing-List: contact modperl-help@perl.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <48459EE2.8050701@ice-sa.com>
Date: Tue, 03 Jun 2008 21:43:30 +0200
From: =?ISO-8859-1?Q?Andr=E9_Warnier?= <aw@ice-sa.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Torsten Foertsch <torsten.foertsch@gmx.net>
CC: modperl@perl.apache.org
Subject: Re: Linux::Smaps kernel/perlio dependencies
References: <200806031104.01044.torsten.foertsch@gmx.net>
 <200806031520.25121.torsten.foertsch@gmx.net> <48455F3D.1000201@ice-sa.com>
 <200806031848.21608.torsten.foertsch@gmx.net>
In-Reply-To: <200806031848.21608.torsten.foertsch@gmx.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Torsten,

many thanks for the time taken for the explanation.

I still understand only slightly less than 50% of it, but then I don't 
really need to understand more either.  I am just very glad and thankful 
that there are people such as you who apparently do understand it, upon 
which we can rely to give us a good perl when we need it, a good 
explanation when we ask for it, and upon which we might need to call 
some day when we are really desperate.

And, one other good thing about the explanation below, is that it will 
undoubtedly provide a number of people like me with some esoteric new 
vocabulary for the next time the marketing guys ask us why this damn 
project isn't ready in time.  I can just see their faces when we talk to 
them about boosting performance and avoiding shell code injection by 
taking advantage of the latest processors and glibc features, and now 
switching from user to supervisor mode by means of a Virtual Dynamic 
Shared Object instead of the old pass� software interrupt 0x80.
Great stuff !

Now if I could just understand why the different choices of a perlio 
layer influence the location of this VDSO, I feel that I would instantly 
become a much better perl and mod_perl programmer.  Or was it just the 
fact that I ran the command 3 times in a row ? Hmmm.
But don't ! I really do not need to know about that one.

Danke und Gr�sse
Andr�

P.S. Now that I knew what to look for, there seems to be a good 
explanation here :
http://manugarg.googlepages.com/systemcallinlinux2_6.html
Now I feel that my understanding has climbed to at least 55%.


Torsten Foertsch wrote:
> On Tue 03 Jun 2008, Andr� Warnier wrote:
>> I find it interesting that the answers are all different on system (1),
>> but all the same on system (2).
>> I don't have a clue as to what it means, or what it does to my systems,
>> but I trust you do.
> 
> Just to enlighten you. Originally linux on x86 used to use a software 
> interrupt 0x80 to implement syscalls. With newer processors this is a 
> performance bottleneck. So a new interface (sysenter/sysexit) has been 
> invented to switch from user space to kernel space and back.
> 
> This new interface uses a special page that is mapped in the virtual address 
> space of each process the so called Virtual Dynamic Shared Object (vdso). It 
> was originally located at a well known place in the address space of a 
> process because the C library needs to know where it is to make syscalls.
> 
> Later on it was found that the exact place where in the address space the vdso 
> page is located can be randomized a bit to enhance security. That makes it 
> harder to perform attacks based on shell code injection or other things where 
> the attacker needs to perform syscalls. But on the downside you need a glibc 
> that knows how to locate that page itself. So older programs won't run on a 
> system that randomizes the vdso location.
> 
> So, what you see on "arthur" is a randomized vdso location and on "dent" a 
> fixed one.
> 
> Torsten
> 
> --
> Need professional mod_perl support?
> Just hire me: torsten.foertsch@gmx.net
>