On Thu, Oct 03, 2013 at 11:03:07AM -0700, Kees Cook wrote: > > When you start a port to a 512-bit architecture, you'll have much nastier > > problems than this one... > > Well, this is simply taking advantage of this particular allocator's > behavior. Instead of depending on this side-effect, why not change the > allocation so that we never risk a potentially broken read? (Even SLOB > notes that it may have as low as 2-byte granularity.) Oh, for fuck sake! "Hardening", indeed... Kees, try to think for a minute[1]. Really. We have general-purpose allocator. Asked to give us something considerably bigger than one word. How do you call a situation when it returns something with the end of requested object crossing the page boundary if rounded up to nearest multiple of word size? That's right, FUBAR. Because for that to happen it would have to have given you an address that would not be word-aligned. In response to request to allocate something wider than a word. Remember the words along the lines of "the pointer returned if the allocation succeeds is properly aligned..."? It's not a behaviour of this particular allocator. It's something that will have to be guaranteed by *any* general-purpose allocator. [1] yes, yes, I know - the mere mention of security should've prevented such arrogant requests. It's an imperfect universe. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
