On 17.10.2008 00:09, ron minnich wrote:
On Thu, Oct 16, 2008 at 3:07 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 16.10.2008 23:54, ron minnich wrote:
On Thu, Oct 16, 2008 at 2:52 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
If that's it, the solution is absolutely simple. And I mean totally simple.
- Backup old content
- Write ffffffff
at this point it is game over. The code that does this is in rom.
Hm. Unshare only this function, maybe with another name?
printk?
Think of point 1-4 as one "atomic" operation. pci_conf1_read_config32 does not call any other function, so simply unshare that and be happy.
- Read back and save in a variable
- Restore old content.
Make sure no code blacked out by the decode is executed between 1 and 4 and you're safe. If you're feeling paranoid, do it as inline asm. Make sure that short sequence is never ever run as XIP code in ROM (I can do that checking right now).
What am I missing?
the big thing is that the problem code is a binary vga bios over which we have zero control. :-(
Hmmm. Is it running in vm86? If yes, we can trap I/O port writes and reads, so this is solvable. Same should apply to x86emu.
this is getting kind of hideously complex. Let's think on it some more.
I'm not completely getting this. Do we run the binary blob from inside coreboot or does SeaBIOS perform that task? If coreboot does it, we have some trapping code for BIOS emulation anyway. If SeaBIOS does it, the problem is moot since SeaBIOS is independent and completely in RAM.
Regards, Carl-Daniel