Comparing kernel foo

This is some old 32 bit code from Kos in 'Intel ASM' register format and form.

BuildPm32Task:
; Create Physical Pointer To this TSS len 256
 Mov Edi,PhysicalBaseTss ; TSS
 Mov Eax,WhichFault  ;
 Mov Ecx,SizeOfTss  ;
 Mul Ecx   ; Index In Tss segment to this TSS
 add Eax,Edi   ; And the Base
 Mov Ebx,Eax   ; Save for Fill function
 Mov Dx,8900h  ; Type and Granularity of size
 Mov Ebp,WhichFault  ;
 Shl Ebp,3   ; *8 for Idt
 Call BuildTssInGdt  ; Set it in the GDT to Tss link
 Mov Dx,8500h  ; Type and Size
 Call PutGdtTsInIdt  ; Set the link Idt to Gdt to Tss
 Mov Edi,Ebx   ; This TSS
 Push Edi
 Call InstallTssDataP32
 Call PutPortAccessV86
 Pop Edi
 Ret

This is some code from the Linux kernel which is comparable.

/*H:610 Like the IDT, we never simply use the GDT the Guest gives us.  We keep
 * a GDT for each CPU, and copy across the Guest's entries each time we want to
 * run the Guest on that CPU.
 *
 * This routine is called at boot or modprobe time for each CPU to set up the
 * constant GDT entries: the ones which are the same no matter what Guest we're
 * running. */
void setup_default_gdt_entries(struct lguest_ro_state *state)
{
 struct desc_struct *gdt = state->guest_gdt;
 unsigned long tss = (unsigned long)&state->guest_tss;

 /* The Switcher segments are full 0-4G segments, privilege level 0 */
 gdt[GDT_ENTRY_LGUEST_CS] = FULL_EXEC_SEGMENT;
 gdt[GDT_ENTRY_LGUEST_DS] = FULL_SEGMENT;

 /* The TSS segment refers to the TSS entry for this particular CPU.
  * Forgive the magic flags: the 0x8900 means the entry is Present, it's
  * privilege level 0 Available 386 TSS system segment, and the 0x67
  * means Saturn is eclipsed by Mercury in the twelfth house. */
 gdt[GDT_ENTRY_TSS].a = 0x00000067 | (tss << 16);
 gdt[GDT_ENTRY_TSS].b = 0x00008900 | (tss & 0xFF000000)
  | ((tss >> 16) & 0x000000FF);
}

I am sure this just looks like caca to most everybody else, but I wrote original code in the BIOS for 386 protected mode switch and this shtuff is just second nature to me. When I was young I used to put those odd comments in the code and as time went by I quit doing it because it was funny the first time I reviewed the code and then just got irritating and I removed them all.

As much as I would rather use C , the advantage for a specific processor is nil in my opinion. I often rewrote these core code modules for different processors and I really like RISC big-endian machine code better, but Intel was the most common place to get work. I also use the 'Flat' real mode to play with VM before I switched. I also incorporated a full debugger that was invoked on a fault. That was my first design. It did disassembly and was rock solid before I did any more of the design.

It might scare somebody to drop to a debugger, but it was always my opinion that if any flaw existed that would stop the machine or fail in some bad way, I wanted to be all over that and know why. As the code is designed, I have not had a flaw in two decades now. I suppose it is possible, however I spent hours examining all the critical aspects of task switches, memory, and even timed every instruction of every module.

The silly thing is that I am the only person who ever used this OS.

The extensions to the OS are all written in pseudo code and all higher level functions beyond the main operating loop and memory/task management are purely gospel symbolic code that is executed as single steps. That took me nearly a year to design.

Something strange that I ran into the other day tells me that if I don't look deeply and have full knowledge of the source, it can be twisted, even if it is intended to be for a good purpose, back doors can be a major risk. Specifically I am referring to a self concealing compiling source sequence obfuscation. If you understand the process of bootstrap from the first hexadecimal code, you know who I'm talking about.