lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 13 May 2022 14:26:53 +0000 From: David Laight <David.Laight@...LAB.COM> To: 'Alexander Potapenko' <glider@...gle.com> CC: Dave Hansen <dave.hansen@...el.com>, Thomas Gleixner <tglx@...utronix.de>, Peter Zijlstra <peterz@...radead.org>, "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>, Dave Hansen <dave.hansen@...ux.intel.com>, Andy Lutomirski <luto@...nel.org>, the arch/x86 maintainers <x86@...nel.org>, Dmitry Vyukov <dvyukov@...gle.com>, "H . J . Lu" <hjl.tools@...il.com>, "Andi Kleen" <ak@...ux.intel.com>, Rick Edgecombe <rick.p.edgecombe@...el.com>, Linux Memory Management List <linux-mm@...ck.org>, LKML <linux-kernel@...r.kernel.org> Subject: RE: [RFCv2 00/10] Linear Address Masking enabling From: Alexander Potapenko > Sent: 13 May 2022 13:26 > > On Fri, May 13, 2022 at 1:28 PM David Laight <David.Laight@...lab.com> 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)
Powered by blists - more mailing lists