Messages in this thread | | | From | Dmitry Vyukov <> | Date | Wed, 11 Mar 2020 11:46:10 +0100 | Subject | Re: [PATCH] UML: add support for KASAN under x86_64 |
| |
On Wed, Mar 11, 2020 at 11:32 AM Johannes Berg <johannes@sipsolutions.net> wrote: > > Hi, > > > Hi all, I just want to bump this so we can get all the comments while > > this is still fresh in everyone's minds. I would love if some UML > > maintainers could give their thoughts! > > I'm not the maintainer, and I don't know where Richard is, but I just > tried with the test_kasan.ko module, and that seems to work. Did you > test that too? I was surprised to see this because you said you didn't > test modules, but surely this would've been the easiest way? > > Anyway, as expected, stack (and of course alloca) OOB access is not > detected right now, but otherwise it seems great. > > Here's the log: > https://p.sipsolutions.net/ca9b4157776110fe.txt > > I'll repost my module init thing as a proper patch then, I guess. > > > I do see issues with modules though, e.g. > https://p.sipsolutions.net/1a2df5f65d885937.txt > > where we seem to get some real confusion when lockdep is storing the > stack trace?? > > And https://p.sipsolutions.net/9a97e8f68d8d24b7.txt, where something > convinces ASAN that an address is a user address (it might even be > right?) and it disallows kernel access to it?
Please pass these reports via scripts/decode_stacktrace.sh to add line numbers (or any other symbolization script). What is the base revision? Hard to analyze without line numbers.
> Also, do you have any intention to work on the stack later? For me, > enabling that doesn't even report any issues, it just hangs at 'boot'. > > johannes >
| |