5 ms·

Cool, but why do you have to disable ALSR for recording to work?

by d33 10y ago

wyldfire 10y ago
If the implementation records the state of your program at each time interval as "the values stored at particular memory locations", it's much simpler to put those values back at those locations than it would be to recognize the memory map and decompose the state in order to play it back at the arbitrarily established offsets used with ASLR. As a practical matter, ASLR should have little if any impact to nearly all programs design, so disabling it at development/debug time should not come at a big cost. BTW this post states "There is no fundamental reason for [ASLR] restriction, but it is some work to fix." EDIT: I see, your focus is specifically on recording. Disregard this comment, good point.
moyix 10y ago
If I had to guess it just simplifies the implementation. If you have deterministic load addresses then you can just reload the program on replay. If you have ASLR on, then you need to record where each library/stack/heap is and arrange for them to be placed at the same place when you replay. It's doable (though I don't know offhand how to specify the stack/heap location from userspace) but extra work. I've done similar things before – in PANDA we don't strictly need to snapshot the full device state when creating a recording; it would be enough to just keep track of which memory regions are I/O and reconstitute that mapping. But QEMU's savevm/loadvm saves and restores that mapping as a side effect so it's easier to just let that happen. Edit: also, instead of disabling ASLR system-wide, it might be better to just use "setarch `uname -m` -R <pypy>", which disables it for just a single process.
masklinn 10y ago
Cf "Current issues" section: > Only works on Linux, and only with Address Space Layout Randomization (ASLR) disabled. There is no fundamental reason for either restriction, but it is some work to fix.
DanWaterworth 10y ago
Here's a python program that should be deterministic, but isn't without disabling ASLR: print id(object())
- masklinn 10y ago
  Why should this program be deterministic?
  - moyix 10y ago
    Reversible debugging (also known as record and replay) requires making the program behave exactly the same way every time. That way you can "execute backward": at statement n of the program, restart it from the beginning, and stop at statement n-1 (in practice you would take snapshots of the program state along the way so you don't have to re-execute all the way from the beginning of the program). In the example given here, you could get away with it since control flow doesn't depend on the value of id(object()). But for example, if you had: if (id(object()) >> 12) & 1: print "foo" else: print "bar" You would need to guarantee that id(object()) always returned the same value so that the execution follows the same path.
  - DanWaterworth 10y ago
    Ah, you've caught me out on my sloppy use of English. What I should have said is that the address space layout is a source of non-determinism that would otherwise need to be accounted for in the recording of a program. Further, I hold to the view that given a program, knowledge of the thread execution schedule/scheduler and the results of external calls, a program's execution should be deterministic. Thinking about this now, I realize disabling ASLR shouldn't be enough to fix this problem since recording and replaying are sufficiently different.
    - masklinn 10y ago
      > What I should have said is that the address space layout is a source of non-determinism that would otherwise need to be accounted for in the recording of a program. Ah yes, it needs to be deterministic in the context of a time-traveling debugger, I was thinking about the general case, sorry. > Further, I hold to the view that given a program, knowledge of the thread execution schedule/scheduler and the results of external calls, a program's execution should be deterministic. Surely it is, if you precisely know all timings and IO and can replay them there's nowhere for non-determinism to creep in. That's not really an acceptable scale of required knowledge for a time-traveling debugger though.
mzs 10y ago
"no longer necessary from revision ff376ccacb36."

Cool, but why do you have to disable ALSR for recording to work?

by d33 10y ago

Cool, but why do you have to disable ALSR for recording to work?

If the implementation records the state of your program at each time interval as "the values stored at particular memory locations", it's much simpler to put those values back at those locations than it would be to recognize the memory map and decompose the state in order to play it back at the arbitrarily established offsets used with ASLR. As a practical matter, ASLR should have little if any impact to nearly all programs design, so disabling it at development/debug time should not come at a big cost. BTW this post states "There is no fundamental reason for [ASLR] restriction, but it is some work to fix." EDIT: I see, your focus is specifically on recording. Disregard this comment, good point.

moyix 10y ago

If I had to guess it just simplifies the implementation. If you have deterministic load addresses then you can just reload the program on replay. If you have ASLR on, then you need to record where each library/stack/heap is and arrange for them to be placed at the same place when you replay. It's doable (though I don't know offhand how to specify the stack/heap location from userspace) but extra work. I've done similar things before – in PANDA we don't strictly need to snapshot the full device state when creating a recording; it would be enough to just keep track of which memory regions are I/O and reconstitute that mapping. But QEMU's savevm/loadvm saves and restores that mapping as a side effect so it's easier to just let that happen. Edit: also, instead of disabling ASLR system-wide, it might be better to just use "setarch `uname -m` -R <pypy>", which disables it for just a single process.

masklinn 10y ago

Cf "Current issues" section: > Only works on Linux, and only with Address Space Layout Randomization (ASLR) disabled. There is no fundamental reason for either restriction, but it is some work to fix.

DanWaterworth 10y ago

Here's a python program that should be deterministic, but isn't without disabling ASLR: print id(object())

masklinn 10y ago
Why should this program be deterministic?
- moyix 10y ago
  Reversible debugging (also known as record and replay) requires making the program behave exactly the same way every time. That way you can "execute backward": at statement n of the program, restart it from the beginning, and stop at statement n-1 (in practice you would take snapshots of the program state along the way so you don't have to re-execute all the way from the beginning of the program). In the example given here, you could get away with it since control flow doesn't depend on the value of id(object()). But for example, if you had: if (id(object()) >> 12) & 1: print "foo" else: print "bar" You would need to guarantee that id(object()) always returned the same value so that the execution follows the same path.
- DanWaterworth 10y ago
  Ah, you've caught me out on my sloppy use of English. What I should have said is that the address space layout is a source of non-determinism that would otherwise need to be accounted for in the recording of a program. Further, I hold to the view that given a program, knowledge of the thread execution schedule/scheduler and the results of external calls, a program's execution should be deterministic. Thinking about this now, I realize disabling ASLR shouldn't be enough to fix this problem since recording and replaying are sufficiently different.
  - masklinn 10y ago
    > What I should have said is that the address space layout is a source of non-determinism that would otherwise need to be accounted for in the recording of a program. Ah yes, it needs to be deterministic in the context of a time-traveling debugger, I was thinking about the general case, sorry. > Further, I hold to the view that given a program, knowledge of the thread execution schedule/scheduler and the results of external calls, a program's execution should be deterministic. Surely it is, if you precisely know all timings and IO and can replay them there's nowhere for non-determinism to creep in. That's not really an acceptable scale of required knowledge for a time-traveling debugger though.

mzs 10y ago

"no longer necessary from revision ff376ccacb36."