linux-kernel - Re: [PATCH] kallsyms: fix potential overflow in binary search

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 14 May 2008 17:31:49 +0200
From:	"Vegard Nossum" <vegard.nossum@...il.com>
To:	"Paulo Marques" <pmarques@...popie.com>
Cc:	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] kallsyms: fix potential overflow in binary search

Hi,

On Wed, May 14, 2008 at 1:44 PM, Paulo Marques <pmarques@...popie.com> wrote:
> Vegard Nossum wrote:
>>>
>>> From 61b840f071e496f632fcc293f5435428cfc98844 Mon Sep 17 00:00:00 2001
>>
>> From: Vegard Nossum <vegard.nossum@...il.com>
>> Date: Tue, 13 May 2008 10:20:27 +0200
>> Subject: [PATCH] kallsyms: fix potential overflow in binary search
>>
>> This will probably never trigger... but it won't hurt to be careful.
>
> Not "probably", this will never trigger _period_. If you ever have more than
> 2^31 symbols in the kernel's kallsyms table you'll have worse problems to
> worry about than the binary search overflowing.
>
> So, I don't think it is worth this des-optimization at all...

You are right, and I will not push this patch through if you think it's stupid.

The change is only a matter of principle; at the very least, document
your assumptions! So my patch changed something that was not obviously
right to something that is explicitly right. Is it even remotely
possible that somebody could notice that we never have 2^32 kallsym
entries and change these array indices to a smaller type, without
taking the possibility of overflow into account? It sounds unlikely, I
agree; on the other hand, what makes this different from all the
_other_ times you thought something was impossible and it wasn't?
(Surely you've had those experiences too?)

My mentality is to make things work under as many circumstances as
possible, provided the effort is worth it, so that I won't be
surprised in the future. Documentation is another way to do that.
Would you rather see a patch that introduces a comment which explains
why the overflow isn't possible (in the current situation)?

If you still believe this is wrong, then I will ask Andrew to withdraw
the patch. Thank you for your comments.

Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/