Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Weird things I learned while writing an x86 emulator

timdbg.com

Post reply on HN
Print view View original

21–30 of 75 posts

Re: Weird things I learned while writing an x86 emulator

#21

Post by mark_undoio »

schemescape wrote: post #5

I thought this was going to be about a toy emulator/hobby project, but it's apparently about an emulator used in Time Travel Debugging!

Ha, I was just reading some of the discussion and thinking it sounded quite similar to the JIT we use in our own (Linuxy) Time Travel Debugger.

It's similarly am x86-on-x86 JIT / emulator but (and I'm sure WinDbg's TTD is similar) most of what you want to do there is just code copying for any instructions that don't need special instrumentation.

And you want to run entirely in the cache of JITted code so you're close to native speed, rather than exit to C code and make decisions.

Re: Weird things I learned while writing an x86 emulator

#22

Post by menaerus »

Has anyone used TTD, or rr for that purpose in Linux world, to debug a complex multi-threaded application? What is the main use-case of these tools?

For example, limitations of rr seem to suggest that it is almost of no use for multi-threaded programs so I have never actually tried it. I don't know about the TTD though.

  > rr limitations

  > ...

  > emulates a single-core machine. So, parallel programs incur the slowdown of running on a single core. This is an inherent feature of the design.

Re: Weird things I learned while writing an x86 emulator

#23

Post by mark_undoio »

userbinator wrote: post #13

An ADD instruction will update the carry flag but the INC instruction does not! Neither does DEC, and I believe the original reason for this was multiple-precision arithmetic routines --- you need to propagate the carry flag, but also update loop counters and pointers. It seems that the actual behavior of the undefined flags is related to the internal implementation of the shift operation, and is different between di…

IIRC from our similar code, the LEA (load effective address) instruction is useful for doing adds / subtracts of arbitrary integers without updating the flags.

Flags turn out to be quite the annoyance for the kind of in-process virtualization needed by Time Travel Debug. You need to instrument code with minimal overhead so, on the one hand, you don't want to save/restore flags all the time .... And on the other hand it still all has to work when flags get used.

Re: Weird things I learned while writing an x86 emulator

#24

Post by FartyMcFarter »

userbinator wrote: post #13

An ADD instruction will update the carry flag but the INC instruction does not! Neither does DEC, and I believe the original reason for this was multiple-precision arithmetic routines --- you need to propagate the carry flag, but also update loop counters and pointers. It seems that the actual behavior of the undefined flags is related to the internal implementation of the shift operation, and is different between di…

> "Undefined" values are often used by anti-debugging/anti-emulation/VM detection code to determine if the CPU is real hardware or not, so it's actually quite important to emulate them correctly.

That seems quite brittle, unless all real CPUs implement them the same way. If they do, one has to wonder whether it's really undefined or an undocumented part of the x86 spec instead.

Re: Weird things I learned while writing an x86 emulator

#25

Post by psychphysic »

mark_undoio wrote: post #23
userbinator wrote: post #13

An ADD instruction will update the carry flag but the INC instruction does not! Neither does DEC, and I believe the original reason for this was multiple-precision arithmetic routines --- you need to propagate the carry flag, but also update loop counters and pointers. It seems that the actual behavior of the undefined flags is related to the internal implementation of the shift operation, and is different between di…

IIRC from our similar code, the LEA (load effective address) instruction is useful for doing adds / subtracts of arbitrary integers without updating the flags. Flags turn out to be quite the annoyance for the kind of in-process virtualization needed by Time Travel Debug. You need to instrument code with minimal overhead so, on the one hand, you don't want to save/restore flags all the time .... And on the other hand…

Multiplication even.

Re: Weird things I learned while writing an x86 emulator

#26

Post by Sniffnoy »

woodruffw wrote: post #16
Sniffnoy wrote: post #15

Earlier quoted context omitted.

What is it? I can't seem to find it in the paper.

There are many structurally valid 26 byte productions; the diagram on page 2 shows the layout and page 5 has pseudocode for generating them. (There may be even longer valid productions; my analysis was pretty naive. But 26 is already substantially longer than the limit!)

Thanks, I saw that, but I was hoping for explicit examples.

Re: Weird things I learned while writing an x86 emulator

#27

Post by woodruffw »

Sniffnoy wrote: post #26
woodruffw wrote: post #16

Earlier quoted context omitted.

There are many structurally valid 26 byte productions; the diagram on page 2 shows the layout and page 5 has pseudocode for generating them. (There may be even longer valid productions; my analysis was pretty naive. But 26 is already substantially longer than the limit!)

Thanks, I saw that, but I was hoping for explicit examples.

Figure 6 has examples (in the context of instruction generation). But note that those instructions are “nonsense,” in the sense that they’re guaranteed to either #UD at 15 bytes or well before then.

Re: Weird things I learned while writing an x86 emulator

#28

Post by Sniffnoy »

woodruffw wrote: post #27
Sniffnoy wrote: post #26

Earlier quoted context omitted.

Thanks, I saw that, but I was hoping for explicit examples.

Figure 6 has examples (in the context of instruction generation). But note that those instructions are “nonsense,” in the sense that they’re guaranteed to either #UD at 15 bytes or well before then.

Ah, thanks, I missed that! Kind of disappointing that it doesn't give the instructions' dissassembly (so to speak -- obviously as you point out in reality they are nonsense), but I suppose I can sit down and figure that out myself. :)

Re: Weird things I learned while writing an x86 emulator

#29

Post by actionfromafar »

userbinator wrote: post #14
woodruffw wrote: post #7

This is a good list! Another fun quirk: because x86 is a register-memory architecture and allows all kinds of variants of reg/mem operand encodings, there are a handful of equivalent encodings with exactly the same lengths (and just slightly different ModR/M bytes). You can take advantage of this to do software fingerprinting or, in my case, steganography without changing an executable’s size or semantics[1]. [1]: ht…

The (in)famous A86/A386 assembler claimed to use this technique to identify code produced with it. As far as I know, it was just a simple inversion of reg-reg ModRMs depending on the register values being used, although I didn't test it too exhaustively.

Speaking of things with the same names, what happened to Linux a386 and what the heck was it even? I can't find a link nowadays, but it was something like User Mode Linux, but not really.

Re: Weird things I learned while writing an x86 emulator

#30

Post by rcxdude »

menaerus wrote: post #22

Has anyone used TTD, or rr for that purpose in Linux world, to debug a complex multi-threaded application? What is the main use-case of these tools? For example, limitations of rr seem to suggest that it is almost of no use for multi-threaded programs so I have never actually tried it. I don't know about the TTD though. > rr limitations > ... > emulates a single-core machine. So, parallel programs incur the slowdown…

It can still debug multi-threaded programs, but if your bug relies on multi-core interactions it won't appear under rr (you can still catch a lot of race conditions though, and it has a 'chaos mode' which generate irregular scheduling intended to increase the likelyhood of such bugs appearing). It's been used to debug race conditions as well as other bugs in firefox, for example.
Post reply on HN