Linux 2.4.24 contains in arch/i386/mm/fault.c [around line 270]
the following code.
tsk->thread.error_code = error_code;
Openwall 2.4.24-ow1 changes (fixes?) this to:
if (address < TASK_SIZE)
tsk->thread.error_code = error_code;
else
tsk->thread.error_code = 0;
While Linux 2.4.25-pre6 contains:
/* Kernel addresses are always protection faults */
tsk->thread.error_code = error_code | (address >= TASK_SIZE);
I'm assuming this means the openwall change was an error?
Cheers,
MaZe.
On Tue, 20 Jan 2004, Maciej Zenczykowski wrote:
>
> I'm assuming this means the openwall change was an error?
Oh, the openwall approach is fine too - the exact error number doesn't
really matter much, and which one you choose is pretty much a matter of
taste.
Linus
Perhaps, however I assumed that errorcode == 0 is a special case meaning
no error, this seems to be suggested by the code. If so then the ow
approach differs from the current 25pre6 code. The openwall sets it to 0
meaning (I assume) no error, while the 25pre6 code sets it to a non-zero
value, while the 24 code sets it to whatever errorcode was (can it be
zero or nonzero? probably both, since this would explain the change
in the first place...). This effectively means we have 3 different
function source-codes for the address>=TASK_SIZE case, while all behave
identically for address<TASK_SIZE.
On Tue, 20 Jan 2004, Linus Torvalds wrote:
> On Tue, 20 Jan 2004, Maciej Zenczykowski wrote:
> > I'm assuming this means the openwall change was an error?
>
> Oh, the openwall approach is fine too - the exact error number doesn't
> really matter much, and which one you choose is pretty much a matter of
> taste.
> Linus
If it doesn't matter why set the bit at all? If we do set the least
significant bit this is obviously because it shouldn't be zero (i.e. it
doesn't matter as long as it's boolean true), if so then why does ow set
it to zero in this case. Obviously this is somehow _weird_...
Cheers,
MaZe.
On Wed, 21 Jan 2004, Maciej Zenczykowski wrote:
>
> If it doesn't matter why set the bit at all? If we do set the least
> significant bit this is obviously because it shouldn't be zero (i.e. it
> doesn't matter as long as it's boolean true), if so then why does ow set
> it to zero in this case. Obviously this is somehow _weird_...
The error code is _not_ a boolean. It's several bits, and it so happens
that only the low bit matters for kernel space accesses. And it doesn't
actually matter whether it is set (2.6.x) or not (2.4.x), it should just
be fixed.
Linus