On 17-06-20 13:09:50, stan wrote:
On Tue, 20 Jun 2017 12:20:57 -0400
Tom Horsley <horsley1953@xxxxxxxxx> wrote:
> That seems like it might be impossible without architecture changes
> in the chips to allow bounds checking the stack pointer in hardware
> (which certainly wouldn't fix any existing systems :-).
I think the kernel fix was the first solution suggestion in the
exploit
report - expand the guard page to 1 MB in size from 4 KB. I hope they
don't do this (at least permanently). My understanding of this is
flawed, but my research about this found that every process has its
own
instance of the two pieces that go into this exploit. If every
vulnerable process that runs needs 1 MB of empty guard, that can get
pretty expensive in terms of memory if there are lots of processes
running. And more swapping in and out, etc. The report said that if
the stack-check was implemented, even a 4kB guard page was enough.
It's not allocated memory. It's a Page Table Entry in the Kernel that
ensures that no actual memory is mapped there and that the region is
thus unreadable and unwritable. This is not unlike a swapped-out page,
except the Kernel Page Table Entry for such a page says that it can be
swapped back in and from what (memory-mapped) file. So all it uses is
address space and Page Table Entries.
--
____________________________________________________________________
TonyN.:' <mailto:tonynelson@xxxxxxxxxxxxxxxxx>
' <http://www.georgeanelson.com/>
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
