Skip to content

x86-64 Pjmptbl: normalize the argument before indexing into the jump table - #595

Merged
xavierleroy merged 4 commits into
masterfrom
x86_64-jmptbl
Aug 27, 2026
Merged

x86-64 Pjmptbl: normalize the argument before indexing into the jump table#595
xavierleroy merged 4 commits into
masterfrom
x86_64-jmptbl

Conversation

@xavierleroy

Copy link
Copy Markdown
Contributor

The index argument of Pjmptbl is an unsigned 32-bit integer, not a 64-bit integer, so it must be converted to 64 bits (by zeroing the top 32 bits) before being used as an index into the jump table.

Issue reported by Christos Papakonstantinou (Cantina Security).

@xavierleroy

Copy link
Copy Markdown
Contributor Author

It turns out that RISC-V 64 bits has a similar issue, although much less serious: the 32-bit index argument is implicitly extended to a signed 64-bit integer. So, in the unlikely case where the jump table has more than 2^31 entries, we're addressing the wrong entry. Commit bc5a65f proposes to fix this by zero-extending the index while multiplying it by 4. It adds one shift-right instruction to the code generated for Pbtbl. The alternative would be to reject jump tables with more than 2^31 entries.

@xavierleroy

Copy link
Copy Markdown
Contributor Author

The RISC-V fix was overkill: we're generating worse code for a case that never happens in practice. I just added a run-time assertion that the jump table has at most 2^31 entries, which guarantees that the index has the correct 64-bit value.

…p table

The index argument of Pjmptbl is an unsigned 32-bit integer, not a 64-bit
integer, so it must be converted to 64 bits (by zeroing the top 32 bits)
before it can be used as an index into the jump table.
… elements

The index argument of Pbtbl is an unsigned 32-bit integer.  However, RV64
stores it sign-extended in a 64-bit register.  This could cause an
incorrect access in the jump table if the index is 2^31 or more.

However, this can only happen if the jump table itself has at least
2^31 entries, which is highly unlikely (a source C program that would
produce such a huge table would itself be huge and CompCert would
probably run out of memory compiling it).

To be on the safe side, we just add a run-time assertion that the jump
table is no bigger than 2^31 entries.
@xavierleroy
xavierleroy merged commit ad4934a into master Aug 27, 2026
19 checks passed
@xavierleroy
xavierleroy deleted the x86_64-jmptbl branch August 27, 2026 11:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant