> Pools are generally (thought) safe from use after free bugs because > the poison renders the object useless. Unfortunately, in some cases > pool will very quickly recycle an object, meaning the newly allocated > object may be reinitialzed and then appear sensible to the code > holding on to the "old" pointer. > > pool allocations are deterministic, which we'd prefer to avoid.
Outside our group, it is the battle between "hardware caches are deterministic, and then things are fast" and "deterministic addresses are easier to attack in exploit code". Guess what choice is always made. > Any deterministic pattern is bad, but some are worse. In particular, when > the first object from a page is returned, that page is immediately > made the curpage, meaning we bounce the same object in and out many > times over a series of allocations. Yup. Especially from the same subsystem to the same subsystem. We are actually not catching read after free's for situations where the 0 and 1 bits match the 0xdeadbeef bits. > 1. Swizzle the curpage from time to time. We don't crawl too far into > the lists, but allocating from the front two pages introduces a little > variety into the process. > > 2. Don't force LIFO semantics on the first object back for a page. I like it. Randomization has gotten cheaper. I want to remind that this "fast recycle" policy was put in place back in Sweden. It wasn't added because of the performance benefits. We were hunting a slow-reuse bug. It was quickly fixed. Then I think it became natural to believe that fast-recycle would find bugs better... maybe this is false... I like where you are going with this..
