|
From: Tom H. <to...@co...> - 2005-10-04 14:14:36
|
Back in January Jeremy added new SYS_PRE_MEM_READ/WRITE macros which as well as doing the standard PRE_MEM_READ/WRITE checks also checked whether the memory in question was in a client segment with the right permissions to read/write to and caused the syscall to return EFAULT if there was a problem. This seems to have been lost during the VEX merge and I was wondering if it was deliberate or not? It is the reason why bug 113796 didn't appear to be present in the 3.0 code when the underlying cause was in fact still present. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Nicholas N. <nj...@cs...> - 2005-10-04 14:40:05
|
On Tue, 4 Oct 2005, Tom Hughes wrote: > Back in January Jeremy added new SYS_PRE_MEM_READ/WRITE macros which > as well as doing the standard PRE_MEM_READ/WRITE checks also checked > whether the memory in question was in a client segment with the right > permissions to read/write to and caused the syscall to return EFAULT > if there was a problem. > > This seems to have been lost during the VEX merge and I was wondering > if it was deliberate or not? It is the reason why bug 113796 didn't > appear to be present in the 3.0 code when the underlying cause was in > fact still present. Not sure if it was deliberate but nobody has since found it necessary to put back in. One thing I didn't like about the approach was that it could change the behaviour of some syscalls, eg. something like: read(0, 0, 0) I think there the buffer is unwritable so Valgrind forces the syscall failure even though the buffer isn't touched because the length is zero. It concerned me that this kind of semantics-changing might have been occurring for other syscalls. Nick |