lkml.org 
[lkml]   [2010]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [tip:x86/asm] x86-64: Use normal ptregs stub for execve
From
On Wed, Jan 27, 2010 at 8:07 AM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * tip-bot for Brian Gerst <brgerst@gmail.com> wrote:
>
>> Commit-ID:  f19a25c872b20ae4357f72687cf3e7b0da220ee2
>> Gitweb:     http://git.kernel.org/tip/f19a25c872b20ae4357f72687cf3e7b0da220ee2
>> Author:     Brian Gerst <brgerst@gmail.com>
>> AuthorDate: Mon, 25 Jan 2010 10:47:33 -0500
>> Committer:  H. Peter Anvin <hpa@zytor.com>
>> CommitDate: Tue, 26 Jan 2010 23:38:14 -0800
>>
>> x86-64: Use normal ptregs stub for execve
>>
>> Execve historically passed regs by value, so it had a seperate stub.
>> This is no longer true, so change it to use a normal PTREGSCALL stub.
>>
>> Signed-off-by: Brian Gerst <brgerst@gmail.com>
>> LKML-Reference: <1264434453-2204-1-git-send-email-brgerst@gmail.com>
>> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
>> ---
>>  arch/x86/kernel/entry_64.S |   17 +----------------
>>  1 files changed, 1 insertions(+), 16 deletions(-)
>
> FYI, -tip testing found that this commit breaks the grub binary on 64-bit,
> simply running /sbin/grub causes it to segfault:
>
> [ 3145.999766] grub[6706] general protection ip:805c481 sp:ff95629c error:0 in
> grub[8048000+8c000]
>
> i've excluded this commit for now.
>
>        Ingo
>
>

I see what is going on. Grub is a 32-bit statically linked executable
even on a 64-bit distro. The old execve stub forced return to
userspace via iret, but PTREGSCALL apparently doesn't. This means
that the 32-bit %cs isn't getting set. Drop this patch for now.

--
Brian Gerst
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2010-01-27 16:23    [W:0.107 / U:0.352 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site