All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stas Sergeev <stsp@aknet.ru>
To: Pavel Machek <pavel@ucw.cz>
Cc: Alan Cox <alan@redhat.com>,
	Linux kernel <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@osdl.org>,
	Petr Vandrovec <vandrove@vc.cvut.cz>,
	Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua>
Subject: Re: [patch] x86: fix ESP corruption CPU bug
Date: Sun, 13 Mar 2005 23:55:57 +0300	[thread overview]
Message-ID: <4234A8DD.9080305@aknet.ru> (raw)
In-Reply-To: <20050313201020.GB8231@elf.ucw.cz>

Hi.

Pavel Machek wrote:
>> +	andl $(VM_MASK | (4 << 8) | 3), %eax
>> +	cmpl $((4 << 8) | 3), %eax
>> +	je ldt_ss			# returning to user-space with LDT SS
> All common linux apps use same %ss, no? Perhaps it would be more
> efficient to just check if %ss == 0x7b, and proceed directly to
> restore_nocheck if not?
Such an optimization will cost three more
instructions, one of which is a "taken"
jump. It seems like the "taken" jump on
a fast path is not good, while now it is
only 5 instructions with a not-taken jump.
I am not sure here, but I think the current
solution is better (depends on how bad the
"taken" jump is, and how bad it is to have
the three extra insns for that optimization
purpose).

> Or perhaps we could only enable this code
> after application loads custom ldt?
The good thing here is that the code
actually does what you say, i.e. it jumps
to ldt_ss only when the app has loaded
the custom ldt and loaded that selector
to %ss. The way it is implemented, is
probably different from what you mean,
I assume you mean the new per-thread flag?
But I don't see how it can be more optimal,
i.e. you propose to check whether or not
the app altered the ldt (which can just be
the old glibc I think), while the current
solution is to also check whether it was
loaded to %ss (so the glibc case is avoided,
IIRC glibc used to load %gs with LDT selector).
I.e. since right now we jump to ldt_ss only
when the %ss is loaded with an LDT selector,
I think the extra checks are not needed.


  reply	other threads:[~2005-03-13 20:55 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-13 18:20 [patch] x86: fix ESP corruption CPU bug Stas Sergeev
2005-03-13 18:52 ` Grzegorz Kulewski
2005-03-13 19:11   ` Stas Sergeev
2005-03-13 19:37     ` Ondrej Zary
2005-03-13 19:46       ` Stas Sergeev
2005-03-13 20:02   ` Pavel Machek
2005-03-13 20:10 ` Pavel Machek
2005-03-13 20:55   ` Stas Sergeev [this message]
2005-03-13 21:13     ` Linus Torvalds
2005-03-13 22:06       ` [patch] x86: fix ESP corruption CPU bug (take 2) Stas Sergeev
2005-03-14 19:29         ` Alan Cox
2005-03-14 19:59           ` Stas Sergeev
2005-03-15  3:34             ` Andrew Morton
2005-03-15 10:48               ` x86: spin_unlock(), spin_unlock_irq() & others are out of line ? Eric Dumazet
2005-03-15 19:44                 ` Lee Revell
2005-03-15 19:48               ` [patch] x86: fix ESP corruption CPU bug (take 2) Stas Sergeev
2005-03-13 23:17       ` [patch] x86: fix ESP corruption CPU bug Pavel Machek
2005-03-13 23:54         ` Linus Torvalds
2005-03-14  0:16       ` Linus Torvalds
2005-03-14  4:52         ` Stas Sergeev
2005-03-14  9:34           ` Andi Kleen
2005-03-14 10:37             ` [BUG?] x86_64 : Can not read /dev/kmem ? Eric Dumazet
2005-03-21 19:37               ` Andi Kleen
2005-03-22 15:24               ` Andi Kleen
2005-03-14 15:21             ` [patch] x86: fix ESP corruption CPU bug Jakob Eriksson
2005-03-14 17:03               ` linux-os
2005-03-14 17:10                 ` Pavel Machek
2005-03-14 19:24                 ` Brian Gerst
2005-03-14 20:21                   ` Stas Sergeev
2005-03-14 18:02               ` Stas Sergeev
2005-03-14 17:29             ` Stas Sergeev
  -- strict thread matches above, loose matches on Subject: below --
2005-03-14 11:10 Zoltan Boszormenyi
2005-01-03 23:39 Stas Sergeev
2005-01-04  0:01 ` Linus Torvalds
2005-01-04  1:58   ` Stas Sergeev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4234A8DD.9080305@aknet.ru \
    --to=stsp@aknet.ru \
    --cc=alan@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=torvalds@osdl.org \
    --cc=vandrove@vc.cvut.cz \
    --cc=vda@port.imtp.ilyichevsk.odessa.ua \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.