"Carl Shapiro" <[EMAIL PROTECTED]> writes: > On Tue, Apr 1, 2008 at 1:50 AM, Christophe Rhodes <[EMAIL PROTECTED]> wrote: >> For your information: I believe that this is (was) not a problem with >> CMUCL, though the changes you have made to clear the direction flag >> close to where you set it will work around most of the problem. > > For your information this bug has nothing to do with the Linux kernel > and everything to do with a failure to abide by the x86 calling > convention. Any foreign call which makes use of a string instruction > assuming the direction flag is clear runs the risk of corrupting > memory. To reproduce this bug all you need to do is make a foreign > call memcpy. You do not need to execute a signal handler and you do > not need to be running on a Linux system either.
Oh, many apologies; I assumed that bugs related to the direction flag on a foreign call would have been fixed long ago; obeying the platform ABI is of course required, and I'm sorry that I assumed that the bug you were fixing was a different one. For what it's worth, a change substantially the same as yours was recently made to SBCL in order to minimize the window of vulnerability to the kernel bug I referred to in my message. Please then take my message as a heads-up to tell you that the changes you have made are not sufficient because of kernel bugs, and that to work around bugs in current and historical versions of the Linux and BSD kernels you may wish to clear the direction flag in signal handlers on those platforms; I apologise once again for my misunderstanding. Best, Christophe
