On Tue, Jan 23, 2024 at 5:45 AM Kees Cook wrote:
>
> Yes. We removed this bad behavior by using -fno-strict-overflow, and we will
> want to keep it enabled.
Yeah, I only meant that the wording of the commit seems to say there
is something special about the "overflowing behavior", i.e. I was
expe
On January 22, 2024 6:24:14 PM PST, Miguel Ojeda
wrote:
>On Tue, Jan 23, 2024 at 1:28 AM Kees Cook wrote:
>>
>> Because the kernel is built with -fno-strict-overflow, signed and pointer
>> arithmetic is defined to always wrap around instead of "overflowing"
>> (which would either be elided du
On Tue, Jan 23, 2024 at 1:28 AM Kees Cook wrote:
>
> Because the kernel is built with -fno-strict-overflow, signed and pointer
> arithmetic is defined to always wrap around instead of "overflowing"
> (which would either be elided due to being undefined behavior or would
> wrap around, which led to
Effectively revert commit 6aaa31aeb9cf ("ubsan: remove overflow
checks"), to allow the kernel to be built with the "*-overflow"
sanitizers again. This gives developers a chance to experiment[1][2][3]
with the instrumentation again, while dealing with the impact of
-fno-strict-oveflow.
Notably, the
