MEPCC during NMI recovery

[mndstrmr]

This is not a bug, as there is no specification besides that which I have written for this behaviour as far as I know.

When taking an NMI Ibex stores mepc in mstack_epc to allow for easy recovery. Upon MRET mstack_epc is copied back to mepc. See here.

CherIoT-Ibex does this too, but it does not store the upper bits of MEPCC, and so upon MRET MEPCC.address = mstack_epc and the rest is cleared. MEPCC therefore does not have the value it would have had, had the NMI not happened.

This feels like the wrong behaviour to me, but I may be wrong and it's possible that CherIoT-RTOS simply doesn't care. I'm happy to be told that this is the intended behaviour.

[rmn30]

Hi, I think you're right that we've never defined NMI behaviour because we've never had a source of NMIs. What you're describing sounds doesn't sound useful: I think it would immediately fault after mret due to untagged PCC? I guess this means we'll have to define something sensible if we ever want NMI.

[marnovandermaas]

Is it possible to store a complete capability on the mstack or would that break some security properties?

[kliuMsft]

Revisiting the issue.. I'd prefer de-featuring NMI from cheriot-ibex (was my intention but never formally documented). @rmn30, @marnovandermaas?

[marnovandermaas]

How come you want to remove non-maskable interrupts? It is quite useful when designing an SoC that there are interrupts that cannot be disabled by software.

[kliuMsft]

I do believe in a well-designed system NMI is optional, and right now I don't see a use case for it in CHERIoT yet. Basically, interrupt masking should be owned by a trusted entity (in this case the scheduler) anyway and interrupt should only be masked when absolutely necessary. That implies taking an NMI might leave the system unstable.. If there is truly something can't wait even for a short amount of time, you can (and probably should) have dedicated hardware to handle it. From: Marno van der Maas ***@***.***> Sent: Monday, May 19, 2025 7:58 AM To: microsoft/cheriot-ibex ***@***.***> Cc: Comment ***@***.***>; Subscribed ***@***.***> Subject: Re: [microsoft/cheriot-ibex] MEPCC during NMI recovery (Issue #60) How come you want to remove non-maskable interrupts? It is quite useful when designing an SoC that there are interrupts that cannot be disabled by software. - Reply to this email directly, view it on GitHub<#60 (comment)> or unsubscribe<https://github.com/notifications/unsubscribe-auth/A3V7IMEF3IQKCWEEU5IU5OD27HWPHBFKMF2HI4TJMJ2XIZLTSOBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDUOJ2WLJDOMFWWLLTXMF2GG2C7MFRXI2LWNF2HTAVFOZQWY5LFUVUXG43VMWSG4YLNMWVXI2DSMVQWIX3UPFYGLLDTOVRGUZLDORPXI6LQMWWES43TOVSUG33NNVSW45FGORXXA2LDOOJIFJDUPFYGLKTSMVYG643JORXXE6NFOZQWY5LFVE2TSMBRGM3DKOBZQKSHI6LQMWSWS43TOVS2K5TBNR2WLKRSG43TANRWG44DMONHORZGSZ3HMVZKMY3SMVQXIZI>. You are receiving this email because you commented on the thread. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.