Received-SPF: pass (google.com: domain of linux-kernel+bounces-181805-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <99da3934-2c44-4a1f-832f-3f182ddadefa@huaweicloud.com>
Date: Fri, 17 May 2024 09:45:20 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC] Mitigating unexpected arithmetic overflow
To: Linus Torvalds <torvalds@linux-foundation.org>,
 Kees Cook <keescook@chromium.org>
Cc: Justin Stitt <justinstitt@google.com>,
 Peter Zijlstra <peterz@infradead.org>, Mark Rutland <mark.rutland@arm.com>,
 linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org,
 llvm@lists.linux.dev
References: <202404291502.612E0A10@keescook>
 <CAHk-=wi5YPwWA8f5RAf_Hi8iL0NhGJeL6MN6UFWwRMY8L6UDvQ@mail.gmail.com>
 <202405081144.D5FCC44A@keescook>
 <CAHk-=wjeiGb1UxCy6Q8aif50C=wWDX9Pgp+WbZYrO72+B1f_QA@mail.gmail.com>
From: Jonas Oberhauser <jonas.oberhauser@huaweicloud.com>
In-Reply-To: <CAHk-=wjeiGb1UxCy6Q8aif50C=wWDX9Pgp+WbZYrO72+B1f_QA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


Am 5/8/2024 um 10:07 PM schrieb Linus Torvalds:
> And no, the answer is ABSOLUTELY NOT to add cognitive load on kernel
> developers by adding yet more random helper types and/or functions.


Just to show an option without "more types and helper functions", one 
could also instead add a coverage requirement:

Every arithmetic operation should either:
- have a test case where the wrap around happens, or
- have a static analyser say that overflow can not happen, or
- have a static analyser say that overflow is fine (e.g., your a+b < a case)

Then the answer to safe wrap situations isn't to make the kernel code 
less readable, but to have a component-level test that shows that the 
behavior on overflow (in at least one case :)) ) is what the developer 
expected.

For static analysis to prove that overflow can not happen, one sometimes 
would need to add BUG_ON() assertions to let the analyser know the 
assumptions on surrounding code, which has its own benefits.


static inline u32 __item_offset(u32 val)
{
         BUG_ON(val > INT_MAX / ITEM_SIZE_PER_UNIT);
         return val * ITEM_SIZE_PER_UNIT;
}


Obviously, the effort involved is still high. Maybe if someone as a pet 
project proves first that something in this direction is actually worth 
the effort (by uncovering a heap of bugs), one could offer this kind of 
check as an opt-in.


Best wishes,

   jonas