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] [day] [month] [year] [list]
Date:	Wed, 23 Aug 2006 12:10:22 +0900
From:	"Magnus Damm" <magnus.damm@...il.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	"Andi Kleen" <ak@...e.de>, "Magnus Damm" <magnus@...inux.co.jp>,
	fastboot@...ts.osdl.org, linux-kernel@...r.kernel.org
Subject: Re: [Fastboot] [PATCH] x86_64: Reload CS when startup_64 is used.

On 8/22/06, Eric W. Biederman <ebiederm@...ssion.com> wrote:
> "Magnus Damm" <magnus.damm@...il.com> writes:
> > On 8/22/06, Eric W. Biederman <ebiederm@...ssion.com> wrote:
> >>
> >> In long mode the %cs is largely a relic.  However there are a few cases
> >> like lret where it matters that we have a valid value.  Without this
> >> patch it is possible to enter the kernel in startup_64 without setting
> >> %cs to a valid value.  With this patch we don't care what %cs value
> >> we enter the kernel with, so long as the cs shadow register indicates
> >> it is a privileged code segment.
> >>
> >> Thanks to Magnus Damm for finding this problem and posting the
> >> first workable patch.  I have moved the jump to set %cs down a
> >> few instructions so we don't need to take an extra jump.  Which
> >> keeps the code simpler.
> >>
> >> Signed-of-by: Eric W. Biederman <ebiederm@...ssion.com>
> >
> > While at it, could you please fix up the purgatory code in kexec-tools
> > to include this fix so we can boot older versions of the kernel too?
>
> I guess I'm not opposed to a patch but I have some serious reservations
> about a solution that limits my address to 32bits in 64bit mode, and
> appears to break the gdt used for entering the 32bit kernel.

The 32-bit pointer issue can easily be resolved. I don't understand
what you mean with breaking the GDT though - to me it looks like the
entry for CS in entry64.S is broken without my patch. You reload the
GDT to a new one anyway in entry64-32.S so I'm not sure what this
32-bit breakage is that you are talking about.

> I'm up way to late tonight.  I just wanted to resolve the situation
> when it was clear what was going on.

Getting the fix in the kernel is hopefully solved now, thanks for the
help. Next step in my mind is to fix up kexec-tools - I'll send an
updated patch to fastboot later on today.

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