From: Alexander Potapenko > Sent: 13 May 2022 13:26 > > On Fri, May 13, 2022 at 1:28 PM David Laight <David.Laight@xxxxxxxxxx> wrote: > > > > ... > > > Once we have the possibility to store tags in the pointers, we don't > > > need redzones for heap/stack objects anymore, which saves quite a bit > > > of memory. > > > > You still need redzones. > > The high bits are ignored for actual memory accesses. > > > > To do otherwise you'd need the high bits to be in the PTE, > > copied to the TLB and finally get into the cache tag. > > > > Then you'd have to use the correct tags for each page. > > Sorry, I don't understand how this is relevant to HWASan in the userspace. > Like in ASan, we have a custom allocator that assigns tags to heap > objects. The assigned tag is stored in both the shadow memory for the > object and the pointer returned by the allocator. > Instrumentation inserted by the compiler checks the pointer before > every memory access and ensures that its tag matches the tag of the > object in the shadow memory. Doesn't that add so much overhead that the system runs like a sick pig? I don't see any point adding overhead to a generic kernel to support such operation. > A tag mismatch is reported as an out-of-bounds or a use-after-free, > depending on whether the accessed memory is still considered > allocated. > Because objects with different tags follow each other, there is no > need to add extra redzones to the objects to detect buffer overflows. > (We might need to increase the object alignment though, but that's a > different story). How does all that help if a system call (eg read()) is given an invalid length. If that length is checked then the 'unmasked' address can be passed to the kernel. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
