linux-kernel - Re: [PATCH 00/15] bitops: Change bitmap index from int to unsigned long

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]

Date:	Wed, 25 Feb 2009 08:53:47 -0700
From:	Matthew Wilcox <matthew@....cx>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Justin Chen <jchen@...st41.cup.hp.com>, linux-arch@...r.kernel.org,
	bjorn.helgaas@...com, justin.chen@...com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/15] bitops: Change bitmap index from int to unsigned long

On Wed, Feb 25, 2009 at 04:46:00PM +0100, Peter Zijlstra wrote:
> > Adding one more bit only doubles the maximum size.  That buys us, what,
> > another eighteen months until we have to change it again?  Unsigned long
> > seems most sensible to me.  Unsigned long long probably isn't worth
> > doing -- you'd have to be using one eighth of your address space on a
> > single bitmap.
> 
> Are you serious? Bitmaps of length 4G-bit (512M-byte) are way past the
> sanely allocatable size anyway.

Runtime allocatable, yes.  This particular instance was during boot.
Justin wrote:

> If the caller passes a large unsigned integer and we interpret it as
> being negative, we compute an address outside the bitmap.  This can
> cause memory corruption or other errors.

> The issue that triggered me to do this change is the routine
> mark_bootmem_node() while we ran on an ia64 box with large memory.
> As long as the EFI maps the available memory chunk at the physical
> address 0x200000000000 (or above), the routine mark_bootmem_node() will
> get the start PFN>=0x80000000.  While it calls the __free() with this
> sidx=0x80000000 (bit31 set), the bitops (test_and_clear_bit) will treat
> this idx as a negative number since it accepts it as an "int".  It turns
> out the memory outside the bitmap will be corrupted.

If we've got problems with overflowing 'int' on memory size, we'll be
overflowing 'unsigned int' in eighteen months.  0x200000000000 is large,
but we can easily add on an extra four nybbles.

I don't see the downside to using unsigned long instead of unsigned int.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
--
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/