mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Chuck Ebbert <76306.1226@compuserve.com>
To: Stas Sergeev <stsp@aknet.ru>
Cc: Zachary Amsden <zach@vmware.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Jan Beulich <jbeulich@novell.com>
Subject: Re: + espfix-code-cleanup.patch added to -mm tree
Date: Fri, 11 Aug 2006 22:27:25 -0400	[thread overview]
Message-ID: <200608112230_MC3-1-C7D2-A98F@compuserve.com> (raw)

In-Reply-To: <44CF474C.9070800@aknet.ru>

On Tue, 01 Aug 2006 16:21:32 +0400, Stas Sergeev wrote:

> >> -    .quad 0x0000920000000000    /* 0xd0 - ESPFIX 16-bit SS */
> >> +    .quad 0x00cf92000000ffff    /* 0xd0 - ESPFIX SS */

> > Seems a bit dangerous to allow access to full 4GB through this.  Can you 
> > tighten the limit any?  I suppose not, because the high bits in %esp 
> > really could be anything.  But it might be nice to try setting the limit 
> > to regs->esp + THREAD_SIZE.  Of course, this is not strictly necessary, 
> > just an extra paranoid protection mechanism.

> Since, when calculating the base, I do &-THREAD_SIZE, I guess the minimal
> safe limit is regs->esp + THREAD_SIZE*2... Well, may just I not do that please? :)
> For what, btw? There are no such a things for __KERNEL_DS or anything, so
> I just don't see the necessity.

It's really not that hard to get the limit:

        limit_in_bytes = new_esp | (THREAD_SIZE - 1)
        limit_in_pages = limit_in_bytes >> 12

And this will catch any bad accesses that assume zero-based pointers:

        kernel stack is at f7000000
        user stack is at   b7000000

        SS base =  40000000
        SS limit = b7001fff

All kernel pointers will be >c0000000 and will trap on access if they
try to use SS.  And it will work with any user/kernel split.

-- 
Chuck


             reply	other threads:[~2006-08-12  2:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-12  2:27 Chuck Ebbert [this message]
2006-08-12 10:35 ` Stas Sergeev
  -- strict thread matches above, loose matches on Subject: below --
2006-08-02 19:14 Chuck Ebbert
2006-08-02 19:31 ` Stas Sergeev
     [not found] <200607300016.k6U0GYu4023664@shell0.pdx.osdl.net>
     [not found] ` <44CE766D.6000705@vmware.com>
2006-08-01 12:21   ` Stas Sergeev
2006-08-01 13:38     ` Jan Beulich
2006-08-01 14:37       ` Stas Sergeev
2006-08-01 14:43         ` Jan Beulich
2006-08-01 15:09           ` Stas Sergeev
2006-08-01 21:01     ` Zachary Amsden
2006-08-02 17:12       ` Stas Sergeev
2006-08-02 18:30         ` Zachary Amsden
2006-08-02 19:12           ` Stas Sergeev
2006-08-01  2:24 Chuck Ebbert
2006-08-01 12:39 ` 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=200608112230_MC3-1-C7D2-A98F@compuserve.com \
    --to=76306.1226@compuserve.com \
    --cc=jbeulich@novell.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stsp@aknet.ru \
    --cc=zach@vmware.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®