On Thu, Feb 21, 2008 at 09:59:24PM +0100, Thomas Gleixner wrote:
> On Thu, 21 Feb 2008, Thomas Gleixner wrote:
> > > That or we need to do the NOP/un-NOP part in the update_vsyscall code
> > > dependent on if the current clocksource supports vread, instead of on
> > > the /proc entry access.
> >
On Thu, Feb 21, 2008 at 08:45:53PM +0100, Thomas Gleixner wrote:
> On Thu, 21 Feb 2008, Andi Kleen wrote:
>
> > On Wed, Feb 20, 2008 at 02:57:34PM +0100, Arne Georg Gleditsch wrote:
> > > Hi,
> > >
> > > I'm looking at 2.6.25-rc2. vsyscall_sysctl_change contains code to NOP
> > > out the actual
Andi Kleen <[EMAIL PROTECTED]> writes:
> On Wed, Feb 20, 2008 at 02:57:34PM +0100, Arne Georg Gleditsch wrote:
>> Hi,
>>
>> I'm looking at 2.6.25-rc2. vsyscall_sysctl_change contains code to NOP
>> out the actual system call instructions of the vsyscall page when
>> vsyscall64 is enabled. This
Andi Kleen [EMAIL PROTECTED] writes:
On Wed, Feb 20, 2008 at 02:57:34PM +0100, Arne Georg Gleditsch wrote:
Hi,
I'm looking at 2.6.25-rc2. vsyscall_sysctl_change contains code to NOP
out the actual system call instructions of the vsyscall page when
vsyscall64 is enabled. This seems to
On Thu, Feb 21, 2008 at 09:59:24PM +0100, Thomas Gleixner wrote:
On Thu, 21 Feb 2008, Thomas Gleixner wrote:
That or we need to do the NOP/un-NOP part in the update_vsyscall code
dependent on if the current clocksource supports vread, instead of on
the /proc entry access.
That won't
On Thu, Feb 21, 2008 at 08:45:53PM +0100, Thomas Gleixner wrote:
On Thu, 21 Feb 2008, Andi Kleen wrote:
On Wed, Feb 20, 2008 at 02:57:34PM +0100, Arne Georg Gleditsch wrote:
Hi,
I'm looking at 2.6.25-rc2. vsyscall_sysctl_change contains code to NOP
out the actual system call
On Thu, 21 Feb 2008, Thomas Gleixner wrote:
> > That or we need to do the NOP/un-NOP part in the update_vsyscall code
> > dependent on if the current clocksource supports vread, instead of on
> > the /proc entry access.
>
> That won't fly. We need to sychronize the CPUs when we patch the code,
>
On Thu, 21 Feb 2008, john stultz wrote:
> > > Yes they are. But a system call sequence at a known fixed address
> > > is potentially useful to exploits. That is why it is nop'ed out when
> > > it is not needed.
> >
> > That's a nice intent, but the reality is that this code is broken as
> >
On Thu, 2008-02-21 at 20:45 +0100, Thomas Gleixner wrote:
> On Thu, 21 Feb 2008, Andi Kleen wrote:
>
> > On Wed, Feb 20, 2008 at 02:57:34PM +0100, Arne Georg Gleditsch wrote:
> > > Hi,
> > >
> > > I'm looking at 2.6.25-rc2. vsyscall_sysctl_change contains code to NOP
> > > out the actual
On Thu, 21 Feb 2008, Andi Kleen wrote:
> On Wed, Feb 20, 2008 at 02:57:34PM +0100, Arne Georg Gleditsch wrote:
> > Hi,
> >
> > I'm looking at 2.6.25-rc2. vsyscall_sysctl_change contains code to NOP
> > out the actual system call instructions of the vsyscall page when
> > vsyscall64 is enabled.
On Wed, Feb 20, 2008 at 02:57:34PM +0100, Arne Georg Gleditsch wrote:
> Hi,
>
> I'm looking at 2.6.25-rc2. vsyscall_sysctl_change contains code to NOP
> out the actual system call instructions of the vsyscall page when
> vsyscall64 is enabled. This seems to interact badly with the fallback
>
On Wed, Feb 20, 2008 at 02:57:34PM +0100, Arne Georg Gleditsch wrote:
Hi,
I'm looking at 2.6.25-rc2. vsyscall_sysctl_change contains code to NOP
out the actual system call instructions of the vsyscall page when
vsyscall64 is enabled. This seems to interact badly with the fallback
code in
On Thu, 21 Feb 2008, Andi Kleen wrote:
On Wed, Feb 20, 2008 at 02:57:34PM +0100, Arne Georg Gleditsch wrote:
Hi,
I'm looking at 2.6.25-rc2. vsyscall_sysctl_change contains code to NOP
out the actual system call instructions of the vsyscall page when
vsyscall64 is enabled. This seems
On Thu, 2008-02-21 at 20:45 +0100, Thomas Gleixner wrote:
On Thu, 21 Feb 2008, Andi Kleen wrote:
On Wed, Feb 20, 2008 at 02:57:34PM +0100, Arne Georg Gleditsch wrote:
Hi,
I'm looking at 2.6.25-rc2. vsyscall_sysctl_change contains code to NOP
out the actual system call
On Thu, 21 Feb 2008, john stultz wrote:
Yes they are. But a system call sequence at a known fixed address
is potentially useful to exploits. That is why it is nop'ed out when
it is not needed.
That's a nice intent, but the reality is that this code is broken as
hell:
1) the
On Thu, 21 Feb 2008, Thomas Gleixner wrote:
That or we need to do the NOP/un-NOP part in the update_vsyscall code
dependent on if the current clocksource supports vread, instead of on
the /proc entry access.
That won't fly. We need to sychronize the CPUs when we patch the code,
which is
Arne,
On Wed, 20 Feb 2008, Arne Georg Gleditsch wrote:
> I'm looking at 2.6.25-rc2. vsyscall_sysctl_change contains code to NOP
> out the actual system call instructions of the vsyscall page when
> vsyscall64 is enabled. This seems to interact badly with the fallback
> code in do_vgettimeofday
Hi,
I'm looking at 2.6.25-rc2. vsyscall_sysctl_change contains code to NOP
out the actual system call instructions of the vsyscall page when
vsyscall64 is enabled. This seems to interact badly with the fallback
code in do_vgettimeofday which tries to call gettimeofday if the
configured clock
Hi,
I'm looking at 2.6.25-rc2. vsyscall_sysctl_change contains code to NOP
out the actual system call instructions of the vsyscall page when
vsyscall64 is enabled. This seems to interact badly with the fallback
code in do_vgettimeofday which tries to call gettimeofday if the
configured clock
Arne,
On Wed, 20 Feb 2008, Arne Georg Gleditsch wrote:
I'm looking at 2.6.25-rc2. vsyscall_sysctl_change contains code to NOP
out the actual system call instructions of the vsyscall page when
vsyscall64 is enabled. This seems to interact badly with the fallback
code in do_vgettimeofday
20 matches
Mail list logo
