Re: qemu oddness with isolinux vesamenu.c32

["H. Peter Anvin" <hpa@zytor.com>]

[Resend corrected destinations]

H. Peter Anvin wrote:
>>
>> hope this helps
> 
> Cc: the kvm-devel list in the hope that they might be able to shed some 
> light on this.
> 
> What this means is that an expansion ROM located in the ISA expansion 
> area at segment D000 tried to call the DOS interrupt INT 2Ch with 
> AX=42C4h.  I believe INT 2Ch is a no-op in DOS, but does something in 
> the NT kernel.
> 
> The CS:IP of the call was D000:04F0.
> 
> I have no idea what would do this; nothing in the command line list 
> stands out as anything which would install an expansion ROM image into 
> the VM.
> 
> Either way, it would be good to find out what the idea of calling INT 
> 2Ch here is.
> 

Never mind, I tracked it down; it's the extboot extension to KVM.

         /* save old int 19 at int 2b */
[...]
         /* save old int 13 to int 2c */

This is highly unsafe behaviour, *especially* given the choice of
vectors (int 20-3f are used by any DOS-like operating system, and
Syslinux uses them for compatibility with DOS.)

Some BIOSes do this kind of things, but they use vectors in the range
0xc0-0xef.  The use of these vectors is platform-dependent, but since
KVM controls the platform, that is relatively safe.

Furthermore, it is completely unnecessary.  Instead of stuffing the old
pointer in an interupt vector and using the INT instruction, stuff it in
a variable in the local code segment, and use the following sequence:

	pushf
	lcallw *%cs:old_vector

In order to do this it needs, of course, to be able to write to its own
memory, which I'm not sure if qemu-kvm allows by default.  If so, this
is actually a defect in qemu-kvm, since modern expansion "ROMs" *do*
expect to be able to write to their own memory areas during
initialization; see the PnPBIOS spec, Appendix B; support for this
specification is mandatory for PCI systems.

	-hpa