Is this method applicable to Linux operating system?

[GIN-zhao]

I now need to migrate your methods to Linux. I am not sure whether they are compatible, and I don't see any reinforcement methods for FreeRTOS in the source code. Is it reasonable and feasible for me to do so?

[davidebaroffio-polimi]

Hi @GIN-zhao

If I understood correctly, you want to protect the Linux kernel with ASPIS.
The protection of the Linux kernel with ASPIS, although possible, might be not trivial.

Concerning what you can actually do.
The only thing we did for supporting FreeRTOS is to add some source-level annotations in its kernel (“exclude” and “to duplicate”), you can find further details in our article:
https://dl.acm.org/doi/10.1145/3660524

If I were you, I would start by compiling some smaller kernel modules and try to make it work. The main concern you should have is how to manage these annotations so ensure consistency in the module whilst not extending the duplication to other modules, which may broaden the scope too much and render your task unmanageable.

If you have any problems or find some bugs please contact me, I would be more than happy to help.

[GIN-zhao]

Hi @GIN-zhao

If I understood correctly, you want to protect the Linux kernel with ASPIS. The protection of the Linux kernel with ASPIS, although possible, might be not trivial.

Concerning what you can actually do. The only thing we did for supporting FreeRTOS is to add some source-level annotations in its kernel (“exclude” and “to duplicate”), you can find further details in our article: https://dl.acm.org/doi/10.1145/3660524

If I were you, I would start by compiling some smaller kernel modules and try to make it work. The main concern you should have is how to manage these annotations so ensure consistency in the module whilst not extending the duplication to other modules, which may broaden the scope too much and render your task unmanageable.

If you have any problems or find some bugs please contact me, I would be more than happy to help.

Thank you for your response. I have a few more questions.
1. We conducted radiation experiments on the device under test running Linux, exposing only the CPU. The main issues observed were single-event upsets (SEUs) causing stack return address anomalies or page table mapping errors. We suspect that this is due to cache flips within the CPU. We are exploring whether software-based protection could mitigate the impact of SEUs on the CPU. We have tried compiler hardening techniques such as COAST, as mentioned in your paper. However, during compilation, we found that COAST cannot be applied directly to certain modules, such as Linux's mm memory management module. This is partly due to COAST's variable restrictions, and partly because the compiled modules prevent linking into a complete kernel. I haven't used ASPIS yet, so I'm unsure if it faces similar limitations. Additionally, the kernel involves sections of assembly language, which cannot likely be protected. Our aim is to implement safeguards for the cache component. What other suitable methods would you suggest?
2. I noticed some errors in your FreeRTOS implementation. Since FreeRTOS occupies a relatively small memory space, I assume you performed bit flip injection by directly traversing the entire memory? Linux has a much larger memory footprint, and I haven't found any suitable bit flip injection tools for it. Do you have any insights?

[GIN-zhao]

Thank you for your response. I have a few more questions. 1. We conducted radiation experiments on the device under test running Linux, exposing only the CPU. The main issues observed were single-event upsets (SEUs) causing stack return address anomalies or page table mapping errors. We suspect that this is due to cache flips within the CPU. We are exploring whether software-based protection could mitigate the impact of SEUs on the CPU. We have tried compiler hardening techniques such as COAST, as mentioned in your paper. However, during compilation, we found that COAST cannot be applied directly to certain modules, such as Linux's mm memory management module. This is partly due to COAST's variable restrictions, and partly because the compiled modules prevent linking into a complete kernel. I haven't used ASPIS yet, so I'm unsure if it faces similar limitations. Additionally, the kernel involves sections of assembly language, which cannot likely be protected. Our aim is to implement safeguards for the cache component. What other suitable methods would you suggest? 2. I noticed bitflip injector in your FreeRTOS implementation. Since FreeRTOS occupies a relatively small memory space, I assume you performed bit flip injection by directly traversing the entire memory? Linux has a much larger memory footprint, and I haven't found any suitable bit flip injection tools for it. Do you have any insights? 发自我的iPhone

…

