Mips handling of signed integer overflows
Subsystems (2)
Dear Mips maintainers,
back in 2006, commit 36ccf1c0e391 ("[MIPS] Make integer overflow exceptions in kernel mode fatal.") forced the kernel to panic on integer overflows.
But three years later in 2009, commit 68df3755e383 ("Add '-fwrapv' to gcc CFLAGS") ensured that integer overflows are not undefined behavior and instead force wraparound.
I assume this means that the compiler uses non-trapping instructions for addition/subtraction on Mips. Consequently, calling die_if_kernel() from do_ov() in arch/mips/kernel/traps.c should no longer be necessary as it can never happen.
Can you confirm or deny this?
I came across this because ecdsa_get_signature_rs() in crypto/ecdsa.c performs a subtraction which may lead to a signed integer overflow:
https://lore.kernel.org/all/[email protected]/
If gcc ignores -fno-strict-overflow on Mips and raises an exception, the kernel would panic in ecdsa_get_signature_rs() for a sufficiently large ASN.1-encoded integer.
Thanks,
Lukas
Quoted 3 lines · Lukas Wunner
back in 2006, commit
36ccf1c0e391("[MIPS] Make integer overflow exceptions in kernel mode fatal.") forced the kernel to panic on integer overflows.
Makes sense.
Quoted 3 lines
But three years later in 2009, commit
68df3755e383("Add '-fwrapv' to gcc CFLAGS") ensured that integer overflows are not undefined behavior and instead force wraparound.
Makes sense too.
Quoted 6 lines
I assume this means that the compiler uses non-trapping instructions for addition/subtraction on Mips. Consequently, calling
die_if_kernel()fromdo_ov()inarch/mips/kernel/traps.cshould no longer be necessary as it can never happen.Can you confirm or deny this?
Neither.
MIPS C compilers have never produced trapping addition/subtraction
instructions, which have been reserved for use by other programming languages. And GCC specifically has never produced these instructions for any of the languages supported, there are no patterns in the MIPS backend defined that would produce these instructions. The only way to encounter one of them in the execution stream is by means of handcoded assembly.
The call to `die_if_kernel' is there is to catch an unexpected scenario,
just as with any unexpected exception triggered in the kernel mode. It has to stay there as reaching that place means that we have a bug in the kernel, because we're not supposed ever to encounter a trapping addition/subtraction instruction (there's one specific exception to this rule in arch/mips/kernel/r4k-bugs64.c, and we install a special handler temporarily to take care about it).
Quoted 8 lines
I came across this because
ecdsa_get_signature_rs()incrypto/ecdsa.cperforms a subtraction which may lead to a signed integer overflow:https://lore.kernel.org/all/[email protected]/
If gcc ignores -fno-strict-overflow on Mips and raises an exception, the kernel would panic in
ecdsa_get_signature_rs()for a sufficiently large ASN.1-encoded integer.
This is not going to happen.
NB I know the internals of the MIPS GCC backend pretty well, I've worked
with it for decades now.
Did I answer your question?
Maciej
Quoted 7 lines · Maciej W. Rozycki
Quoted 6 lines · Lukas Wunner
I assume this means that the compiler uses non-trapping instructions for addition/subtraction on Mips. Consequently, calling
die_if_kernel()fromdo_ov()inarch/mips/kernel/traps.cshould no longer be necessary as it can never happen.Can you confirm or deny this?
[...]
Quoted 6 lines
MIPS C compilers have never produced trapping addition/subtraction
instructions, which have been reserved for use by other programming languages. And GCC specifically has never produced these instructions for any of the languages supported, there are no patterns in the MIPS backend defined that would produce these instructions. The only way to encounter one of them in the execution stream is by means of handcoded assembly.
[...]
Quoted 1 line
Did I answer your question?
Yes thank you this helps greatly.
Lukas