Re: [PATCH v2 4/5] lib: sbi: Create a spot to place Smrnmi detection before traps and after DT is ready

Anup Patel <[email protected]>
Newsgroups org.infradead.lists.opensbi
Message-ID <CAAhSdy2GUYS--zred2cetcC=6z00J5M+5ZkWZXGOyoNjCaHQ+w@mail.gmail.com>
On Mon, May 4, 2026 at 10:10 PM Evgeny Voevodin
<[email protected]> wrote:
>
> Hi Anup,
>
> Two concerns about the suggested approach.
>
> 1) Enablement of NMIs before the platform has set up its NMI handler
> introduces a window of possible hang. While NMIE=1, the trap handler is
> not defined, so if an NMI arrives, the trap jumps to nowhere.
>
> The v2 series keeps NMIE=0 until smrnmi_handlers_init() has installed
> both NMIVEC and the regular trap entry, which avoids this hole.
>
> More generally: on Smrnmi-enabled platforms, there is really no way to
> use any trap-based mechanism until the platform has set its NMI handlers.
> Holding off them until after a call to the platform's
> smrnmi_handlers_init() is mandatory to prevent possible hangs.
>
> 2) About the stack canary concern with the C-side __stack_chk_guard_init().
>
> The danger pattern "canary already pushed on stack" only triggers if a
> function call which returns is currently on stack, which means
> __stack_chk_guard variable will be checked against its value on prologue.
> Neither C nor asm functions currently on stack return or use epilogue
> check of __stack_chk_guard. The full call chain to __stack_chk_guard_init()
> consists of:
>
>   asm _start
>    -> sbi_init()              __noreturn
>       -> init_coldboot()      __noreturn
>          -> __stack_chk_guard_init()    asm, no canary
>
> Even if asm side falls back to `return`, it is still `j _start_hang`
> which also doesn't check epilogue.
>
> Could you reconsider patch 4/5 with this context?
>

Sounds good but I still require some changes.

This patch needs to be split into two patches:
1) The first patch should only move sbi_platform_extensions_init()
before trap-based feature detection
2) The second patch should move Zkr based stack canary
initialization into C code. No need for preserving the existing
__stack_chk_guard_init() intead we can initialize __stack_chk_guard
variable directly from init_coldboot()

Regards,
Anup

-- 
opensbi mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/opensbi
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.