This is where we’ll be storing our checksum. 1” added one byte at the end of this section. In our example we’ll call this section “.data_safram”: data_safram.ld – Linker script – define custom memory section imagine other process changing the memory just after the checksum is checked) and no mechanism would detect that (actually we would even store a new checksum at the end of the run calculated over wrong data and keep going).īut let’s back up a little – the first step is to define the memory section in a linker script. So if this were running on a bare-metal with simple preemptive scheduling then no spatial freedom of interference would be achieved as any other process could alter the memory during execution of safety critical section (e.g. Printf("testarray=%u, checksum=%u\n", testarray, crc) Īlso please note that the stack (or any other memory section besides “.data_safram” in fact) is not protected. Void periodic_task(char **argv, uint8_t count) This section is represented by this function: th_safram_crc.c – Safety critical section There is however one important assumption here: no preemption can happen in the safety critical section of the code and no other code can execute in parallel (single core CPU). This shall allow us to detect any intrusions and reset the process in case the memory corruption happens. This example has a particular goal of protecting a dedicated memory section of a process with a checksum. All the source code shown here (and more) can be found on GitHub here. Often we cannot stop this from happening but we can at least ensure detecting it in timely manner and take corrective actions.īut without further ado let’s go through the example. In all environments it shall be assumed that any other process with lower ASIL (or QM) than desired integrity level of your component can (and will) execute wrongly and will (if it has a chance) change your memory. This will be illustrated on an example for Linux operating system but essentially (as you will see later) it is more suitable for more bare-metal applications. memory protection mechanisms implemented in operating system, base software or hardware layerĪs said, this post is mainly about (1) – protecting a given memory section of a process with checksum.protecting each variable by dual storage of its complement.protecting a memory region with a checksum.And as the title suggests here we’ll deal in detail only with one particular hardware independent mechanism of memory protection.īut in general there are several more mechanisms one can think of when it comes to spatial freedom of interference: There are in general 3 types of of interference: spatial (memory), temporal (scheduling) and communication (corruption of input and output data). In another words how to ensure that safety critical component runs as designed without giving a chance to others (less critical component) to impact the execution. The Part 6 of ISO26262 defines the freedom from interference as absence of cascading failures between software components. How much limited depends on the integrity level where ASIL D is the highest integrity. But the probability of this happening is limited. It can (and will) go nuts and start writing to your memory or halt the CPU. If you are care mainly about software then Part 6 of this standard is the most important. This gives you some guidance what you shall be doing to make safety critical software.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |