Syslinux - Mar 2017 - "isolinux.bin missing or corrupt" when booting USB flash drive in old PC

Hi,

i am looking now at the code which i assume loads the rest of isolinux.bin.

The entry point for program execution from the MBR is obviously at

  http://git.zytor.com/syslinux/syslinux.git/tree/core/isolinux.asm#n186

(Do i get it right that this is the Intel syntax ? (Gronfff))

If POP yields the victim of the most recent not yet popped PUSH, then
this does not look correctly coordinated with the MBR.

isohdpfx.S has:

	pushw	%cx		/* -16: Save sectors on the stack */
	movzbw	%dh, %ax	/* dh = max head */
	incw	%ax		/* From 0-based max to count */
	pushw	%ax		/* -18: Save heads on the stack */
	mulw	%cx		/* Heads*sectors -> sectors per cylinder */

	pushw	%bx		/* -20: EBIOS flag */
	
isolinux.asm has:

		; The following values will have been pushed onto the
		; entry stack:
		;	- partition offset (qword)
		;	- ES
		;	- DI
		;	- DX (including drive number)
		;	- CBIOS Heads
		;	- CBIOS Sectors
		;	- EBIOS flag
		;       (top of stack)

  _start_hybrid:
		pop cx				; EBIOS flag
		pop word [cs:bsSecPerTrack]
		pop word [cs:bsHeads]
		pop dx
		pop di
		pop es

Shouldn't the sequence of
                pop word [cs:bsSecPerTrack]
                pop word [cs:bsHeads]
be the reverse sequence of
        pushw   %cx             /* -16: Save sectors on the stack */
        pushw   %ax             /* -18: Save heads on the stack */
?


Can it be that the two POPW which would need to swap places are the
two byte groups "8f  06  28  30  2e" and "8f  06  2a  30 
5a" near
byte position 64 of isolinux.bin :
  
  fb  c0  78  70  59  2e  8f  06  28  30  2e  8f  06  2a  30  5a

given that isohdpfx.S has:

  HYBRID_MAGIC                    = 0x7078c0fb
  isolinux_hybrid_signature       = 0x7c00+64
  isolinux_start_hybrid           = 0x7c00+64+4

(One may guess that i will propose to patch the ISO at byte 8444*512+70,
 if i get a "yes" on this question.)

---------------------------------------------------------------------

If this is indeed the wrong sequence in isolinux.bin then the riddle
arises why the second try of David with isohdpfc.bin succeeded.

And why do our virtual BIOSes work ? Don't they get the fake EBIOS flag ?
Can it be that isolinux.bin unconditionally first tries
"getlinsec_ebios"
before it defaults to "getlinsec_cbios" which is a consumer of
"bsSecPerTrack" and "bsHeads" ?


How can so few bytes impose so many riddles ?


Have a nice day :)

Thomas

Hi,

i now believe to see a difference between isohdpfd.S and isohdpfc.S
which explains why isohdpfc.bin works with isolinux.bin on our
virtual BIOSes:

isohdpfc pushes the CX value to the stack which it gets from INT 13 AH 41.
Quite surely bit 0 of that CX is not set. But bit 2 "Enhanced Disk
Drive"
could be set.
  https://en.wikipedia.org/wiki/INT_13H

I understand on David's BIOS after

        andw    $1,%cx          /* Bit 0 = fixed disk subset */
        jz      1f

jz jumps because CX is 0. This gets pushed to the stack.
(So the code around the int 13 assumes that either int 13 fails and returns
 CX == 0, or the reply is good enough to reach "andw 1,%cx". Ewww ...)

Now in isolinux.asm we have this test, quite immediately after the
stack was exploited:

		mov si,bios_cbios
		jcxz _start_common
		mov si,bios_ebios
		jmp _start_common

If CX is 4 (= EDD) here, then we go to LBA addressing and the confused
geometry is not of interest on the first try. At least this would explain
why our modern virtual BIOSes let isolinux.bin work. (I.e. the "EBIOS"
flag is indeed effective in isolinux.bin.)


David's BIOS would have to announce in CX "EDD" (or "Drive
Locking and
Ejecting" = bit 1) and would have to be able to do LBA addressing despite
no bit 0 "Device Access using the packet structure".
(Wikipedia gives the vague impression that bit 0 really shall indicate
 the availability of INT 13 AH 42 which does the LBA reading.)


Have a nice day :)

Thomas

