Alexander Graf <[EMAIL PROTECTED]> writes: > > As everything except gfxboot works, we can simply change gfxboot in > runtime to use a different value. Unfortunately the mov instruction, > used to read the SS register is only 2 bytes long, so there is no way to > binary patch the mov to something that would contain an address. So the > only way I could think of was an invalid instruction. The UD exception > is intercepted in KVM and is already emulated for VMCALLs. This can be > extended to an opcode, that is officially unused (0f 0c) and have the
It quite is dangerous to use unused opcodes like this. Intel/AMD tend to regularly add new instructions with new CPUs, so currently unused opcodes can quick turn into used ones which don't trap anymore or trap differently or do something unexpected. And yes this has broken software in the past. If you want to continue to use this method (it is unclear given the rest of the thread), I would recommend you keep track of the patched locations instead and use some documented to be trapping 1 or 2 byte opcode and then check in the #UD handler if you hit one of the previously patched locations. Given that solution would have some corner cases (e.g. the table would likely need to have a fixed upper limit), but at least for the gfxboot case just using a very small limited table would be probably enough. -Andi ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
