Fun with NULL pointers, part 2

Posted Jul 21, 2009 22:04 UTC (Tue) by mjthayer (guest, #39183)
Parent article: Fun with NULL pointers, part 2

Presumably if a NULL pointer can be a valid pointer under certain circumstances then checks for NULL to determine invalid pointers would be wrong under the same circumstances, and the right thing would be to avoid using pointers which have not been initialised to their final value. Note that gcc *can* spot and warn about that if the pointer is not initialised to NULL first.

to post comments

Fun with NULL pointers, part 2

Posted Jul 21, 2009 22:18 UTC (Tue) by sourcejedi (guest, #45153) [Link] (4 responses)

Actually, I don't think it is valid for kernel code to dereference NULL. The reason being, it would be a __user address, which should be accessed using copy_from_user() or similar.

Fun with NULL pointers, part 2

Posted Jul 21, 2009 23:01 UTC (Tue) by mjthayer (guest, #39183) [Link] (3 responses)

That speaks for checking pointers against the user-kernel boundary rather than against NULL. Slightly less efficient I know, but more effective defensively.

Fun with NULL pointers, part 2

Posted Jul 22, 2009 11:50 UTC (Wed) by etienne_lorrain@yahoo.fr (guest, #38022) [Link] (2 responses)

And the i386 has a very nice assembly instruction for that, which perfectly fits: "bound".
The nice thing is that it is very short, and never mess with the jump instruction prediction subsystem because if not inside boundaries, an exception is generated.
I just know one single software using that assembly instruction, and it works as intended.

Fun with NULL pointers, part 2

Posted Jul 23, 2009 2:20 UTC (Thu) by quotemstr (subscriber, #45331) [Link] (1 responses)

Not really all that nice:

Intel's designers added the bound instruction to allow a quick check of the range of a value in a register. This is useful in Pascal, for example, which checking array bounds validity and when checking to see if a subrange integer is within an allowable range. There are two problems with this instruction, however. On 80486 and Pentium/586 processors, the bound instruction is generally slower than the sequence of instructions it would replace:
     cmp     reg, LowerBound
     jl      OutOfBounds
     cmp     reg, UpperBound
     jg      OutOfBounds
On the 80486 and Pentium/586 chips, the sequence above only requires four clock cycles assuming you can use the immediate addressing mode and the branches are not taken; the bound instruction requires 7-8 clock cycles under similar circumstances and also assuming the memory operands are in the cache. A second problem with the bound instruction is that it executes an int 5 if the specified register is out of range. IBM, in their infinite wisdom, decided to use the int 5 interrupt handler routine to print the screen. Therefore, if you execute a bound instruction and the value is out of range, the system will, by default, print a copy of the screen to the printer. If you replace the default int 5 handler with one of your own, pressing the PrtSc key will transfer control to your bound instruction handler. Although there are ways around this problem, most people don't bother since the bound instruction is so slow.

Fun with NULL pointers, part 2

Posted Jul 23, 2009 8:54 UTC (Thu) by etienne_lorrain@yahoo.fr (guest, #38022) [Link]

Nowadays, if you are not in a tight loop written in assembly, you no more count the number of cycles of instructions but the amount of time it takes to load it into the layer 1 memory cache, and the time to reload the previous cache line after executing your instruction, it is basically proportional to the size of the instruction.
The two cmp solution needs 16 bytes (in protected mode) if the out-of-bound handler is within 256 bytes of the test, and 32 bytes if not: that is a complete cache line.
The bound solution needs 8 bytes, mostly because it does not encode the out-of-bound address handler.
The difference loading the other 24 bytes is a lot more significant than the 4 cycles difference.
Even the failed branch prediction you will probably get is more important - even the fact that you have polluted the branch prediction cache is probably more important.
The default INT5 screen print handler is not accessible under Linux, BIOS is not mapped and the APIC is configured differently, if I remember well you have a SIGBUS exception in user mode and something as easy to trap/abort in kernel mode.