* Withdraw: [PATCH] x86-64: fix another kernel data leak to 32-bit processes
@ 2009-10-20 6:13 Jan Beulich
2009-10-20 6:14 ` Ingo Molnar
0 siblings, 1 reply; 2+ messages in thread
From: Jan Beulich @ 2009-10-20 6:13 UTC (permalink / raw)
To: mingo, tglx, hpa; +Cc: stable, linux-kernel
>Unfortunately I didn't realize that the other instances of branches to
>int_ret_from_sys_call also need fixing when preparing the previous
>similar patch. The issue fixed here was in fact introduced by an
>earlier patch of mine (295286a89107c353b9677bc604361c537fd6a1c0, i.e.
>in 2.6.28, but through stable now also present in 2.6.27), making
>kernel stack contents potentially visible through R8...R11 when an
>this or earlier syscall got interrupted prior to the handler being able
>to decrement the stack pointer (such that the space normally used by
>those registers within pt_regs would get overwritten by the interrupt
>handler stub).
That analysis wasn't right after all - there's a CLEAR_RREGS in each of
the modified paths already, so the change is unnecessary (and adding
redundant code). Please don't apply it.
>While touching the code, I also swapped the branch pairs so that the
>static branch prediction logic would consider the syscall-number-in-
>range case the taken path.
If this would seem a worthwhile change, I can re-send it as a separate,
lower priority patch...
Jan
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Withdraw: [PATCH] x86-64: fix another kernel data leak to 32-bit processes
2009-10-20 6:13 Withdraw: [PATCH] x86-64: fix another kernel data leak to 32-bit processes Jan Beulich
@ 2009-10-20 6:14 ` Ingo Molnar
0 siblings, 0 replies; 2+ messages in thread
From: Ingo Molnar @ 2009-10-20 6:14 UTC (permalink / raw)
To: Jan Beulich; +Cc: tglx, hpa, stable, linux-kernel
* Jan Beulich <JBeulich@novell.com> wrote:
> >Unfortunately I didn't realize that the other instances of branches
> >to int_ret_from_sys_call also need fixing when preparing the previous
> >similar patch. The issue fixed here was in fact introduced by an
> >earlier patch of mine (295286a89107c353b9677bc604361c537fd6a1c0, i.e.
> >in 2.6.28, but through stable now also present in 2.6.27), making
> >kernel stack contents potentially visible through R8...R11 when an
> >this or earlier syscall got interrupted prior to the handler being
> >able to decrement the stack pointer (such that the space normally
> >used by those registers within pt_regs would get overwritten by the
> >interrupt handler stub).
>
> That analysis wasn't right after all - there's a CLEAR_RREGS in each
> of the modified paths already, so the change is unnecessary (and
> adding redundant code). Please don't apply it.
>
> >While touching the code, I also swapped the branch pairs so that the
> >static branch prediction logic would consider the syscall-number-in-
> >range case the taken path.
>
> If this would seem a worthwhile change, I can re-send it as a
> separate, lower priority patch...
Please do - thanks!
Ingo
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2009-10-20 6:14 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-10-20 6:13 Withdraw: [PATCH] x86-64: fix another kernel data leak to 32-bit processes Jan Beulich
2009-10-20 6:14 ` Ingo Molnar
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.