If a brand provides a header_supported hook, check it when trying to find
a brand based on a matching interpreter as well as in the final loop for the
fallback brand. Previously a brand might reject a binary via a
header_supported hook in one of the earlier loops, but still be chosen by
one of these later loops.
Details
- Reviewers
imp kib - Commits
- rS328909: Always give ELF brands a chance to veto a match.
- CHERI binaries tripped over this as described at https://github.com/CTSRD-CHERI/cheribsd/issues/248
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
sys/kern/imgact_elf.c | ||
---|---|---|
375 ↗ | (On Diff #38072) | Why put the condition into the separate if () ? It naturally extends the existing condition with &&. |
sys/kern/imgact_elf.c | ||
---|---|---|
375 ↗ | (On Diff #38072) | Mostly because the if condition was starting to get ugly to read. The rest of this function always invokes header_supported in a separate statement as well and this seemed a bit more readable. (The == 0 in the strncmp having to wrap is rather unfortunate for readability.) |
389 ↗ | (On Diff #38072) | My one open question is if we should be running header_supported here? On the one hand a fallback brand has to be opted into, OTOH, a header_supported method probably knows it can't possibly handle certain types of files so should probably be honored? |
sys/kern/imgact_elf.c | ||
---|---|---|
389 ↗ | (On Diff #38072) | I agree that it would be more consistent to check all places where we might to select the brand, against the header_supported. Until we have a case were the matching result changes, it is more theoretical question. |