Re: [PATCH 7/21] i386 Losing fs gs to bios

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* 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]
  Powered by Linux