27.04.2014, 20:59, "Peter Maydell" <[email protected]>:
> On 27 April 2014 17:46, Michael Tokarev <[email protected]> wrote: >> 25.04.2014 21:24, Peter Maydell wrote: >>> It is always going to be possible to determine that you're >>> running on an emulator rather than real hardware, so changing >>> QEMU behaviour just for this is uninteresting. If QEMU >>> behaves differently from the specification (in this case >>> the x86 hardware and architecture manuals) that's an interesting >>> bug. If we just happen to choose a different undefined >>> behaviour from that which hardware does, that is not in >>> my opinion a problem. >> Actually it might be a problem. We know a ton of examples where >> hardware had bugs and software had to compensate and actually >> _expect_ buggy behavour. Or when software depends on (reliable >> repeating) certain behavour in undocumented parts, and hell >> breaks when this (undocumented!) behavour changes. > Yes, sometimes you get that sort of thing. But we should only > put that kind of change in when we actually need it (ie when > there's real guest code that hits it, not just silly test programs > deliberately looking for undefined behaviour), and comment > why it's there so people who need to maintain that bit of code > in future know that it's deliberate and not just accidental. > > I should perhaps have said "that is not inherently a problem". > > thanks > -- PMM Let's imagine we analyse a program(may be a malware) and so run it in emulator. Malware can execute that test and understand that it run in an emulator. After that malware can make decision, that someone analyse it and alter its behavior with a view to make analysis more complicated. So it makes sense to apply that patch. Of course that little fix can't absolutely break a chance to detect emulation, but can make it more difficult.
