Mips handling of signed integer overflows

Mips handling of signed integer overflows

[Lukas Wunner]

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/Zp5b7ZQaXfGbkCVC@wunner.de/

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

Re: Mips handling of signed integer overflows

[Maciej W. Rozycki]

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@wunner.de/
> 
> 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

Re: Mips handling of signed integer overflows

[Lukas Wunner]

On Mon, Jul 22, 2024 at 03:59:00PM +0100, Maciej W. Rozycki wrote:
> On Mon, 22 Jul 2024, Lukas Wunner wrote:
> > 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?
[...]
>  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.
[...]
>  Did I answer your question?

Yes thank you this helps greatly.

Lukas