On Fri, May 13, 2022 at 01:07:43PM +0200, Alexander Potapenko wrote: > On Thu, May 12, 2022 at 11:51 PM Dave Hansen <dave.hansen@xxxxxxxxx> wrote: > > > > On 5/12/22 12:39, Thomas Gleixner wrote: > > >> It's OK for a debugging build that runs on one kind of hardware. But, > > >> if we want LAM-using binaries to be portable, we have to do something > > >> different. > > >> > > >> One of the stated reasons for adding LAM hardware is that folks want to > > >> use sanitizers outside of debugging environments. To me, that means > > >> that LAM is something that the same binary might run with or without. > > > On/off yes, but is there an actual use case where such a mechanism would > > > at start time dynamically chose the number of bits? > > > > I'd love to hear from folks doing the userspace side of this. Will > > userspace be saying: "Give me all the bits you can!". Or, will it > > really just be looking for 6 bits only, and it doesn't care whether it > > gets 6 or 15, it will use only 6? > > (speaking more or less on behalf of the userspace folks here) > I think it is safe to assume that in the upcoming year or two HWASan > will be fine having just 6 bits for the tags on x86 machines. > We are interested in running it on kernels with and without > CONFIG_X86_5LEVEL=y, so U48 is not an option in some cases anyway. Just to be clear: LAM_U48 works on machine with 5-level paging enabled as long as the process doesn't map anything above 47-bit. -- Kirill A. Shutemov
