Re: [RFC 0/2] __vdso_findsym

[H. Peter Anvin]

Symbol versioning so we can rev the ABI and still provide backwards compatibility.  Weak symbols so the libc can override symbols if it considers it appropriate.  This is a good thing.

On June 15, 2014 11:20:41 AM PDT, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
>cc: Andi Kleen, who designed the vdso
>
>On Sun, Jun 15, 2014 at 10:57 AM, H. Peter Anvin <hpa@xxxxxxxxx> wrote:
>> On 06/15/2014 10:40 AM, Andy Lutomirski wrote:
>>>
>>> To be clear, I have no desire whatsoever to give the vdso an actual
>>> ELF parser or anything else that userspace should be providing
>itself.
>>> I think that a special-purpose vdso parser in the vdso makes some
>>> sense, though, since userspace might otherwise provide one for the
>>> sole purpose of parsing the vdso.
>>>
>>> And there's plenty of reasons that having the vdso be an ELF image
>is
>>> useful.  For one thing, gdb can take advantage of it.  For another,
>>> CRIU is parsing it for a rather different reason, and something like
>>> __vdso_findsym won't fill that need.
>>>
>>> Also, given the general lack of a comprehensible specification of
>what
>>> the GNU flavor of the ELF format actually is [1], there's something
>to
>>> be said for reducing the proliferation of ELF parsers.  glibc and
>>> binutils are quite unlikely to become incompatible with each other,
>>> but I sincerely doubt that anyone from binutils land is likely to
>>> review (and maintain!) my ELF parser, Go's, or a hypothetical future
>>> ELF parser from any of the other glibc-less things.  If those things
>>> use one that's in the kernel, then it's easy for the kernel to
>>> guarantee that each vdso image can successfully parse itself.
>>>
>>> [1] The only comprehensible description of the GNU hash extension
>that
>>> I could find is on Oracle's blog (!)
>>>
>>
>> Yes, but that is why we provide the standard SysV hash.  The GNU hash
>is
>> not too bad, but you're absolutely right the documentation stinks.
>>
>> Providing a simple symbol lookup is an opportunistic thing, and might
>be
>> useful that way, and only because (as you say) the version in the
>vdso
>> would only need to be guaranteed to parse a single data structure --
>> that same vdso.
>>
>> On the other hand, it better work, correctly, in every version of the
>> kernel, so I believe it will need to be done such that it is either
>> correct by construction or gets self-tested during the build process
>so
>> it errors out on failure.
>
>I was thinking of adding something to selftests that would check that
>__vdso_findsym can find every exported symbol, check that it can't
>find the ones it shouldn't find, and call it on a bunch of garbage
>strings to make sure it rejects them.
>
>
>> One simple way to do correct by construction
>> would be to do the "vdso entry point by index" -- a new kind of
>system
>> call numbers, in effect, as much as it has shades of Windows DLL with
>> their "ordinal numbers".
>
>It's certainly easy.  It's a little gross, and I sort of feel bad
>about having two parallel ways of referring to a vdso function -- one
>used by ELF parsers and one used by the new thing.  Using an array
>also wins on speed and code size.  *sigh* -- I'm torn on this one.
>
>Do you know why the vdso uses symbol versioning and weak symbols in
>the first place?  This seems to date back all the way to the beginning
>(2aae950b21e4bc789d1fc6668faf67e8748300b7).  If we're going to add a
>new way to find vdso symbols, I would like to at least drop support
>for versions.
>
>--Andy

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/