On Fri, Mar 24, 2017 at 05:38:31PM +0100, Thomas Schmitt via Syslinux
wrote:
> isohdpfc pushes the CX value to the stack which it gets from INT 13 AH 41.
> Quite surely bit 0 of that CX is not set. But bit 2 "Enhanced Disk
Drive"
> could be set.
>   https://en.wikipedia.org/wiki/INT_13H
> 
> I understand on David's BIOS after
> 
>         andw    $1,%cx          /* Bit 0 = fixed disk subset */
>         jz      1f
> 
> jz jumps because CX is 0. This gets pushed to the stack.
> (So the code around the int 13 assumes that either int 13 fails and returns
>  CX == 0, or the reply is good enough to reach "andw 1,%cx". Ewww
...)
Well... I'm not quite following you.
If it reaches andw 1,%cx then CX will indicate if wanted EBIOS calls
are supported or not as the and will mask away all but the interesting
bit.


The code:
        /* Check to see if we have EBIOS */
        pushw   %dx             /* drive number */
        movb    $0x41, %ah      /* %al == 0 already */
        movw    $0x55aa, %bx
        xorw    %cx, %cx
        xorb    %dh, %dh
        stc
        int     $0x13
        jc      1f
        cmpw    $0xaa55, %bx
        jne     1f
        andw    $1,%cx
        /* Bit 0 = fixed disk subset */
        jz      1f

        /* We have EBIOS; patch in the following code at
           read_sector_cbios: movb $0x42, %ah ;  jmp read_common */
        movl    $0xeb42b4+((read_common-read_sector_cbios-4) << 24), \
                (read_sector_cbios)
        jmp     1f
1:


This is my interpretation:

David's machine's BIOS returns no carry indicating maybe
support. However it doesn't set BX to the correct value, so isohdpfx.S
jumps to 1f with some flags in CX set.

Or David's machine's BIOS returns carry but corrupts CX.

My versions of isohdpfc just replaced the first "jc 1f" above with
"jnc 1f" or with "jmp 1f", thus in the end possibly
indicating EBIOS
support to isolinux (assuming weird return status on the EBIOS check).

Then I interpret the code in isolinux that when EBIOS calls doesn't
work it will fall back to old not extended calls (CBIOS?). That's why
it worked after a delay.


Your findings in isohdpfx.S made clear it confused/is wrong with
regard to order of number of heads and sectors on the stack. Either
the declared offsets were wrong or the order of pushes. At that time I
choose the order of pushes as the correct way.

Good work digging in the code again (isolinux.asm). Yes, it's Intel
syntax, or more specifically nasm syntax (in case it matters). 

Now given your findings in isolinux.asm  it seems that previous choice
was wrong and the declared offsets were correct.

Thus a new patch that corrects the order of pushes (instead of
offsets) _and_ setting CX to zero if EBIOS detection fails. Apply it
to orginal syslinux code.

diff --git a/mbr/isohdpfx.S b/mbr/isohdpfx.S
index 17e1efe..14eca14 100644
--- a/mbr/isohdpfx.S
+++ b/mbr/isohdpfx.S
@@ -151,7 +151,7 @@ next:
 
 	/* Check to see if we have EBIOS */
 	pushw	%dx		/* drive number */
-	movb	$0x41, %ah	/* %al == 0 already */
+	movb	$0x41, %ah
 	movw	$0x55aa, %bx
 	xorw	%cx, %cx
 	xorb	%dh, %dh
@@ -167,20 +167,22 @@ next:
 	   read_sector_cbios: movb $0x42, %ah ;  jmp read_common */
 	movl	$0xeb42b4+((read_common-read_sector_cbios-4) << 24), \
 		(read_sector_cbios)
-	jmp	1f
+	jmp	2f
 1:
+	xor	%cx, %cx	/* Clear EBIOS flag. */
+2:	
 	popw	%dx
 	pushw	%cx		/* EBIOS flag */
 
 	/* Get (C)HS geometry */
 	movb	$0x08, %ah
 	int	$0x13
-	andw	$0x3f, %cx	/* Sector count */
 	popw	%bx		/* EBIOS flag */
-	pushw	%cx		/* -16: Save sectors on the stack */
 	movzbw	%dh, %ax	/* dh = max head */
 	incw	%ax		/* From 0-based max to count */
-	pushw	%ax		/* -18: Save heads on the stack */
+	pushw	%ax		/* -16: Save heads on the stack */
+	andw	$0x3f, %cx	/* Sector count */
+	pushw	%cx		/* -18: Save sectors on the stack */
 	mulw	%cx		/* Heads*sectors -> sectors per cylinder */
 
 	pushw	%bx		/* -20: EBIOS flag */


I suppose you'd want a .bin as well:
<http://www.ludd.ltu.se/~ams/tmp/isohdpfx.bin.170324>


-- 
MartinS