3 ms·

How to check if a pointer is in a range of memory

13 points by signa11 4y ago

westmeal 4y ago
Actually pretty interesting, Chen's posts are always full of interesting edge cases and general computing weirdness.
amluto 4y ago
This made me sad: > But why do you add 8 to move to the next selector? Why not just increment the selector? Because the bottom three bits of the selector are used for other things. In particular, the bottom bit of the selector is used to choose the selector table. Let’s ignore bits 1 and 2 since they are not relevant to the discussion. Assume for convenience that they are always zero.² > ² I know that in practice they aren’t. I’m assuming they are zero for convenience. If you are writing segmented protected mode user code on a modern OS that has nearly complete support for it (Linux! [0]), you should know how this works. And Raymond Chen is, uncharacteristically, wrong. The bottom two bits are RPL (“Requested Privilege Level”), and they are generally both set in user mode, so RPL=3. The next bit is TI (table indicator), which is 0 for GDT (used for flat memory or 16/32-bit TLS on modern Linux) or 1 for LDT (controlled by modify_ldt, and this is what you will use for, ahem, modern protected mode segmented code). So you will add 8 to your segment selector for the next LDT segment (which is not obviously useful unless you are pretending to be in real mode), and the selector & 8 == 7 most of the time. Sadly, Windows dropped support for those most excellent features of modern CPUs years ago, so it’s understandable that Raymond got his bits in the wrong order :) (Intel and AMD have both dropped proper x87 segmentation support a few years ago, so interesting old apps don’t work any more even in a VM. Whoops. I tried advocating for a real fix, but there’s not much of a business case to be made.) [0] Keeping this working is kind of fun. We have a pretty strong test suite for it these days.

3 ms·

How to check if a pointer is in a range of memory

13 points by signa11 4y ago

westmeal 4y ago
Actually pretty interesting, Chen's posts are always full of interesting edge cases and general computing weirdness.
amluto 4y ago
This made me sad: > But why do you add 8 to move to the next selector? Why not just increment the selector? Because the bottom three bits of the selector are used for other things. In particular, the bottom bit of the selector is used to choose the selector table. Let’s ignore bits 1 and 2 since they are not relevant to the discussion. Assume for convenience that they are always zero.² > ² I know that in practice they aren’t. I’m assuming they are zero for convenience. If you are writing segmented protected mode user code on a modern OS that has nearly complete support for it (Linux! [0]), you should know how this works. And Raymond Chen is, uncharacteristically, wrong. The bottom two bits are RPL (“Requested Privilege Level”), and they are generally both set in user mode, so RPL=3. The next bit is TI (table indicator), which is 0 for GDT (used for flat memory or 16/32-bit TLS on modern Linux) or 1 for LDT (controlled by modify_ldt, and this is what you will use for, ahem, modern protected mode segmented code). So you will add 8 to your segment selector for the next LDT segment (which is not obviously useful unless you are pretending to be in real mode), and the selector & 8 == 7 most of the time. Sadly, Windows dropped support for those most excellent features of modern CPUs years ago, so it’s understandable that Raymond got his bits in the wrong order :) (Intel and AMD have both dropped proper x87 segmentation support a few years ago, so interesting old apps don’t work any more even in a VM. Whoops. I tried advocating for a real fix, but there’s not much of a business case to be made.) [0] Keeping this working is kind of fun. We have a pretty strong test suite for it these days.