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

Reply via email to