Index
> Main > No longer mov cr9-cr15 out side of long mode |
| Author |
|
|
DimonSoft 01 Feb 2023, 19:40
Didn’t bother looking through the docs to ensure, but, AFAIR, Unreal Mode is achieved with a special kind of processor memory management setup performed before switching back to Real-Address Mode. From the decoder’s point of view the CR8–CR15 are still unencodeable in the instruction format, since they require additional bit from a REX prefix. Meanwhile REX prefixes are simple INC and DEC instructions in any other modes except long mode, so are not recognizable in real mode.
|
|||
01 Feb 2023, 19:40 |
|
|
revolution 01 Feb 2023, 22:52
Unreal mode is unrelated to the instruction decoding. It only affects the ability to have addresses >64k. It is a rewrite of the segment register shadow space.
Code: mov esi, 1 shl 24 mov al, [esi] ; fault in real mode, allowed in unreal mode |
|||
|
01 Feb 2023, 22:52 |
|
|
Zoltanmatey31 02 Feb 2023, 08:31
I see. although i just wondered what if you set some flag to 64 bit operands and then this switches on longmode like interpretation of the CS segment.
EDIT: I have found this just now: "a descriptor having the 32-bit attribute ("D" bit) set to one." is there a 64 bit attribute like this or system register have to be accessed? can not it be so that the system register is also set to 64 bit and this one is preserved? again, i dont know how long mode functions on the system level. |
|||
|
02 Feb 2023, 08:31 |
|
|
revolution 02 Feb 2023, 08:53
Zoltanmatey31 wrote: I see. although i just wondered what if you set some flag to 64 bit operands and then this switches on longmode like interpretation of the CS segment. In fasm you do this: Code: use64 ; long mode encoding mov rax,cr8 ; this is fine use16 ; real or unreal mode mov eax,cr8 ; die |
|||
|
02 Feb 2023, 08:53 |
|
|
macomics 02 Feb 2023, 09:46
I can also add that even a 64-bit operating system sets the correct values for each thread. And in each thread, the processor execution context (including CR0-CR15) is set separately and in a 32-bit application on a 64-bit OS, it will not be possible to set values in CR8-CR15.
|
|||
|
02 Feb 2023, 09:46 |
|
|
revolution 02 Feb 2023, 10:03
I notice that objdump decodes the following in 32-bit mode:
Code: ~ objdump -b binary -D -M intel-mnemonic -m i386 cr8.bin cr8.bin: file format binary Disassembly of section .data: 00000000 <.data>: 0: f0 0f 20 c0 mov eax,cr8 4: f0 0f 20 c8 mov eax,cr9 8: f0 0f 20 d0 mov eax,cr10 c: f0 0f 20 d8 mov eax,cr11 10: f0 0f 20 e0 mov eax,cr12 14: f0 0f 20 e8 mov eax,cr13 18: f0 0f 20 f0 mov eax,cr14 1c: f0 0f 20 f8 mov eax,cr15 Both of them can't be right. |
|||
|
02 Feb 2023, 10:03 |
|
|
Zoltanmatey31 02 Feb 2023, 20:22
I used to find some pages i believe about instruction encoding on stackoverflow website if i am right about the naming.
However this was a while ago not sure if they still have information on x86-64 architecture (and not just high level languages). i did only a bit of programming in assembly (3 functions i have written or 4-5 maybe, one with self modifying code this is why i needed information on opcode encoding, i have found that there is moveax instruction and moval instruction separate opcodes which only take one argument and are both one byte, but assemblers dont honour it, just chose one encoding or the other according to some whims, i would like to write macro for the separate encodings). |
|||
|
02 Feb 2023, 20:22 |
|
< Last Thread | Next Thread > |
Forum Rules:
|