* Zachary Amsden <zach@xxxxxxxxxx> wrote: > I discovered an even more subtle problem; the PnP BIOS code is saving > the %fs and %gs segments in inline assembler, yet it also uses the > same hack for patching in a fake real mode selector for the BIOS data > area. Note that the protected mode selector 0x40 overlaps the user TLS > area in the GDT; this means that badly timed PnP BIOS calls could come > in, save %fs, come back, and restore %fs -- to point to the fake real > mode selector in the GDT. This selector will remain cached despite > the GDT update until the next task context switch, and could very well > be responsible for causing random crashes and corruption in user space > programs which make use of it (notably, Wine). > > Rather than leave a half effort, I wrote an encapsulation function > that saves and restores GDT state properly before attempting to call a > potentially buggy BIOS. Note that saving and restoring %fs and %gs > must be done after restoring the fake real mode GDT entry (0x40 >> 3), > since they could possibly be referencing that segment. Also note that > %cs, %ss, %ds, and %es need not be messed with, since in kernel mode, > they never can point to a user TLS segment. as per my previous comment, wouldnt this patch mostly go away if we dedicated entry #8 to the 0x40 BIOS hack? Ingo
