Re: [PATCH v2 13/14] x86: runtime_const used for KASAN_SHADOW_END

On 2025-02-26 at 16:24:28 +0100, Andrey Konovalov wrote:

On Wed, Feb 26, 2025 at 12:53 PM Maciej Wieczor-Retman
[off-list ref] wrote:

quoted

After adding
        kasan_params += hwasan-instrument-with-calls=0
to Makefile.kasan just under
        kasan_params += hwasan-mapping-offset=$(KASAN_SHADOW_OFFSET)
inline works properly in x86. I looked into assembly and before there were just
calls to __hwasan_load/store. After adding the the
hwasan-instrument-with-calls=0 I can see no calls and the KASAN offset is now
inlined, plus all functions that were previously instrumented now have the
kasan_check_range inlined in them.

My LLVM investigation lead me to
        bool shouldInstrumentWithCalls(const Triple &TargetTriple) {
          return optOr(ClInstrumentWithCalls, TargetTriple.getArch() == Triple::x86_64);
        }
which I assume defaults to "1" on x86? So even with inline mode it doesn't care
and still does an outline version.

Ah, indeed. Weird discrepancy between x86 and arm.

Florian, Vitaly, do you recall why this was implemented like this?

To account for this, let's then set hwasan-instrument-with-calls=0
when CONFIG_KASAN_INLINE is enabled. And also please add a comment
explaining why this is done.

Sure, will do :)

[...]

quoted

quoted

What do you mean by "The alignment doesn't fit the shadow memory size"?

Maybe that's the wrong way to put it. I meant that KASAN_SHADOW_END and
KASAN_SHADOW_END aren't aligned to the size of shadow memory.

I see. And the negative side-effect of this would be that we'll need
extra page table entries to describe the shadow region?

I think so, yes. But I guess it's not a big issue, and anyway right now I'm not
sure how to change it so other necessary parts don't break :b

[...]

quoted

I think this was a false alarm, sorry. I asked Kirill about turning
pgtable_l5_enabled() into a runtime_const value but it turns out it's already
patched by alternative code during boot. I just saw a bunch more stuff there
because I was looking at the assembly output and the code isn't patched there
yet.

Great!

-- 
Kind regards
Maciej Wieczór-Retman