Messages in this thread | | | Subject | Re: [RFC PATCH v3] UML: add support for KASAN under x86_64 | From | Johannes Berg <> | Date | Fri, 27 May 2022 09:32:03 +0200 |
| |
On Fri, 2022-05-27 at 07:31 +0200, Dmitry Vyukov wrote: > > - This doesn't seem to work when CONFIG_STATIC_LINK is enabled (because > > libc crt0 code calls memory functions, which expect the shadow memory > > to already exist, due to multiple symbols being resolved. > > - I think we should just make this depend on dynamic UML. > > - For that matter, I think static UML is actually broken at the > > moment. I'll send a patch out tomorrow. > > I don't know how important the static build is for UML.
Depends who you ask, I guess.
IMHO just making KASAN depend on !STATIC_LINK is fine, until somebody actually wants to do what you describe:
> Generally I prefer to build things statically b/c e.g. if a testing > system builds on one machine but runs tests on another, dynamic link > may be a problem. Or, say, if a testing system provides binary > artifacts, and then nobody can run it locally. > > One potential way to fix it is to require outline KASAN > instrumentation for static build and then make kasan_arch_is_ready() > return false until the shadow is mapped. I see kasan_arch_is_ready() > is checked at the beginning of all KASAN runtime entry points. > But it would be nice if the dynamic build also supports inline and > does not add kasan_arch_is_ready() check overhead.
which sounds fine too, but ... trade-offs.
> > + if (IS_ENABLED(CONFIG_UML)) { > > + __memset(kasan_mem_to_shadow((void *)addr), KASAN_VMALLOC_INVALID, shadow_end - shadow_start); > > "kasan_mem_to_shadow((void *)addr)" can be replaced with shadow_start.
and then the memset line isn't so long anymore :)
> > > > + return 0; > > + } > > + > > + shadow_start = ALIGN_DOWN(shadow_start, PAGE_SIZE); > > shadow_end = ALIGN(shadow_end, PAGE_SIZE); > > There is no new fancy PAGE_ALIGN macro for this. And I've seen people
s/no/now the/ I guess, but it's also existing code.
johannes
| |