All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Alexander van Heukelum <heukelum@fastmail.fm>
Cc: Stas Sergeev <stsp@aknet.ru>, Ingo Molnar <mingo@elte.hu>,
	Thomas Gleixner <tglx@linutronix.de>,
	Cyrill Gorcunov <gorcunov@gmail.com>, Tejun Heo <tj@kernel.org>,
	Zachary Amsden <zach@vmware.com>,
	Chuck Ebbert <76306.1226@compuserve.com>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: Ping: Re: [PATCH 0/2] i386: espfix fixes
Date: Tue, 16 Jun 2009 16:29:10 -0700	[thread overview]
Message-ID: <4A382AC6.2070603@zytor.com> (raw)
In-Reply-To: <1245192098.31604.1320729303@webmail.messagingengine.com>

Alexander van Heukelum wrote:
> 
> On http://lkml.indiana.edu/hypermail/linux/kernel/0608.0/0162.html:
>>>> - .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.
> 
> In the normal case user-esp would be between 0 and 65535, and in
> that case the memory range in the ESPFIX stack segment would be
> pretty small. But userspace can set esp to just about anything if
> it really wants to, and in that case the reduction of the memory
> range is pretty much wothless (kernel stacks are allocated way
> above the code). As you said: may we just not do that, please?
> 

Who are "we", here?  First of all, this is about a 16-bit stack segment,
right?  Why are we doing a 4 GB limit at all if this is a 16-bit stack
segment (where the stack can only be touched for the first 64K even if a
stack operation happens)?

I clearly don't quite understand at a glance what is going on.
	
	-hpa


      reply	other threads:[~2009-06-16 23:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-07 12:42 [PATCH 0/2] i386: espfix fixes Alexander van Heukelum
2009-06-07 12:42 ` [PATCH 1/2] i386: fix return to 16-bit stack from NMI handler Alexander van Heukelum
2009-06-07 12:42 ` [PATCH 2/2, tip] i386: Fix/simplify espfix, move it into assembly Alexander van Heukelum
2009-06-07 12:42 ` [PATCH 2/2, mainline] " Alexander van Heukelum
     [not found] ` <1245182594.27756.1320705931@webmail.messagingengine.com>
2009-06-16 21:19   ` Ping: Re: [PATCH 0/2] i386: espfix fixes Stas Sergeev
2009-06-16 22:41     ` Alexander van Heukelum
2009-06-16 23:29       ` H. Peter Anvin [this message]

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=4A382AC6.2070603@zytor.com \
    --to=hpa@zytor.com \
    --cc=76306.1226@compuserve.com \
    --cc=gorcunov@gmail.com \
    --cc=heukelum@fastmail.fm \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=stsp@aknet.ru \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    --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 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.