On Wed, Mar 7, 2018 at 1:48 PM, <jinb.pa...@gmail.com> wrote: > >> >> > :: for user-space binary It is similar to memcheck of valgrind. >> >> How will it be different from memcheck? ASAN is already similar to >> memcheck, just faster. So why not just use ASAN? > > I have to do investigate more to answer this question...
It's kind of an important question. >> > Perform the wrong shift. ==> I think It can be a improvement point. ==> >> > exit process at this point by various ways. It can be helpful to block a >> > chance to exploit. >> >> I think there is already an option for this. All sanitizers are >> capable of terminating the process on first bug. > > > Yap, I found it. -fno-sanitize-recover may be what you said. There also must be a runtime flag. >> > :: for loadable kernel module AFAIK, Runtime-sanitization hasn't tried >> > yet on LKM. (right??) >> >> KASAN can perfectly work on kernel modules, if they are instrumented. >> Potentially one could instrument only a single module (but not kernel >> code code) and enable KASAN runtime. >> The same can be achieved with runtime binary instrumentation too, but >> will be much more complex. Is it what you mean? > > > Yes, I mean runtime binary instrumentation. Is it already implemented in > KASAN?? > I agree with your opinion that is more complex. > So, I wonder what you think whether it is needed or not. I can only say that we are not doing it because (1) it's too complex, (2) you can't protect something for which you don't have source code anyway (consider that the code is not doing what it's claiming to be doing but instead sends all information about your credit cards to internet without any heap corruptions). > Use-case what I consider,, > When a user want to run untrusted app or LKM, > runtime sanitization can add mitigation for the case, without isolation > technique. > (But I'm not sure It's really needed.) Well, if it's untrusted and you don't have source code then you can't protect it (or from it), see above. > (* one more question *) > If linux kernel is built with KASAN, UBSAN, ... > Can kernel-module be built with those sanitizer?? without any additional > effort of user?? Yes. This is happening by default. >> > :: How to minimize instrumentation?? Only Functions influenced by user >> > input can be instrumented. In the case of kernel driver, It is not >> > difficult >> > to extract function list to be instrmented. >> >> How do you want o extract this list of functions? Or you mean that >> user supplies the list? > > > For linux kernel, > 1) Select system call function, exported kernel function as starter. > 2) Do taint-analysis or measuring-coverage from the starter. > I think these kind of techniques can be leveraged to extract list of > functions. > 3) Exclude functions that are not selected of 1), 2). (I don't know yet > how this can be implemented.. Can it be implemented by gcc-plugin??) > ==> Output : Minimal sanitized linux kernel. Can this kernel be > suitable for product environment?? I don't know yet.. > > For kernel driver, > 1) Extract common condition of starter function of kernel driver. > --> Starter function is generally be connected with function pointer. > e.g) struct file_operations->ioctl() ==> kernel_driver_ioctl() > --> I have to find more condition.. > 2), 3) are same to "For linux kernel" > ==> Output : Minimal sanitized kernel driver. > > ** User-supplied list can be an easiest way as I think. This looks too complex to be practical. -- 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 address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
