elf: fail validation if writable .data sections are present#240
elf: fail validation if writable .data sections are present#240alessandrod merged 2 commits intosolana-labs:mainfrom
Conversation
|
One thing to note is that doing verification this way is obviously stricter, as it will fail at validation time vs run time when the data gets written to. But we've already decided to do it this way for |
dmakarov
left a comment
dmakarov
left a comment
There was a problem hiding this comment.
thank you for adding the tests in addition to the fix!
This extends the check we already do for .bss to all writable .data sections. Improves error messages for programs that use mutable global state, for which before we were returning access violation errors due to relocated addresses being invalid, eg: Access violation in program section at address 0x1000a39b0 of size 8 by instruction #5065 Versus the error we provide now: Found writable section (.data._ZN3std6thread8ThreadId3new7COUNTER17h88fd3fcacf16583cE.llvm.14438380808032992799) in ELF, read-write data not supported
alessandrod
force-pushed
the
writable-data-sections
branch
from
e63c81d to
21b3239
Compare
|
I guess when this get merged I should bump version and tag? |
When reject_writable_data_sections is turned on, programs with writable data sections (global mutable state) are rejected. See solana-labs/rbpf#240
|
This is the corresponding solana PR: solana-labs/solana#21826. Marked as draft for now since we need to bump rbpf version before it can get in. |
Yes, pushing a tag should publish the new version on crates.io automatically. If this fails, please, let me know. |
|
But we still have to bump the version manually. Only the |
Correct. A new version tag still needs to be pushed manually to the github repository to trigger the publishing of a new version to crates.io. |
|
@alessandrod I added a few more changes to roll in a missing featurization from earlier, check them out. |
Looks good! |
When reject_writable_data_sections is turned on, programs with writable data sections (global mutable state) are rejected. See solana-labs/rbpf#240
4 participants
This extends the check we already do for .bss to all writable .data sections. Improves error messages for programs that use mutable global state, for which before we were returning access violation errors due to relocated addresses being invalid, eg:
Versus the error we provide now:
The new error can actually help folks pin point the issue with their code (in my example, some hashmap code pulling in threading code).