Re: status grub2 port of grub-legasy map command

[Javier Martín]

El dom, 31-05-2009 a las 18:00 +0200, Vladimir 'phcoder' Serbinenko
escribió:
> 2009/5/31 Javier Martín <address@hidden>:
> > El dom, 31-05-2009 a las 13:36 +0200, Vladimir 'phcoder' Serbinenko
> > escribió:
> >> Doing some tests I discovered that freedos MBR (but not the
> >> bootsector) relies on %dl being preserved across int 0x13. In the
> >> patch you can see additional hassle to preserve %dx.
> > Do not do this. Some BIOS functions (like ah=08h) return data in dl.
> > Clients should not expect data in registers to be preserved across
> > interrupt calls. I don't know if there is something like a 8086/PC-BIOS
> > ABI document that we can find to confirm the non-preservation of dl, but
> > the FreeDOS MBR should be fixed then.
> Thank you for pointing ah=8 function
> AFAIK there is no normative reference. The source which was mainly
> used for long years is helppc and it states following:
>       - registers DS, BX, CX and DX are preserved
> (http://heim.ifi.uio.no/~stanisls/helppc/int_13.html)
> But now this reference is terribly outdated.
> SeaBIOS preserves %dl too
> According to wikipedia ah=8 is the only function which returns in %dl.
> I will write an updated version which restores %dx only if ah!=8
Do not waste your time doing so. There are many other functions that
return data in DX, some of them specific to certain systems or TSRs -
check Ralf Brown's Interrupt List [0] for a possibly very incomplete
reference. The fuss about DS, BS, CX and DX being preserved is quite
false, as even Wikipedia shows at [[INT 13]]: just check ah=41h, which
returns in both BX and CX.

The only semi-rational action we can take is to reverse the mapping
_only_ if %dl still contains the mapped data we passed into the int13
handler, but that leaves the question - how do we know that some 0x81 is
actually the 0x81 we put there in substitution of the 0x80 the payload
called with, and not the true result of the call?

> > I managed to get the right %dl passed with the following procedure:
> > let's say I want to boot FreeDOS on hd1, but I will drivemap it so that
> > it will become hd0. Instead of doing this:
> > root=(hd1,1)
> > drivemap -s (hd0) (hd1)
> > chainloader +1
> > I do the following:
> > root=(hd0)
> > drivemap -s (hd0) (hd1)
> > chainloader (hd1,1)+1
> > This gets the right number into %dl (I have not checked multiboot), but
> > I acknowledge that it's nothing more than a hack.
> And it sets es:di (pointer to partition table entry) to incorrect value
I have yet to find a bootsector that uses such information. IIrc, there
were so many buggy BIOSes out there that it was unreliable anyways: MBRs
just check their own memory and bootsectors forget about it entirely.
Nevertheless, this issue deserves a deeper look.

> > I cannot see a way for
> > drivemap to access that data and modify it according to the mappings
> > without breaking modularity with multiboot and chainloader
> I think of something like having a function pointer in kernel
> int (*grub_get_biosdisk) (grub_device_t dev) = grub_get_biosdisk_basic;
> static int grub_get_biosdisk_basic (grub_device_t dev)
> {
>     if (! dev)
>       return 0xff;
>     if (! dev->disk)
>       return 0xff;
>     if (! dev->disk->dev)
>       return 0xff;
>     if (dev->disk->dev->id != GRUB_DISK_DEVICE_BIOSDISK_ID)
>       return 0xff;
>     return (int) dev->disk->id;
> }
> Which can be easily overridden by drivemap
> But I don't really like this approach
Neither do I, but it might be the only non-100%-hackish approach. I
think this part should be addressed by a wider audience (coughs at the
passive listeners in the list).

> > Regarding grub2 using its own drivers, we have no reliable way of
> > conclusively saying that (ata2)==(hd1), so we'd better say nothing at
> > all and keep dl=ffh as we do currently.
> I thought of introducing a variable "biosdrive" and doing something like
> root=ata1
> biosdrive=0x81
> chainloader +1
> boot
> Setting %dl to 0xff if drive can't be determined reliably and isn't
> supplied by user is a good possibility. I'll do so.
Er... AfaIk that's what chainloader and multiboot do when they cannot
determine the boot disk. Regarding that "biosdrive", it would add more
complexity to what already is a non-simple system. I'd say that either
this mapping gets done automagically or the current hack is better,
since it is so obviously a hack that if we cannot solve it future
developers will still have an itch to get rid of it.


[0] http://www.ctyme.com/intr/int-13.htm

-- 
-- Lazy, Oblivious, Recurrent Disaster -- Habbit

signature.asc
Description: Esto es una parte de mensaje firmado digitalmente