Adding "write protect" with call instruction, removing "write protect" with return instruction.
|
Prev: CHEA Dumbass George Gollin's Racial Hate
Next: Adding "write protect" with call instruction, removing "writeprotect" with return instruction.
From: Andy 'Krazy' Glew on 30 May 2010 11:20 On 5/29/2010 8:19 PM, Stefan Monnier wrote: >>> The only way this has a chance of working (on existing hardware) if >>> for the minimum stack frame to be at least 1 page in size, and for the >>> applications to run with write access to the memory management tables. >> A (probably crazy) idea that came to me was to use ECC bit inversion >> to indicate a special "word". (This assumes that inverting all the > > Can someone remind me why these kinds of "solutions" are better than the > ones that have been used for the last few decades (i.e. bounds checking) > which also have the advantage of actually really plugging those hole rather > than just making them harder to use. I agree with you: stack protection (whether obtained by range registers, or protection bitmasks, or canaries, or ECC, or shadowing) is just a band-aid. Bounds-checking is better.
From: Paul A. Clayton on 30 May 2010 18:43 On May 30, 12:15 am, MitchAlsup <MitchAl...(a)aol.com> wrote: [snip] > Modern processors utilize background HW scrubbers that periodically > rumage through the caches and fix single bit ECC errors before they > become double bit (or worse) errors. How are you going to inform these > scrubbers that you don't want certain cached lines scrubbed? Start > with multibit errors and trust that machine check software can figure > out that the user has farted around with the page tables? > > nadda gonna 'happen. Alpha 21364 systems seemed to have no problem encoding metadata (directory information) into the ECC bits. Obviously, the _system_ needs to be aware of the feature. > Just what kind of operating system is going to let user-level software > write page table entries? Every operating system that runs on x86! Technically, it is not the user-level software that is writing to the PTE--it is the hardware. Just as a write can update the modified bit, a return address store could set a protection bit and a return address read could clear the bit. (Note: just because something is possible does not mean that it is advisable!) Paul A. Clayton just a technophile
From: Paul A. Clayton on 30 May 2010 18:55
On May 30, 11:20 am, Andy 'Krazy' Glew <ag-n...(a)patten-glew.net> wrote: > On 5/29/2010 8:19 PM, Stefan Monnier wrote: [snip] > > Can someone remind me why these kinds of "solutions" are better than the > > ones that have been used for the last few decades (i.e. bounds checking) > > which also have the advantage of actually really plugging those hole rather > > than just making them harder to use. Actually, most of them are probably inferior--less general and more kludge-like for that specific function. However, some of the _techniques_ might be useful for other functions. > I agree with you: stack protection (whether obtained by range registers, or protection bitmasks, or canaries, or ECC, > or shadowing) is just a band-aid. > > Bounds-checking is better. Not the least because it is not limited to protecting the return address on the stack. Paul A. Clayton just a technophile |