On Mon, Mar 16, 2020 at 10:55 AM Joel Sherrill <j...@rtems.org> wrote: > > > > On Mon, Mar 16, 2020 at 11:05 AM Sebastian Huber > <sebastian.hu...@embedded-brains.de> wrote: >> >> On 15/03/2020 17:52, suyash singh wrote: >> >> Hello, >> Out of >> AddressSanitizer, ThreadSanitizer, MemorySanitizer, and DataFlowSanitizer. >> >> Are all of them useful as RTEMS-tools to integrate? Any other sanitizers >> suggested? >> >> Asking as part of my proposed gsoc project, >> https://docs.google.com/document/d/1OerM8Iix7PbDUCyb_J_KEzcMgLbvdqxd4FnK_BqI7XI/edit?usp=sharing >> >> I am not sure of these sanitizers can be used in RTEMS at all. We don't have >> virtual memory. Firstly, it would be necessary to check for each sanitizer >> if it uses virtual memory. If yes, then is this absolutely necessary or just >> convenient? Also the sanitizers are not available on all LLVM architectures. >> We have to evaluate if the architectures-specific adoptions can be used in >> RTEMS. > > > +1 > > Another area is the compiler stack protection techniques. I have no idea if > those are applicable to RTEMS but they would be useful if they can work. > > Ignoring other constraints from embedded systems, any possible technique to > use with RTEMS must be evaluated against the constraints imposed by having a > single address space, no VM, and single process model. > > You need to check if any of these will work before this project has a chance. > > I would be willing to entertain a project for an appropriate solution that is > limited to say ARM, x86, and RISC-V. > +1
UBSan is a good candidate. > --joel > >> >> _______________________________________________ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
