* Zachary Amsden <[email protected]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
