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. The original kernel fix had a bug, so there is a fix for the fix being compiled now. > > Laura on the kernel list: > > > The stack-clash fix was found to have a bug so I revoked the > > > updates. > > > New builds with a fix for the fix will be filed in bodhi when > > > finished. > So maybe the proper solution is to static link all the setuid > binaries, and not drag everything else on the system down? I think the trend is the other direction. I've seen discussions about whether all static libraries could be removed from Fedora. I suppose people will have to decide that based on what they are using the system for. Which is better for their use case? I'm wondering, in my ignorance, if a different way of organizing the stack and heap could be introduced, so they aren't vulnerable to this. I'm sure the experts have been considering this since the issue has been around for over 10 years. Might even be computer science courses taught about this, and speculation over wine and cheese. :-) They must have looked at alternative approaches and come up empty. If they have, then Windows and Mac will be vulnerable to this as well, since they can't do things any differently. _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
