え、藤井七段ってAMDerなの

【 #Togetter 注目のまとめ #RSSfeed 】
藤井七段、AMDのCPUに言及
https://togetter.com/li/1293954

Why does #OpenBSD's #malloc do so much randomization? 1) to catch bugs. If you memory layout differs each run, bugs that would otherwise be hidden are exposed. 2) it makes lives of attackers harder. They cannot rely on certain allocations always to be next to each other.

A common bug is to leave sensitive mem uncleared and reuse memory (e.g. via #malloc’s cache) without proper initialisation, leading to secret leakage. The purpose of freezero() and recallocarray() is to protect against that threat. Big threat to the application is the application.

#malloc is a general purpose allocator. If you know more about your typical memory usage, you can probably write a faster special purpose allocator. But wait with writing your own until you have evidence that malloc is the bottleneck, remember the features of #OpenBSD's malloc.

Sensitive data? memset(p, 0, sz); free(p); does not do want you think it does. The compiler is allowed to optimise the memset away. Use freezero(p, sz). For large allocations #OpenBSD just unmaps the pages, avoiding the clearing and still making the memory inaccessible.

A lot of malloc implementations hold on to memory pages received from the kernel. #openbsd's #malloc is reasonably aggressive with unmapping pages that are unused, catching use-after-free bugs with segmentation violations.

#openbsd's #malloc stores meta-data separated from the memory returned to the caller, making it harder to use heap overflows to achieve code injection and execution. See e.g. http://www.mathyvanhoef.com/2013/02/understanding-heap-exploiting-heap.html … and references. Having malloc meta-data near program data is dangerous!

平均して一巻辺り三冊分だとして30巻

あの厚さで10巻...？

少なくともまだ10巻は読めるのか