On Feb 18, 2008, at 12:46 PM, Andi Kleen wrote: > 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
I don't think Avi wants anything as hacky in the kernel. > > 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. This is quite a nice idea I thought of as well (that's what the 'generic' binary patching approach would look like). Nevertheless it'd be a lot better to have something that works for all cases without patching binaries, as we might get into TPM problems with that either way. > > > 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. For the gfxboot case a simple variable would be enough. There is only one position where this UD would occur, so it's only one IP to save. Nevertheless please think of this as a hack, not a solution. I only wanted to have something for the meantime while no real fix is available. As I don't have the time right now to actually write a proper one, this was the only way to have something that 'works' at all right now. I strongly hope we will have a working solution until the point where CPUs show up, which will have this opcode used. Alex ------------------------------------------------------------------------- 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
