linux-kernel - Re: [PATCH] mm: __nr_to_section - make it safe against overflow

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0901050935120.13628@quilx.com>
Date:	Mon, 5 Jan 2009 09:37:36 -0600 (CST)
From:	Christoph Lameter <cl@...ux-foundation.org>
To:	Cyrill Gorcunov <gorcunov@...il.com>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Nick Piggin <npiggin@...e.de>, Rik van Riel <riel@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Jiri Slaby <jirislaby@...il.com>
Subject: Re: [PATCH] mm: __nr_to_section - make it safe against overflow

On Mon, 5 Jan 2009, Cyrill Gorcunov wrote:

> yes, I know, that is why I've changed WARN_ON_ONCE to plain WARN_ON.

This is still going to create a gazillion of checks in the code because it
will be expanded numerous times.

> | I would think that the code does not have the tests because of performance
> | and code size concerns. Can we just say that a sane nr must be passed to
> | __nr_section?
> |
>
> If you mean did I test this patch for speed regresson then to be fair --
> no, I didn't. BUT we have a number of macros wich are self protective
> like present_section which is used havily too. On the other hand --
> bad argument passed to __nr_to_section will be (and it is now) really
> harmfull -- since it would allow to reference a memory outside the
> valid bounds. The second -- SECTION_ROOT_MASK wich is fragile, any
> attempt to modify mem_section structure will silently lead to insane
> referencing, that is why it deserve a comment on top of structure.
>
> Don't know Christoph, if it really that important to not spend a few
> cycles here in a sake of safety -- we could easily drop this patch.

The problem is that these few cycles aggregate. Both because these inline
primitives are frequently used and because developers add more of these
checks over time.
--
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/