Messages in this thread | | | From | Patricia Alfonso <> | Date | Thu, 13 Feb 2020 16:54:41 -0800 | Subject | Re: [RFC PATCH v2] UML: add support for KASAN under x86_64 |
| |
> Well I had two patches: > (1) the module constructors one - I guess we need to test it, but you > can include it here if you like. I'm kinda swamped with other > things right now, no promises I can actually test it soon, though I > really do want to because that's the case I need :) > (2) the [DEMO] patch - you should just take the few lines you need from > that (in the linker script) and stick it into this patch. Don't > even credit me for that, I only wrote it as a patch instead of a > normal text email reply because I couldn't figure out how to word > things in an understandable way... > > Then we end up with 2 patches again, the (1) and your KASAN one. There's > no point in keeping the [DEMO] separate, and > Okay, so I'll rebase onto (1) and just add the lines I need from the [DEMO]. Are you sure you don't want to be named as a co-developed-by at least?
> > > > > + if (mmap(start, > > > > + len, > > > > + PROT_READ|PROT_WRITE, > > > > + MAP_FIXED|MAP_ANONYMOUS|MAP_PRIVATE|MAP_NORESERVE, > > > > + -1, > > > > + 0) == MAP_FAILED) > > > > + os_info("Couldn't allocate shadow memory %s", strerror(errno)); > > > > > > If that fails, can we even continue? > > > > > Probably not, but with this executing before main(), what is the best > > way to have an error occur? Or maybe there's a way we can just > > continue without KASAN enabled and print to the console that KASAN > > failed to initialize? > > You can always "exit(17)" or something. > > I'm not sure you can continue without KASAN? > > Arguably it's better to fail loudly anyway if something as simple as the > mmap() here fails - after all, that probably means the KASAN offset in > Kconfig needs to be adjusted? > > johannes > Yeah, failing loudly does seem to be the best option here.
-- Patricia Alfonso
| |