lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 21 Aug 2006 22:29:36 +0900
From:	"Magnus Damm" <magnus.damm@...il.com>
To:	"Andi Kleen" <ak@...e.de>
Cc:	"Magnus Damm" <magnus@...inux.co.jp>, fastboot@...ts.osdl.org,
	linux-kernel@...r.kernel.org, ebiederm@...ssion.com
Subject: Re: [Fastboot] [PATCH][RFC] x86_64: Reload CS when startup_64 is used.

On 8/21/06, Andi Kleen <ak@...e.de> wrote:
>
> >
> > +     /* Reload CS with a value that is within our GDT. We need to do this
> > +      * if we were loaded by a 64 bit bootloader that happened to use a
> > +      * CS that is larger than the GDT limit. This is true if we came here
> > +      * from kexec running under Xen.
> > +      */
> > +     movq    %rsp, %rdx
> > +     movq    $__KERNEL_DS, %rax
> > +     pushq   %rax /* SS */
> > +     pushq   %rdx /* RSP */
> > +     movq    $__KERNEL_CS, %rax
> > +     movq    $cs_reloaded, %rdx
> > +     pushq   %rax /* CS */
> > +     pushq   %rdx /* RIP */
> > +     lretq
>
> Can't you just use a normal far jump? That might be simpler.

I couldn't find a far jump that took a 64-bit address to jump to. But
I guess that the kernel will be loaded in the lowest 4G regardless so
I guess 32-bit pointers are ok, right? That will make it simpler for
sure.

What do you think about reloading CS? Is it the right thing to do, or
is it correct as it is today where we depend on that CS == _KERNEL_CS?
I need to fix kexec-tools regardless, but maybe it is a good idea to
make the 64-bit kernel boot a bit robust too.

Thanks,

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