Re: [Fastboot] [PATCH] x86_64: Reload CS when startup_64 is used.

["Magnus Damm" <magnus.damm@gmail.com>]

On 8/22/06, Eric W. Biederman <ebiederm@xmission.com> wrote:
> "Magnus Damm" <magnus.damm@gmail.com> writes:
> > On 8/22/06, Eric W. Biederman <ebiederm@xmission.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@xmission.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