On 03/02/18 22:12, Boris Lukashev wrote: > Regarding the notion of validated protected memory, is there a method > by which the resulting checksum could be used in a lookup > table/function to resolve the location of the protected data? What I have in mind is a checksum at page/vmap_area level, so there would be no 1:1 mapping between a specific allocation and the checksum. An extreme case would be the one where an allocation crosses one or more page boundaries, while the checksum refers to a (partially) overlapping memory area. Code accessing a pool could perform one (relatively expensive) validation. But still something that would require a more sophisticated attack, to subvert. > Effectively a hash table of protected allocations, with a benefit of > dedup since any data matching the same key would be the same data > (multiple identical cred structs being pushed around). Should leave > the resolver address/csum in recent memory to check against, right? I see where you are trying to land, but I do not see how it would work without a further intermediate step. pmalloc dishes out virtual memory addresses, when called. It doesn't know what the user of the allocation will put in it. The user, otoh, has the direct address of the memory it got. What you are suggesting, if I have understood it correctly, is that, when the pool is protected, the addresses already given out, will become traps that get resolved through a lookup table that is built based on the content of each allocation. That seems to generate a lot of overhead, not to mention the fact that it might not play very well with the MMU. If I misunderstood, then I'd need a step by step description of what happens, because it's not clear to me how else the data would be accessed if not through the address that was obtained when pmalloc was invoked. -- igor -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
