linux-kernel - Re: failed 'ljmp' in linear addressing mode

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20061127231646.GA21627@srv.junsun.net>
Date:	Mon, 27 Nov 2006 15:16:46 -0800
From:	Jun Sun <jsun@...sun.net>
To:	"linux-os (Dick Johnson)" <linux-os@...logic.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: failed 'ljmp' in linear addressing mode


On Mon, Nov 27, 2006 at 08:58:57AM -0500, linux-os (Dick Johnson) wrote:
> 
> I think it probably resets the instant that you turn off paging. To
> turn off paging, you need to copy some code (properly linked) to an
> area where there is a 1:1 mapping between virtual and physical addresses.
> A safe place is somewhere below 1 megabyte. Then you need to set up a
> call descriptor so you can call that code (you can ljump if you never
> plan to get back). You then need to clear interrupts on all CPUs (use a 
> spin-lock). Once you are executing from the new area, you reset your
> segments to the new area. The call descriptor would have already set
> CS, as would have the long-jump. At this time you can turn off paging
> and flush the TLB. You are now in linear-address protected mode.
>

Thanks for the reply.  But I am pretty much sure I did above correctly.
I use single-instruction infinite loop in the call path to verify
that control does reach last 'ljmp' but not the jump destination.

Below is the hack I made to machine_kexec.c file.  As you can see, I
managed to make the identical mapping between virtual and physical addresses.

Note I did not copy the code into the first 1M.  In fact the code
is located at 0xc0477000 (0x00477000 in physical).  I thought that should be
OK as I did not really go all the way back to real-address mode.

That last suspect I have now is the wrong value in CS descriptor.  Does kernel
have a suitable CS descriptor for the last ljmep to 0x10000000 in linear
addressing mode?  The CS descriptor seems to be a pretty dark magic to me ...

Cheers.

Jun

-----------------
diff -Nru linux-2.6.17.14-1st/arch/i386/kernel/machine_kexec.c.orig linux-2.6.17.14-1st/arch/i386/kernel/machine_kexec.c
--- linux-2.6.17.14-1st/arch/i386/kernel/machine_kexec.c.orig   2006-10-13 11:55:04.000000000 -0700
+++ linux-2.6.17.14-1st/arch/i386/kernel/machine_kexec.c        2006-11-22 15:01:45.000000000 -0800
@@ -212,3 +212,19 @@
        rnk = (relocate_new_kernel_t) reboot_code_buffer;
        (*rnk)(page_list, reboot_code_buffer, image->start, cpu_has_pae);
 }
+
+extern void do_os_switching(void);
+void os_switch(void)
+{
+       void (*foo)(void);
+
+       /* absolutely no irq */
+       local_irq_disable();
+
+       /* create identity mapping */
+       foo=virt_to_phys(do_os_switching);
+       identity_map_page((unsigned long)foo);
+
+       /* jump to the real address */
+       foo();
+}

-
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/