linux-kernel - Re: [RFC PATCH 0/4] kstrdup optimization

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:	Tue, 30 Dec 2014 09:32:30 +0100
From:	Andreas Mohr <andi@...as.de>
To:	Andrzej Hajda <a.hajda@...sung.com>
Cc:	Andi Kleen <andi@...stfloor.org>, linux-mm@...ck.org,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/4] kstrdup optimization

Hi,

Andrzej Hajda wrote:
> On 12/30/2014 07:45 AM, Andi Kleen wrote:
> > What happens if someone is to kfree() these strings?
> >
> > -Andi
> >
> kstrdup_const must be accompanied by kfree_const, I did not mention it
> in cover letter
> but it is described in the 1st patch commit message.
> Simpler alternative (but I am not sure if better) would be to add
> similar check
> (ie. if pointer is in .rodata) to kfree itself.

Seems like a large potential programmer-side (a)symmetry issue to me
(not unsimilar to the new/delete vs. malloc/free asymmetry PITA
encountered in case of "dirty C++ habits").

This symmetry issue probably could be cleanly avoided only
by having kfree() itself contain such an identifying check, as you suggest
(thereby slowing down kfree() performance).
(OTOH we do have nice helpers such as Coccinelle
to near-sufficiently deal with such issues,
albeit in a less preferrable/elegant/automatic manner).

If we decide to want to avoid this rats nest via clean builtin identification
but in case such a kfree-side .rodata check is unjustifiably expensive,
one could try to have *builtin* (i.e., fully or at least almost *non*-runtime)
branching of their differing handling,
by marking _const-originated "allocations" via a special easily checkable flag -
but since in such kalloc/kfree API cases
we're dealing with simple raw pointer results
rather than more complex structs,
such identification markup probably could only be achieved
via internal mapping overhead (of management structs) -
unless those APIs happen to have internal bookkeeping already
(in which case the only penalty would either be setting/evaluating a flag
of common shared bookkeeping structs,
or full/clean branching into distinctly handled management parts,
which might be able to cause less runtime overhead).

Andreas Mohr

-- 
GNU/Linux. It's not the software that's free, it's you.
--
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/