linux-kernel - Re: [PATCH 8/9] um: fix strrchr problems

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: <20110830124805.GU2203@ZenIV.linux.org.uk>
Date:	Tue, 30 Aug 2011 13:48:05 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Richard Weinberger <richard@....at>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	user-mode-linux-devel@...ts.sourceforge.net, jdike@...toit.com
Subject: Re: [PATCH 8/9] um: fix strrchr problems

On Tue, Aug 30, 2011 at 12:32:31PM +0200, Richard Weinberger wrote:

> defconfig + STATIC_LINK +  UML_NET_VDE builds fine for me.
> 
> Toolchain (openSUSE 11.4):
> glibc: 2.11.3
> vde2: 2.3.1
> gcc: 4.5.3
> binutils: 2.21.1
> 
> Is my vde too new?
> BTW: Why is only strstr affected, what makes it so special?

What happens is that we end up with arch/um/drivers/vde.o having a reference
to rindex().  It comes from libvdeplug.a:libvdeplug.o and we don't have
rindex() in the kernel.  In libc we *do* have it - as an alias for strrchr.
So libc.a:strrchr.o is pulled in by that and we end up with conflict since
now two object files picked by linker define the same symbol.

At a guess, newer vde stopped wanking with rindex(3) (perhaps switching
to strrchr(3), as recommended by POSIX these days) and that has eliminated
the problem.

So yes, probably it's your vde being newer.  Until other distros pick that
version we are stuck with that problem, though...  Alternative solution
would be to have rindex() in arch/um/drivers/vde_kern.c - that also works
and might be a bit saner.  Defining it in lib/string.c is probably a bad
idea, since its use is not a good practice - it duplicates a standard C
equivalent (C89, at that) for no reason.
--
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/