[int13con] Avoid overwriting random portions of SAN boot disks

The INT13 console type (CONSOLE_INT13) autodetects at initialisation
time a magic partition to be used for logging iPXE console output.  If
the INT13 drive number mapping is subsequently changed (e.g. because
iPXE was used to perform a SAN boot), then the console logging output
will be written to the incorrect disk.

Fix by recording the INT13 vector at initialisation time, and using
this original vector to emulate INT13 calls for all subsequent
accesses.  This should be robust against drive remapping performed
either by ourselves or by another bootloader (e.g. a chainloaded
undionly.kpxe which then performs a SAN boot).

Signed-off-by: Michael Brown <mcb30@ipxe.org>

src/arch/x86/interface/pcbios/int13con.c

 /** Log partition magic signature */
 #define INT13CON_MAGIC "iPXE LOG\n\n"
 
+/** Original INT13 vector */
+static struct segoff __bss16 ( int13con_vector );
+#define int13con_vector __use_data16 ( int13con_vector )
+
 /** Sector buffer */
 static uint8_t __bss16_array ( int13con_buffer, [INT13_BLKSIZE] );
 #define int13con_buffer __use_data16 ( int13con_buffer )
 	int13con_address.buffer.offset = __from_data16 ( int13con_buffer );
 	int13con_address.lba = lba;
 
-	/* Issue INT13 */
-	__asm__ ( REAL_CODE ( "int $0x13\n\t" )
+	/* Emulate INT13 via original vector.  We do this since iPXE
+	 * (or another subsequent bootloader) may hook INT13 and remap
+	 * drive numbers.
+	 */
+	__asm__ ( REAL_CODE ( "pushfw\n\t"
+			      "cli\n\t"
+			      "lcall *int13con_vector\n\t" )
 		  : "=a" ( error )
 		  : "0" ( op << 8 ), "d" ( INT13CON_DRIVE ),
 		    "S" ( __from_data16 ( &int13con_address ) ) );
 		return;
 	}
 
+	/* Store original INT13 vector */
+	copy_from_real ( &int13con_vector, 0, ( 0x13 * 4 ),
+			 sizeof ( int13con_vector ) );
+	DBG ( "INT13CON using original INT13 vector %04x:%04x\n",
+	      int13con_vector.segment, int13con_vector.offset );
+
 	/* Locate log partition */
 	if ( ( rc = int13con_find() ) != 0)
 		return;