Re: [PATCH 0/3] explicit_bzero v5

[Zack Weinberg <zackw at panix dot com>]

On 11/15/2016 09:03 PM, Joseph Myers wrote:
> On Tue, 15 Nov 2016, Zack Weinberg wrote:
> 
>>  * libc.so now exports __explicit_bzero as well as explicit_bzero; the
>>    implementation-namespace symbol is used by libcrypt.so, and the
>>    user-namespace symbol is weak.  (Requested by Joseph, iirc.)
> 
> Requested by Florian (together with header pieces to cause normal calls to 
> explicit_bzero to end up calling the implementation-namespace version) 
> because of concerns about interposition.

Oh, right, that.  I think I should reply directly to Florian's proposal
for impl-namespace names for all new symbols; I'm not convinced it's a
good idea.  I'd feel better about it if __REDIRECT could be implemented
using only ISO C facilities, but I'd still be somewhat dubious.

>>    The impl-namespace symbol is versioned GLIBC_2.25 instead of
>>    GLIBC_PRIVATE, because that seems to be what was done for other
>>    impl-namespace aliases for string functions.  I wasn't able to find
>>    anything definitive about when GLIBC_PRIVATE should be used.
> 
> We need an implementation-namespace export for libcrypt use for namespace 
> reasons [*].

That's what I thought.

> If it's only for libcrypt use, GLIBC_PRIVATE would suffice.  If we want to 
> support it for other libraries limiting the namespace they use, with or 
> without header pieces to protect against accidental interposition, a 
> GLIBC_2.25 export is needed.

It does seem to me that e.g. libssl might want to take defensive
measures against a broken explicit_bzero in the main executable.

> I'd expect a NEWS entry to be included somewhere in the patch series.

I have been holding off on writing one until it was clear that the
_feature_ was going to be accepted.  Have we reached that point?

zw