2014-05-26 19:57 GMT+04:00 'Dmitry Vyukov' via address-sanitizer <[email protected]>: > On Mon, May 26, 2014 at 7:36 PM, Andrey Ryabinin <[email protected]> > wrote: >> 2014-05-26 14:51 GMT+04:00 'Dmitry Vyukov' via address-sanitizer >> <[email protected]>: >>> >>> Regarding kernel, we need to put together a TODO list -- there is lots of >>> work. >>> Do you able to build kernel with asan and boot it? Just verifying it >>> and pointing any weak places in our docs would be a good start. >>> Thanks! >>> >> >> Actually I advanced much further than just building and booting. I did >> some work on the basis of existing >> implementation from https://github.com/xairy/linux. First of all I >> removed all x86 specific hacks, so it's >> cross-platform now (currently I'm running sanitized kernel on ARM board). >> Also added SLUB and buddy allocator support. >> There are some other minor improvements, like proper integration with >> kbuild instead of nasty gcc.py script... > > Whoa! > We want this! > > >> Since we are all working on the same thing, I would be cool to avoid >> extra efforts and start to work together. >> I assume that you want kasan to be a part of mainline Linux kernel, as >> do I. So design & implementation >> should be discussed with Linux kernel community. >> What do you think if I will send our work to Linux kernel mail list, >> and we will discuss it and any further step >> together with Linux community? > > We absolutely want to discuss it with the community and make it part > of mainline kernel. > > Were you able to find some bugs? Bug count is usually a strong > argument in favor of a tool. >
I didn't found any bugs yet, but didn't test much. Though, I found one interesting bug in put_user, because of kasan compiler puts functions calls almost everywhere. It was there for a very long time - http://thread.gmane.org/gmane.linux.kernel/1696488 Testing of linux-next tree in my near plans. > What exactly do you want to write? We need to coordinate. > I propose to sent RFC patch set and find out how much community like this feature. Here is my plan: 1. Sent kasan patches for slub/buddy allocator. I don't want to keep slab support for several reasons - I don't like how it's implemented now. - slub support is much simpler to implement, so it will be easier to review and increase chances for positive feedback - usually linux kernel guys don't like big patch sets, so it would be better to split. 2. If we get positive feedback and after mainline gcc will support outline instrumentation - send updated patchset. According to reviewers feedback we may need to perform several iterations to fix all issuse before merging to mainline. 3. After basic support will be merged we may proceed further with slab support and other things, that comes to mind. > -- > You received this message because you are subscribed to the Google Groups > "address-sanitizer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- Best regards, Andrew Ryabinin -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
