What sanitizers preferred?

suyash singh suyashsingh234 at gmail.com
Wed Mar 18 05:50:44 UTC 2020


AddressSanitizer is supported on  Android ARM
ThreadSanitizer supported on x86_64
Memory sanitizer and UBsan not on the ones you mentioned but on freeBSD
DataFlowSanitizer is under development for x86_64 Linux

But they use virtual memory.


On Mon, Mar 16, 2020 at 10:25 PM Joel Sherrill <joel at rtems.org> wrote:

>
>
> On Mon, Mar 16, 2020 at 11:05 AM Sebastian Huber <
> sebastian.huber at embedded-brains.de> wrote:
>
>> On 15/03/2020 17:52, suyash singh wrote:
>>
>> Hello,
>> Out of
>> AddressSanitizer <http://clang.llvm.org/docs/AddressSanitizer.html>,
>> ThreadSanitizer <http://clang.llvm.org/docs/ThreadSanitizer.html>,
>> MemorySanitizer <http://clang.llvm.org/docs/MemorySanitizer.html>, and
>> DataFlowSanitizer <http://clang.llvm.org/docs/DataFlowSanitizer.html>.
>>
>> 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.
>
> --joel
>
>
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200318/73699814/attachment.html>


More information about the devel mailing list