------------------ Original ------------------ From: Davide Baroffio ***@***.***> Date: Fri,Oct 3,2025 2:15 PM To: HEAPLab/ASPIS ***@***.***> Cc: GIN-zhao ***@***.***>, Mention ***@***.***> Subject: Re: [HEAPLab/ASPIS] Is this method applicable to Linux operatingsystem? (Issue #13) davidebaroffio-polimi left a comment (HEAPLab/ASPIS#13) Hi @GIN-zhao If I understood correctly, you want to protect the Linux kernel with ASPIS. The protection of the Linux kernel with ASPIS, although possible, might be not trivial. Concerning what you can actually do. The only thing we did for supporting FreeRTOS is to add some source-level annotations in its kernel (“exclude” and “to duplicate”), you can find further details in our article: https://dl.acm.org/doi/10.1145/3660524 If I were you, I would start by compiling some smaller kernel modules and try to make it work. The main concern you should have is how to manage these annotations so ensure consistency in the module whilst not extending the duplication to other modules, which may broaden the scope too much and render your task unmanageable. If you have any problems or find some bugs please contact me, I would be more than happy to help. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[davidebaroffio-polimi]

Hi,

Response 1

Indeed, hardening a module such as the memory management module can be quite tricky. I am not very familiar with the details of the module implementation, yet there is a very clear distinction you have to make to determine what pieces of code you want to duplicate and what not.

Option 1
Applying ASPIS to the entire module can be done, with limitations e.g. in the protection of assembly code, since it cannot be accessed at the LLVM IR level. I am unsure what you mean by "COAST's compiled modules prevent linking into a complex kernel." I assume it has something to do with the module's build system, but ASPIS can emit a binary that can be linked to other modules; just make sure that there are no "dangling" duplicate variables. This means that you have to carefully manage the dependency with other modules, as they are not duplicated, and accessing them could cause inconsistencies during execution.

Option 2
You can selectively protect only some functions/variables.
The key factor for the data protection mechanism of ASPIS (EDDI) is that you want to ensure that both copies of the program deal with unrelated data: no pointer overlap, and if a variable is duplicated, it has to be always updated together with its corresponding original value.

For instance, if I have:

int a, a_dup;

Another file cannot update a (e.g. a++) without also updating its duplicate a_dup. That is because ASPIS would find an inconsistency in a subsequent synchronization point, triggering a data corruption detection.

---

One last point. EDDI provides data protection by design, meaning that many corruptions in the program memory (including register file, main memory, cache) can be detected by default: if you have your duplicated program memory layout, one of which is corrupted due to a SEU, EDDI is able to detect the error as soon as the first check is performed, regardless of where the error occurred.

I am very curious about the nature of the "stack return address anomalies or page table mapping errors" that you mentioned. Is there a reference where I can read more about the behaviour you observed?

Response 2

We were injecting via the debugging interface of the microcontroller we ran FreeRTOS on. If you want to do something similar on Linux, you may add a piece of kernel-space code that flips a random bit in the program at random time, to simulate a single-event effect.

You have to rely on statistical fault injection, by the way. Since the exploration space is too big, you cannot run fault injection on the entire memory at each clock cycle (you could, but it would take you forever ahaha). We also ran statistical fault injection on freertos, so that we can have an estimate of the fault tolerance of our system.

[GIN-zhao]

@davidebaroffio-polimi
Hi,Thank you for your reply.
I'd like to first address the question or point of curiosity (ahaha) you mentioned in your response regarding COAST's inability to compile and link the Linux mm memory management module. It's similar to how we know compiling the Linux kernel using O1 optimization won't succeed because it involves certain code optimizations. For example, consider the following code:
void foo(); int main(){ int a = 1; if(a>2) foo(); }
The code only declares the foo function without defining it. Using O1 optimization will fail compilation. With O2 or O3 optimization levels, the compiler would eliminate the if block's code. This is a simple example, but I imagine the kernel involves more complex optimization issues. COAST likely interferes with these optimizations, leading to compilation failures (e.g., errors like “undefined reference function”).

Additionally, the kernel crash logs caused by SEU are as follows:
1. page table mapping errors
root@debian:~# [ 212.473177] Unhandled fault at 0xffff800010003eb0 [ 212.477948] Mem abort info: [ 212.480813] ESR = 0x96000040 [ 212.483944] EC = 0x25: DABT (current EL), IL = 32 bits [ 212.489326] SET = 0, FnV = 0 [ 212.492447] EA = 0, S1PTW = 0 [ 212.495644] Data abort info: [ 212.498590] ISV = 0, ISS = 0x00000040 [ 212.502494] CM = 0, WnR = 1 [ 212.505551] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000f1758000 [ 212.512328] [ffff800010003eb0] pgd=000000237ffff003, p4d=000000237ffff003, pud=000000237fffe003, pmd=000000237fffd003, pte=0068002000155f03 [ 212.525116] Internal error: ttbr address size fault: 96000040 [#1] SMP [ 212.531699] Modules linked in: rfkill nls_ascii nls_cp437 vfat fat aes_ce_blk crypto_simd cryptd aes_ce_cipher ghash_ce gf128mul libaes ngbe(OE) sha2_ce sha256_arm64 efi_pstore sg evdev sha1_ce sbsa_gwdt ptp pps_core drm fuse configfs efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic sd_mod t10_pi crc_t10dif crct10dif_generic ahci libahci libata scsi_mod crct10dif_ce crct10dif_common [ 212.569585] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G OE 5.10.0-22-arm64 #1 Debian 5.10.178-3 [ 212.579309] Hardware name: PHYTIUM LTD D2000/J351BS, BIOS XTDB-J351B-S_V0.1.0.0 Apr 8 2024 [ 212.587770] pstate: 600003c5 (nZCv DAIF -PAN -UAO -TCO BTYPE=--) [ 212.593869] pc : el1_sync+0x0/0x140 [ 212.597447] lr : el1_irq+0xcc/0x180 [ 212.601000] sp : ffff800010003eb0 [ 212.604385] x29: ffff8000118b3ea0 x28: ffff8000118c3240 [ 212.609844] x27: 0000000000000000 x26: ffff800010004000 [ 212.615306] x25: ffff800010000000 x24: 0000000000000000 [ 212.620755] x23: 0000000060000005 x22: ffff800010c40c88 [ 212.626215] x21: ffff8000118b3ec0 x20: 0000ffffffffffff [ 212.631672] x19: ffff8000118b3d70 x18: 0000000000000000 [ 212.637121] x17: 0000000000000000 x16: 0000000000000000 [ 212.642569] x15: 0000000000000000 x14: 0000000000000000 [ 212.648015] x13: 0000000000000003 x12: 0000000000000003 [ 212.653462] x11: 0000000000000000 x10: 0000000000000b00 [ 212.658916] x9 : ffff800010101ccc x8 : ffff8000118c3da0 [ 212.664371] x7 : 0000000000000497 x6 : 000000029190b76f [ 212.669824] x5 : 00ffffffffffffff x4 : ffff0022edf0f080 [ 212.675279] x3 : 0000000000000000 x2 : 00000000000349ae [ 212.680732] x1 : ffff800010100260 x0 : ffff8000118b3d70 [ 212.686179] Call trace: [ 212.688734] el1_sync+0x0/0x140 [ 212.692014] arch_cpu_idle+0x18/0x30 [ 212.695714] default_idle_call+0x44/0x178 [ 212.699836] do_idle+0x238/0x2b0 [ 212.703182] cpu_startup_entry+0x30/0x6c [ 212.707193] rest_init+0xc8/0xd8 [ 212.710526] arch_call_rest_init+0x18/0x24 [ 212.714725] start_kernel+0x55c/0x594 [ 212.718530] Code: d503201f d503201f d503201f d503201f (a90007e0) [ 212.724740] ---[ end trace e06bc25c1f41ac0f ]--- [ 212.473177] Unhandled fault at 0xffff800010003eb0 [ 212.477948] Mem abort info: [ 212.480813] ESR = 0x96000040 [ 212.483944] EC = 0x25: DABT (current EL), IL = 32 bits [ 212.489326] SET = 0, FnV = 0 [ 212.492447] EA = 0, S1PTW = 0 [ 212.495644] Data abort info: [ 212.498590] ISV = 0, ISS = 0x00000040 [ 212.502494] CM = 0, WnR = 1 [ 212.505551] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000f1758000 [ 212.512328] [ffff800010003eb0] pgd=000000237ffff003, p4d=000000237ffff003, pud=000000237fffe003, pmd=000000237fffd003, pte=0068002000155f03 [ 212.525116] Internal error: ttbr address size fault: 96000040 [#1] SMP [ 212.531699] Modules linked in: rfkill nls_ascii nls_cp437 vfat fat aes_ce_blk crypto_simd cryptd aes_ce_cipher ghash_ce gf128mul libaes ngbe(OE) sha2_ce sha256_arm64 efi_pstore sg evdev sha1_ce sbsa_gwdt ptp pps_core drm fuse configfs efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic sd_mod t10_pi crc_t10dif crct10dif_generic ahci libahci libata scsi_mod crct10dif_ce crct10dif_common [ 212.569585] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G OE 5.10.0-22-arm64 #1 Debian 5.10.178-3 [ 212.579309] Hardware name: PHYTIUM LTD D2000/J351BS, BIOS XTDB-J351B-S_V0.1.0.0 Apr 8 2024 [ 212.587770] pstate: 600003c5 (nZCv DAIF -PAN -UAO -TCO BTYPE=--) [ 212.593869] pc : el1_sync+0x0/0x140 [ 212.597447] lr : el1_irq+0xcc/0x180 [ 212.601000] sp : ffff800010003eb0 [ 212.604385] x29: ffff8000118b3ea0 x28: ffff8000118c3240 [ 212.609844] x27: 0000000000000000 x26: ffff800010004000 [ 212.615306] x25: ffff800010000000 x24: 0000000000000000 [ 212.620755] x23: 0000000060000005 x22: ffff800010c40c88 [ 212.626215] x21: ffff8000118b3ec0 x20: 0000ffffffffffff [ 212.631672] x19: ffff8000118b3d70 x18: 0000000000000000 [ 212.637121] x17: 0000000000000000 x16: 0000000000000000 [ 212.642569] x15: 0000000000000000 x14: 0000000000000000 [ 212.648015] x13: 0000000000000003 x12: 0000000000000003 [ 212.653462] x11: 0000000000000000 x10: 0000000000000b00 [ 212.658916] x9 : ffff800010101ccc x8 : ffff8000118c3da0 [ 212.664371] x7 : 0000000000000497 x6 : 000000029190b76f [ 212.669824] x5 : 00ffffffffffffff x4 : ffff0022edf0f080 [ 212.675279] x3 : 0000000000000000 x2 : 00000000000349ae [ 212.680732] x1 : ffff800010100260 x0 : ffff8000118b3d70 [ 212.686179] Call trace: [ 212.688734] el1_sync+0x0/0x140 [ 212.692014] arch_cpu_idle+0x18/0x30 [ 212.695714] default_idle_call+0x44/0x178 [ 212.699836] do_idle+0x238/0x2b0 [ 212.703182] cpu_startup_entry+0x30/0x6c [ 212.707193] rest_init+0xc8/0xd8 [ 212.710526] arch_call_rest_init+0x18/0x24 [ 212.714725] start_kernel+0x55c/0x594 [ 212.718530] Code: d503201f d503201f d503201f d503201f (a90007e0) [ 212.724740] ---[ end trace e06bc25c1f41ac0f ]--- [ 214.461504] Unable to handle kernel NULL pointer dereference at virtual address 00000000000002e0 [ 214.722653] Mem abort info: [ 214.725575] ESR = 0x96000006 [ 214.728788] EC = 0x25: DABT (current EL), IL = 32 bits [ 214.734239] SET = 0, FnV = 0 [ 214.737426] EA = 0, S1PTW = 0 [ 214.740677] Data abort info: [ 214.743686] ISV = 0, ISS = 0x00000006 [ 214.747656] CM = 0, WnR = 0 [ 214.750807] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000040 [ 214.759710] Mem abort info: [ 214.762623] ESR = 0x96000006 [ 214.765831] EC = 0x25: DABT (current EL), IL = 32 bits [ 214.771278] SET = 0, FnV = 0 [ 214.774462] EA = 0, S1PTW = 0 [ 214.777710] Data abort info: [ 214.780718] ISV = 0, ISS = 0x00000006 [ 214.784686] CM = 0, WnR = 0 [ 214.787836] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000040 [ 214.796736] Mem abort info: [ 214.799651] ESR = 0x96000006 [ 214.802855] EC = 0x25: DABT (current EL), IL = 32 bits [ 214.808301] SET = 0, FnV = 0 [ 214.811483] EA = 0, S1PTW = 0 [ 214.814730] Data abort info: [ 214.817737] ISV = 0, ISS = 0x00000006 [ 214.821707] CM = 0, WnR = 0
2. stack return address anomalies
root@debian:/home/zhaoyu/seu_memtest# ./memtester_tmr 10[ 488.698660] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: [ 488.704749] rcu: 2-...!: (1 GPs behind) idle=48a/0/0x1 softirq=4582/4583 fqs=460 [ 488.712305] (detected by 7, t=52520 jiffies, g=2421, q=1444) [ 488.718036] Task dump for CPU 2: [ 488.721252] task:swapper/2 state:R running task stack: 0 pid: 0 ppid: 1 flags:0x0000002a [ 488.731153] Call trace: [ 488.733593] __switch_to+0x12c/0x164 [ 488.737156] 0x60000005 [ 488.739592] rcu: rcu_preempt kthread starved for 51606 jiffies! g2421 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=3 [ 488.749835] rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. [ 488.758950] rcu: RCU grace-period kthread stack dump: [ 488.763987] task:rcu_preempt state:R running task stack: 0 pid: 11 ppid: 2 flags:0x00000028 [ 488.773886] Call trace: [ 488.776321] __switch_to+0x12c/0x164 [ 488.779886] __schedule+0x3d0/0x564 [ 488.783363] schedule+0x9c/0xe0 [ 488.786492] schedule_timeout+0x90/0x120 [ 488.790405] rcu_gp_kthread+0x678/0xc78 [ 488.794228] kthread+0x134/0x1f4 [ 488.797443] ret_from_fork+0x10/0x30
I'm currently unsure whether the compiler approach can protect against this type of error caused by SEUs (such as the EDDI method you mentioned). However, based on your FreeRTOS validation, it should also be effective for Linux. I'm trying to apply these methods to the affected modules. What other considerations do you think we should be aware of? Thank you for your help. If possible, we could exchange contact details. My Telegram ID/Username is ginzhao.

[GIN-zhao]

@davidebaroffio-polimi
Additionally, there are some other documents you may find useful.
https://arxiv.org/pdf/2503.03722