Saving all register of Boehm's Stop-World of hypermodern i686, is it reliable?
Sat Feb 10 20:10:00 GMT 2007
> | J.C. writes:
> | > In boehm-gc/pthread_stop_world.c from GCJ-4.3,
> | > i don't see any specific information of a modern CPU like AMD Athlon64
> | > AM2 or Intel Pentium-M CoreDuo.
> | >
> | > ( to see GC_with_callee_saves_pushed() )
> | >
> | > In my opinion, the registers & flags that must to be saved are:
> | >
> | > * GP registers & flags (like eax,ebx,..,ebp,esp)
> | > * FP registers & flags (like ST(0),..,ST(7))
> | > * MMX registers & flags (from MMX)
> | > * XMM registers & flags (from SSE, SSE2, SSE3, SSE4, ..)
> | > * 3DNow+ registers & flags (very specific from AMD)
> | > * future registers & flags of extensions of new microprocessors.
> | >
> | > If not all register of a hypermodern i686 is saved then it can
> | > soft-crash the application with a certain probability, and it won't be
> | > good for future searching of unknown bugs.
> | I think you need to explain to us where you see a vulnerability. In
> | particular, do you expect pointers to be saved in XMM registers? If
> | so, please explain why you expect this.
> To imagine a theatre of 2 actors,
> the main actor "M" and the Stop-World actor "SW":
> M : i'm calling to e.g. app_quick_memcpy that it uses instructions of cache's
> prefetching and XMM registers to accelerate the copy, thanks to the e.g.
> AMD Athlon Optimization manual. Inside of app_quick_memcpy, it does callings
> to several functions.
Well, that wouldn't be enough to cause any pointers to be lost,
because they'd still be set in the source location. To actually lose
live pointers you'd have to copy to XMM registers and erase the source
memory block before writing the data to the destination block, thus
hiding the data from the gc.
There are other possible ways to hide data from the gc, such as
rotating an address or XORing it by a constant.
> SW: now, i stop your world and start to collect information of your world,
> and i suppose that this traced information will be full.
> M: i've unexpected result of app_quick_memcpy, why? why? i don't find the
> app_quick_memcpy's BUG. It's harmful for my brain.
More information about the Java