On 2025-02-21 at 16:10:54 +0100, Maciej Wieczor-Retman wrote: >On 2025-02-20 at 00:31:08 +0100, Andrey Konovalov wrote: >>On Tue, Feb 18, 2025 at 9:20 AM Maciej Wieczor-Retman >><maciej.wieczor-retman@xxxxxxxxx> wrote: >>> >>> On x86, generic KASAN is setup in a way that needs a single >>> KASAN_SHADOW_OFFSET value for both 4 and 5 level paging. It's required >>> to facilitate boot time switching and it's a compiler ABI so it can't be >>> changed during runtime. >>> >>> Software tag-based mode doesn't tie shadow start and end to any linear >>> addresses as part of the compiler ABI so it can be changed during >>> runtime. >> >>KASAN_SHADOW_OFFSET is passed to the compiler via >>hwasan-mapping-offset, see scripts/Makefile.kasan (for the INLINE >>mode). So while we can change its value, it has to be known at compile >>time. So I don't think using a runtime constant would work. > >I don't know about arm64, but this doesn't seem to work right now on x86. I >think I recall that hwasan-mapping-offset isn't implemented on the x86 LLVM or >something like that? I'm sure I saw some note about it a while ago on the >internet but I couldn't find it today. > >Anyway if KASAN_SHADOW_OFFSET is not set at compile time it defaults to nothing >and just doesn't get passed into kasan-params a few lines below. I assume that >result seems a little too makeshift for runtime const to make sense here? > >> >>Which means that KASAN_SHADOW_OFFSET has to have such a value that >>works for both 4 and 5 level page tables. This possibly means we might >>need something different than the first patch in this series. > >I'll think again about doing one offset for both paging levels so that it's as >optimal as possible. > Also I was wondering if you know what "hwasan-mapping-offset-dynamic" option is? I noticed it in the llvm docs but can't find a good description what it does, even from looking at the code in HWAddressSanitizer.cpp. If hwasan-mapping-offset is not implemeneted for x86 I doubt this is but maybe it could help in a cleaner makefile for x86 at least? Especially once these options will be working in x86 llvm. -- Kind regards Maciej Wieczór-Retman
