On Thu, Dec 4, 2014 at 5:16 PM, Yury Gribov <y.gri...@samsung.com> wrote: > On 12/04/2014 05:04 PM, Dmitry Vyukov wrote: >> >> On Thu, Dec 4, 2014 at 4:48 PM, Yury Gribov <y.gri...@samsung.com> wrote: >>> >>> On 12/04/2014 03:47 PM, Dmitry Vyukov wrote: >>>> >>>> >>>> size_in_bytes = -1 instrumentation is too slow to be the default in >>>> kernel. >>>> >>>> If we want to pursue this, I propose a different scheme. >>>> Handle 8+ byte accesses as 1/2/4 accesses. No changes to 1/2/4 access >>>> handling. >>>> Currently when we allocate, say, 17-byte object we store 0 0 1 into >>>> shadow. An 8-byte access starting at offset 15 won't be detected, >>>> because the corresponding shadow value is 0. Instead we start storing >>>> 0 9 1 into shadow. Then the first shadow != 0 check will fail, and the >>>> precise size check will catch the OOB access. >>>> Make this scheme the default for kernel (no additional flags). >>>> >>>> This scheme has the following advantages: >>>> - load shadow only once (as opposed to the current size_in_bytes = -1 >>>> check that loads shadow twice) >>>> - less code in instrumentation >>>> - accesses to beginning and middle of the object are not slowed down >>>> (shadow still contains 0, so fast-path works); only accesses to the >>>> very last bytes of the object are penalized. >>> >>> >>> >>> Makes sense. The scheme actually looks bullet-proof, why Asan team >>> preferred current (fast but imprecise) algorithm? >>> >>> BTW I think we'll want this option in userspace so well so we'll probably >>> need to update libasan. >> >> >> We've discussed this scheme, but nobody has shown that it's important >> enough. >> It bloats binary (we do have issues with binary sizes) and slows down >> execution a bit. And if it is non-default mode, then it adds more >> flags (which is bad) and adds more configurations to test. >> >> For this to happen somebody needs to do research on (1) binary size >> increase, (2) slowdown, (3) number of additional bugs it finds (we can >> run it over extensive code base that is currently asan-clean). > > > Regarding (3) - unless a codebase deliberately uses unaligned accesses (like > kernel) this change would be of little use - all unaligned accesses are then > bugs and should already be detected and fixed with UBSan.
You answered your own question about user space :)