-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
irq: Add 0 address access panic configuration #15562
base: master
Are you sure you want to change the base?
Conversation
Implemented using up_debugpoint_add Signed-off-by: wangmingrong1 <[email protected]>
[Experimental Bot, please feedback here] No, this PR does not meet the NuttX requirements. The provided information is far too sparse. Here's why and what's missing:
In short, this PR provides almost no context or evidence for the change. It needs significant revision to be considered. |
@@ -59,6 +60,14 @@ struct irq_info_s g_irqvector[NR_IRQS]; | |||
* Public Functions | |||
****************************************************************************/ | |||
|
|||
#ifdef CONFIG_ARCH_PROTECT_ZERO_ADDRESS |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could we move to sched/misc
@@ -538,6 +538,14 @@ config ARCH_PERF_EVENTS | |||
Enable hardware performance counter support for perf events. If | |||
disabled, perf events will use software events only. | |||
|
|||
config ARCH_PROTECT_ZERO_ADDRESS | |||
bool "Protect address zero" | |||
depends on ARCH_HAVE_DEBUG |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
move to nuttx/Kconfig or sched/Kconfig?
@@ -87,5 +96,11 @@ void irq_initialize(void) | |||
#endif | |||
|
|||
up_irqinitialize(); | |||
|
|||
#ifdef CONFIG_ARCH_PROTECT_ZERO_ADDRESS | |||
up_debugpoint_add(DEBUGPOINT_WATCHPOINT_RW, 0, 0, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not use the mpu? What happens if access the address 0 + offset?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it may legal to fetch the code at address 0, mpu can't distinguish fetch and read.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most null pointer access is read and write, and MPU is clearly more suitable for monitoring null pointer access
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not approve of using debug monitor to only protect address 0, If the offset is based on address 0, it will not be able to protect
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The automated configuration of MPU will be a rather substantial topic. It involves modifications to the unified linker script. A great deal of include logic needs to be added to the script for all linker segments and constants. We can draw inspiration from the implementations in Zephyr and Linux.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using 0+offset to access does not really catch the problem. I will think about the new approach carefully and update this patch.
default n | ||
---help--- | ||
When the program accesses address 0, it will assert automatically. | ||
Hardware support is required, such as ARM V8M DWT |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@W-M-R since it depends on HW support, shouldn't it be dependent on ARCH_HAVE_PROTECT_ZERO_ADDRESS ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
already depends on ARCH_HAVE_HWDEBUG
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mean ARCH_HAVE_DEBUG not ARCH_HAVE_HWDEBUG, right? But ARMV7M also has ARCH_HAVE_DEBUG and probably doesn't have this feature, correct? RISC-V also have ARCH_HAVE_DEBUG
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the current 0 address protection method is not unified for each ARCH. I will think about it carefully and modify this patch.
Note: Please adhere to Contributing Guidelines.
Summary
Implemented using up_debugpoint_add
Impact
Update this section, where applicable, on how change affects users,
build process, hardware, documentation, security, compatibility, etc.
Testing
Update this section with details on how did you verify the change,
what Host was used for build (OS, CPU, compiler, ..), what Target was
used for verification (arch, board:config, ..), etc. Providing build
and runtime logs from before and after change is highly appreciated.