Fixed stack canary causes potential security issue

[rota1001]

The task_stack_check funciton uses a contant magic number STACK_CANARY to detect the corruption of stack. However, attackers can forge the canary to bypass the detection, causing some buffer overflows (or underflows) become arbitrary write on the stack. Moreover, since user and kernel program share an address space, some vulnerabilities in user program will cause some problems in kernel.

Thus, I wonder if we need a random stack canary in this kernel, adding an element uint32_t canary to tcb_t and using random to generate a random canary during initialization. Although the random in libc.c is not quite secure (It is predictable), it can be improved in the future.

[visitorckw]

Currently, the kernel does not implement virtual memory or MMU-based protection, so user programs share the same address space with the kernel. In this setup, it is already trivial for a malicious program to access or modify kernel memory, including bypassing the stack canary. Therefore, the use of a constant canary does not introduce a significant new security concern at this stage.

That said, once memory isolation is in place, adopting a randomized per-task stack canary will be a reasonable improvement.