On Mon, 22 Jul 2024, Lukas Wunner wrote:
> back in 2006, commit 36ccf1c0e391 ("[MIPS] Make integer overflow
> exceptions in kernel mode fatal.") forced the kernel to panic on
> integer overflows.
Makes sense.
> 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.
> 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?
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).
> 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/Zp5b7ZQaXfGbkCVC@xxxxxxxxx/
>
> 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
