[kernel-hardening] RE: [RFC PATCH 01/13] Add architecture independent hardened atomic base

["Reshetova, Elena" <elena.reshetova@intel.com>]

> config HARDENED_ATOMIC
> ...
>   This option catches counter wrapping in atomic_t, which
>   can turn refcounting over/underflow bugs into resource
>   consumption bugs instead of exploitable user-after-free flaws.
>

>Sorry to be pedantic, but this feature doesn't actually protect against underflowing atomic_t, and you actually meant "use-after-free"
>flaws.

Actually I am looking into this now since at least on x86 it seems to catch the underflow in some form. This was the output from tests that Hans run:

> ...
> lkdtm: Performing direct entry ATOMIC_UNDERFLOW
> lkdtm: attempting good atomic increment
> lkdtm: attempting bad atomic underflow
> HARDENED_ATOMIC: refcount overflow detected in: cat:3015, uid/euid: 
> 0/0
> HARDENED_ATOMIC: refcount overflow occurred at:
> ldtm_ATOMIC_UNDEFLOW+0x5f/0x80
> ---------[ cut here ]--------
> ...

This is the description of X86_TRAP_OF  trap for x86:

"Interrupt 4—Overflow Exception (#OF)
Exception Class
Trap.
Description
Indicates that an overflow trap occurred when an INTO 
instruction was executed. The INTO instruction checks the 
state of the OF flag in the EFLAGS register. If the OF flag is set, an overflow trap is generated.
Some arithmetic instructions (such as the ADD and SU
B) perform both signed and unsigned arithmetic. These 
instructions set the OF and CF flags in the EFLAGS register to indicate signed overflow and unsigned overflow, 
respectively. When performing arithmetic on signed operands, the OF flag can be tested directly or the INTO 
instruction can be used. The benefit of using the INTO instruction is that if the overflow exception is detected, an 
exception handler can be called automatically to handle the overflow condition."

I start to believe that we have a mismatch of terms here. 
Strictly speaking underflow is not defined for non-floating point numbers, so since we are dealing here with ints and longs, 
when both of them approach zero and then wrap around, it is treated as overflow (just in a different direction than when it approaches LONG_MAX or LONG_MIN).  
Does this makes sense for people? 

Best Regards,
Elena.