On Sat, 2011-03-05 at 00:14 +0200, Pekka Enberg wrote: > On Sat, Mar 5, 2011 at 12:10 AM, Pekka Enberg <penberg@xxxxxxxxxx> wrote: > > I can think of four things that will make things harder for the > > attacker (in the order of least theoretical performance impact): > > > > (1) disable slub merging > > > > (2) pin down random objects in the slab during setup (i.e. don't > > allow them to be allocated) > > > > (3) randomize the initial freelist > > > > (4) randomize padding between objects in a slab > > > > AFAICT, all of them will make brute force attacks using the kernel > > heap as an attack vector harder but won't prevent them. > > There's also a fifth one: > > (5) randomize slab page allocation order > > which will make it harder to make sure you have full control over a > slab and figure out which allocation lands on it. I think the real issue here is that it's too easy to write code that copies too many bytes from userspace. Every piece of code writes its own bound checks on copy_from_user, for instance, and gets it wrong by hitting signed/unsigned issues, alignment issues, etc. that are on the very edge of the average C coder's awareness. We need functions that are hard to abuse and coding patterns that are easy to copy, easy to review, and take the tricky bits out of the hands of driver writers. I'm not really sure what that looks like yet, but a copy that does its own bounds-checking seems like a start: copy_from_user(dst, src, n, limit) # warning when limit is hit copy_from_user_nw(dst, src, n, limit) # no warning version -- Mathematics is the supreme nostalgia of our time. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>