linux-kernel - Re: [patch 3/4 -mm] flex_array: poison free elements

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: <1251150156.22398.8289.camel@nimitz>
Date:	Mon, 24 Aug 2009 14:42:36 -0700
From:	Dave Hansen <dave@...ux.vnet.ibm.com>
To:	David Rientjes <rientjes@...gle.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 3/4 -mm] flex_array: poison free elements

On Mon, 2009-08-24 at 13:41 -0700, David Rientjes wrote:
> On the other hand, I'd have no problem trying to eliminate 
> fa->total_nr_elements (since we already have fa->element_size) since we 
> can calculate it in real-time; the only problem is being able to 
> distinguish when the elements are being stored in struct flex_array vs. 
> being stored in struct flex_array_part.

Yeah, that's the only reason it's there: to determine if we're using the
compact form or not.  We could probably find another place to store
that, or just store a flag telling whether we're using that form or not.
We couldn't do the bounds-checking, but I'm OK with that.

But, honestly, it doesn't *really* bother me if we just use two 32-bit
int slots in the 'struct flex_array'.  The 64-bit code has an extra 4
bytes now anyway.

> We could then use that
> unsigned int in struct flex_array to store the number of inuse elements 
> which is an alternative implementation to flex_array_shrink(), yet I'd 
> still propose to keep the poisoning to reveal use-uninitialized.

I kinda like the idea of truncating more, just because its simpler and
doesn't have any assumptions about the contents.  But, you are right
that poisoning has some distinct benefits, namely allowing sparsely used
arrays to shrink.

-- Dave

--
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/