linux-kernel - Re: [PATCH 1/15] don't reallocate buffer in every audit

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]

Message-ID: <20081217075612.GY28946@ZenIV.linux.org.uk>
Date:	Wed, 17 Dec 2008 07:56:12 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Al Viro <viro@....linux.org.uk>, linux-audit@...hat.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/15] don't reallocate buffer in every audit_sockaddr()

On Tue, Dec 16, 2008 at 11:49:27PM -0800, Andrew Morton wrote:
> > +	if (!context->sockaddr) {
> > +		void *p = kmalloc(sizeof(struct sockaddr_storage), GFP_KERNEL);
> 
> argh, I really hate having to run all around the code verifying that
> the type passed to sizeof matches the type that we'll be storing there :(

And I really hate being unable to find the places doing such allocations
without serious parsing.  Matter of taste.
 
> stoopid question: can an audit_contect be shared between
> threads/processes?  If so, is locking needed around the read/test/write
> of context->sockaddr and friends?  

It can't.  And that's very fortunate, since otherwise all that crap would
	a) be horribly racy
	b) require shitloads of locking all over the place, driving the
overhead even higher.
--
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/