__vdso_findsym

The idea is to add AT_VDSO_FINDSYM pointing at __vdso_findsym. This implements __vdso_findsym.

This would make it easier for runtimes that don't otherwise implement ELF loaders to use the vdso.

Thoughts?

If people like the basic concept, I'll finish it, write up documentation and a selftest. If people don't like it, I'll drop it.

Quoted 10 lines · Andy Lutomirski

The idea is to add AT_VDSO_FINDSYM pointing at __vdso_findsym. This implements __vdso_findsym.

This would make it easier for runtimes that don't otherwise implement ELF loaders to use the vdso.

Thoughts?

If people like the basic concept, I'll finish it, write up documentation and a selftest. If people don't like it, I'll drop it.

I like the idea. I don't think it's immediately useful, since libraries wanting to use vdso will likely want to support older kernels that don't yet have this, and thus need to include their own vdso parsing code. However, if we could get this in now, it would be very useful a few years down the line where optimizing for old kernels is not an important goal. I'd certainly like to be able to drop the ELF parsing code from musl to reduce static binary size. And I could see other projects possibly using it just to avoid the issue of ever adding ELF parsing code in the first place.

Hmm. I hadn't thought of this as a size win, but I guess it could be if there are static binaries around.

This patch currently generates 488 bytes on text with my toolchain. More than half of that is garbage needed to deal with the symbol version tables, and I should be able to move a decent fraction of it to vdso2c and therefore out of the kernel and vdso images.

Now, if we can do this without adding another page then that becomes much more compelling IMO. I suspect we can if you are already down to 488 bytes.

Quoted 5 lines · H. Peter Anvin

Now, if we can do this without adding another page then that becomes much more compelling IMO. I suspect we can if you are already down to 488 bytes.

(If it isn't already the case, was inteded to be part of that...)

The idea is to add AT_VDSO_FINDSYM pointing at __vdso_findsym. This implements __vdso_findsym.

This would make it easier for runtimes that don't otherwise implement ELF loaders to use the vdso.

Thoughts?

Quoted 6 lines · Andy Lutomirski

The idea is to add AT_VDSO_FINDSYM pointing at __vdso_findsym. This implements __vdso_findsym.

This would make it easier for runtimes that don't otherwise implement ELF loaders to use the vdso.

Quoted 1 line

Thoughts?

I'm opposed to this based on the principle that the kernel should NOT be a dumping ground for random code that user-space can and should implement for itself. As long as the vdso is correctly formatted ELF, then parsing it is easy, and the kernel should not care at all if or how user-space accesses it.

Quoted 7 lines · Mikael Pettersson

Quoted 6 lines · Andy Lutomirski

The idea is to add AT_VDSO_FINDSYM pointing at __vdso_findsym. This implements __vdso_findsym.

This would make it easier for runtimes that don't otherwise implement ELF loaders to use the vdso.

Quoted 7 lines

Quoted 1 line

Thoughts?

I'm opposed to this based on the principle that the kernel should NOT be a dumping ground for random code that user-space can and should implement for itself. As long as the vdso is correctly formatted ELF, then parsing it is easy, and the kernel should not care at all if or how user-space accesses it.

Arguably, it was a mistake for the kernel to expose a virtual ELF to begin with, and it should just have exposed a "lookup function by name" operation to begin with. Yes this can be done in userspace, but I see it more as a matter of "fixing a broken API design".

Arguably, it was a mistake for the kernel to expose a virtual ELF to begin with, and it should just have exposed a "lookup function by name" operation to begin with. Yes this can be done in userspace, but I see it more as a matter of "fixing a broken API design".

Quoted 6 lines · Rich Felker

Arguably, it was a mistake for the kernel to expose a virtual ELF to begin with, and it should just have exposed a "lookup function by name" operation to begin with. Yes this can be done in userspace, but I see it more as a matter of "fixing a broken API design".

What the fsck are you smoking? There is immense value in providing a stable and very well-defined data structure, which also happens to be what dynamic linkers already want to consume. Providing a helper for crippled libc applications has potential value. Shaving a few hundred bytes off static applications is a very weak argument, simply because it is such a small fraction of the enormous cost of a static application, and static applications are problematic in a number of other ways, especially the lack of ability to fix bugs.

Treating the kernel as an ersatz dynamic library for "static" applications is kind of silly -- after all, why not provide an entire libc in the vdso? I have actually seen people advocate for doing that.

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 (!)

Quoted 22 lines · Andy Lutomirski

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.

Quoted 3 lines

[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.

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".

cc Andi Kleen, who designed the vdso

Quoted 4 lines · H. Peter Anvin

Quoted 3 lines · Andy Lutomirski

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.

Quoted 5 lines

Quoted 5 lines

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

Quoted 5 lines

Quoted 5 lines

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

Quoted 1 line

Quoted 1 line

the GNU flavor of the ELF format actually is [1], there's something

to

Quoted 9 lines

Quoted 9 lines

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

Quoted 4 lines

Quoted 2 lines

I could find is on Oracle's blog (!)

Yes, but that is why we provide the standard SysV hash. The GNU hash

is

Quoted 3 lines

not too bad, but you're absolutely right the documentation stinks.

Providing a simple symbol lookup is an opportunistic thing, and might

be

Quoted 1 line

useful that way, and only because (as you say) the version in the

vdso

Quoted 6 lines

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

Quoted 1 line

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.

Quoted 2 lines

One simple way to do correct by construction
would be to do the "vdso entry point by index" -- a new kind of

system

Quoted 2 lines

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

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.

Quoted 1 line · 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.

Are we ever going to change, say, the __vdso_clock_gettime ABI without renaming the function? If we want to preserve that ability, I can keep support for versions, but it seems odd.

I don't buy the weak symbol argument at all. We currently expose a strong symbol __vdso_clock_gettime and a weak alias clock_gettime. I agree that, if glibc treats us as a real DSO, then clock_gettime can't be strong, but I don't see why it should exist at all (other than for backwards compatibility).

--Andy

If it doesn't, then you incur an additional indirection penalty. The strong __vdso symbol allows the libc wrapper to fall back to the vdso implementation, the weak symbol allows three to be no wrapper at all. This is good.

The reason for changing ABI would be shifting types. This is very much how glibc manages transitions.

Quoted 2 lines · H. Peter Anvin

If it doesn't, then you incur an additional indirection penalty. The

strong __vdso symbol allows the libc wrapper to fall back to the vdso implementation, the weak symbol allows three to be no wrapper at all. This is good.

Quoted 2 lines

The reason for changing ABI would be shifting types. This is very

much how glibc manages transitions.

The purpose of symbol versioning is so that symbols with well known names, like stat, can continue to use those same names while changing types. Both old and new programs can continue to use the name stat and continue to work even though they use different types.

I don't see how this applies to the kernel VDSO. Those symbols do not use well-known names; they use names like __vdso_time. If you change the types used by those symbols, you can change the name as well. What is the downside?

Ian

The weak symbols are well-known names. The __vdso symbols are strong.

Quoted 15 lines · H. Peter Anvin

Quoted 2 lines

If it doesn't, then you incur an additional indirection penalty. The

strong __vdso symbol allows the libc wrapper to fall back to the vdso implementation, the weak symbol allows three to be no wrapper at all. This is good.

Quoted 2 lines

The reason for changing ABI would be shifting types. This is very

much how glibc manages transitions.

The purpose of symbol versioning is so that symbols with well known names, like stat, can continue to use those same names while changing types. Both old and new programs can continue to use the name stat and continue to work even though they use different types.

Quoted 6 lines

I don't see how this applies to the kernel VDSO. Those symbols do not use well-known names; they use names like __vdso_time. If you change the types used by those symbols, you can change the name as well. What is the downside?

Ian

--
Sent from my mobile phone. Please pardon brevity and lack of formatting.

Quoted 1 line · H. Peter Anvin

The weak symbols are well-known names. The __vdso symbols are

strong.

I see. But I don't understand how this is supposed to work. When I link a program against gettimeofday, I get a reference to gettimeofday with version GLIBC_2.2.5. After all, I only link against libc.so; I don't link against the vDSO. The VDSO provides gettimeofday with version LINUX_2.6. Since those versions don't match, the gettimeofday reference in my executable will not be satisfied by the definition in the vDSO. So at dynamic link time my program is always going to be linked with the gettimeofday in libc.so, which will in turn call the gettimeofday in the vDSO.

Am I missing something that makes the definition of gettimeofday with version LINUX_2.6 in the vDSO useful?

Ian

Quoted 1 line

On June 15, 2014 12:22:17 PM PDT, Ian Lance Taylor <[email protected]>

Quoted 1 line · wrote:

Quoted 1 line

On Sun, Jun 15, 2014 at 12:14 PM, H. Peter Anvin <[email protected]>

Quoted 2 lines · wrote:

Quoted 2 lines

Quoted 2 lines

If it doesn't, then you incur an additional indirection penalty.

The

Quoted 5 lines

Quoted 5 lines

strong __vdso symbol allows the libc wrapper to fall back to the vdso implementation, the weak symbol allows three to be no wrapper at all. This is good.

Quoted 2 lines

The reason for changing ABI would be shifting types. This is very

Quoted 8 lines

Quoted 8 lines

much how glibc manages transitions.

The purpose of symbol versioning is so that symbols with well known names, like stat, can continue to use those same names while changing types. Both old and new programs can continue to use the name stat and continue to work even though they use different types.

I don't see how this applies to the kernel VDSO. Those symbols do

not

Quoted 8 lines

Quoted 5 lines

use well-known names; they use names like __vdso_time. If you change the types used by those symbols, you can change the name as well. What is the downside?

Ian

--
Sent from my mobile phone. Please pardon brevity and lack of

formatting.

You can link against vdso.so if you want to; the kernel build provides an option to install that image. Doesn't mean that any particular libc uses it.

Quoted 1 line · H. Peter Anvin

You can link against vdso.so if you want to; the kernel build

provides an option to install that image. Doesn't mean that any particular libc uses it.

I'd be rather surprised if anyone does this, given the generally spotty state of vdso.so installation and that there's no such thing as an ELF import library.

Also, the vdso's clock_gettime isn't actually compatible with glibc/POSIX -- the return value and errno handling don't match.

--Andy

If it doesn't, then you incur an additional indirection penalty. The strong __vdso symbol allows the libc wrapper to fall back to the vdso implementation, the weak symbol allows three to be no wrapper at all. This is good.

At least versioning is always useful to have, just to have another tool for compatibility if changes are needed.

I haven't looked into this in detail, but my initial assumption would be that it wouldn't be useful to add new vdso interfaces just for Go. After all would you really want to force ever Go user to upgrade their kernel just to get fast fime? So it has to work with whatever is already there anyways.

I think this issue started when some of the Go developers questioned why the kernel needed to provide a very complex interface--parsing an ELF shared shared library--for very simple functionality--looking up the address of a magic function. This approach has required special support not just in Go, but also in the dynamic linker and gdb, and does not work well for statically linked binaries. The support in gdb is perhaps a good idea, but elsewhere it does not make sense.

So why not provide a simple interface?

Quoted 8 lines

I think this issue started when some of the Go developers questioned why the kernel needed to provide a very complex interface--parsing an ELF shared shared library--for very simple functionality--looking up the address of a magic function. This approach has required special support not just in Go, but also in the dynamic linker and gdb, and does not work well for statically linked binaries. The support in gdb is perhaps a good idea, but elsewhere it does not make sense.

Quoted 1 line

So why not provide a simple interface?

What good would it do now that everyone already supports it?

The proposal is 10+ years too late.

Quoted 9 lines

I think this issue started when some of the Go developers questioned why the kernel needed to provide a very complex interface--parsing an ELF shared shared library--for very simple functionality--looking up the address of a magic function. This approach has required special support not just in Go, but also in the dynamic linker and gdb, and does not work well for statically linked binaries. The support in gdb is perhaps a good idea, but elsewhere it does not make sense.

So why not provide a simple interface?

What good would it do now that everyone already supports it?

Quoted 8 lines · Andi Kleen

Quoted 8 lines

I think this issue started when some of the Go developers questioned why the kernel needed to provide a very complex interface--parsing an ELF shared shared library--for very simple functionality--looking up the address of a magic function. This approach has required special support not just in Go, but also in the dynamic linker and gdb, and does not work well for statically linked binaries. The support in gdb is perhaps a good idea, but elsewhere it does not make sense.

Quoted 3 lines

Quoted 1 line

So why not provide a simple interface?

What good would it do now that everyone already supports it?

Do statically linked binaries use the vDSO calls?

Quoted 9 lines · Ian Lance Taylor

Quoted 8 lines · Andi Kleen

Quoted 8 lines

I think this issue started when some of the Go developers questioned why the kernel needed to provide a very complex interface--parsing an ELF shared shared library--for very simple functionality--looking up the address of a magic function. This approach has required special support not just in Go, but also in the dynamic linker and gdb, and does not work well for statically linked binaries. The support in gdb is perhaps a good idea, but elsewhere it does not make sense.

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

So why not provide a simple interface?

What good would it do now that everyone already supports it?

Do statically linked binaries use the vDSO calls?

Under glibc, I believe so (not checked). Under musl, yes, and even in the dynamic-linked case we use the same code that's used for static linking rather than trying to get the dynamic linker to do them correctly. I still have some cruft lying around from where (in the past) we tried to do it via the dynamic linker, but I'm probably going to remove that and make the vdso behave as RTLD_LOCAL so that there's no risk of weird symbols it exports interfering with the application (applications could still make it global via an explicit dlopen). The only reason for keeping it around at all in the dynamic linker is for the sake of gdb.

Quoted 16 lines · Rich Felker

Quoted 9 lines · Ian Lance Taylor

Quoted 8 lines · Andi Kleen

Quoted 8 lines

I think this issue started when some of the Go developers questioned why the kernel needed to provide a very complex interface--parsing an ELF shared shared library--for very simple functionality--looking up the address of a magic function. This approach has required special support not just in Go, but also in the dynamic linker and gdb, and does not work well for statically linked binaries. The support in gdb is perhaps a good idea, but elsewhere it does not make sense.

Quoted 5 lines

Quoted 3 lines

Quoted 1 line

So why not provide a simple interface?

What good would it do now that everyone already supports it?

Do statically linked binaries use the vDSO calls?

Quoted 10 lines

Under glibc, I believe so (not checked). Under musl, yes, and even in the dynamic-linked case we use the same code that's used for static linking rather than trying to get the dynamic linker to do them correctly. I still have some cruft lying around from where (in the past) we tried to do it via the dynamic linker, but I'm probably going to remove that and make the vdso behave as RTLD_LOCAL so that there's no risk of weird symbols it exports interfering with the application (applications could still make it global via an explicit dlopen). The only reason for keeping it around at all in the dynamic linker is for the sake of gdb.

What about backtrace_symbols, dl_addr, and the unwinder (e.g. siglongjmp)? It would be nice to wean the vdso off of frame pointers some day.

Quoted 6 lines · Andi Kleen

I haven't looked into this in detail, but my initial assumption would be that it wouldn't be useful to add new vdso interfaces just for Go. After all would you really want to force ever Go user to upgrade their kernel just to get fast fime? So it has to work with whatever is already there anyways.

Go works fine with the current interface. There was, arguably, a bug in Go's old implementation in that it assumed that the vDSO would have a normal symbol table. That bug has already been fixed.

I think this issue started when some of the Go developers questioned why the kernel needed to provide a very complex interface--parsing an ELF shared shared library--for very simple functionality--looking up the address of a magic function. This approach has required special support not just in Go, but also in the dynamic linker and gdb, and does not work well for statically linked binaries. The support in gdb is perhaps a good idea, but elsewhere it does not make sense.

So why not provide a simple interface?

Quoted 5 lines · H. Peter Anvin

Quoted 4 lines · Rich Felker

Arguably, it was a mistake for the kernel to expose a virtual ELF to begin with, and it should just have exposed a "lookup function by name" operation to begin with. Yes this can be done in userspace,

but

Quoted 7 lines

Quoted 2 lines

I see it more as a matter of "fixing a broken API design".

What the fsck are you smoking? There is immense value in providing a stable and very well-defined data structure, which also happens to be what dynamic linkers already want to consume. Providing a helper for crippled libc applications has potential value. Shaving a few

hundred

Quoted 1 line

bytes off static applications is a very weak argument, simply because

it

Quoted 1 line

is such a small fraction of the enormous cost of a static

application,

Quoted 6 lines

and static applications are problematic in a number of other ways, especially the lack of ability to fix bugs.

Treating the kernel as an ersatz dynamic library for "static" applications is kind of silly -- after all, why not provide an entire libc in the vdso? I have actually seen people advocate for doing

that.

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 (!)

Quoted 48 lines · Andy Lutomirski

Quoted 5 lines · H. Peter Anvin

Quoted 4 lines · Rich Felker

Arguably, it was a mistake for the kernel to expose a virtual ELF to begin with, and it should just have exposed a "lookup function by name" operation to begin with. Yes this can be done in userspace,

but

Quoted 7 lines

Quoted 2 lines

I see it more as a matter of "fixing a broken API design".

What the fsck are you smoking? There is immense value in providing a stable and very well-defined data structure, which also happens to be what dynamic linkers already want to consume. Providing a helper for crippled libc applications has potential value. Shaving a few

hundred

Quoted 1 line

bytes off static applications is a very weak argument, simply because

it

Quoted 1 line

is such a small fraction of the enormous cost of a static

application,

Quoted 6 lines

and static applications are problematic in a number of other ways, especially the lack of ability to fix bugs.

Treating the kernel as an ersatz dynamic library for "static" applications is kind of silly -- after all, why not provide an entire libc in the vdso? I have actually seen people advocate for doing

that.

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.

Quoted 3 lines

[1] The only comprehensible description of the GNU hash extension that I could find is on Oracle's blog (!)

Curious about this blog. We do have a GNU hash implementation in Syslinux, too, for another reference.

Quoted 4 lines

Quoted 3 lines

[1] The only comprehensible description of the GNU hash extension that I could find is on Oracle's blog (!)

Quoted 2 lines

Curious about this blog. We do have a GNU hash implementation in Syslinux, too, for another reference.

https://blogs.oracle.com/ali/entry/gnu_hash_elf_sections

FWIW, I bet that __vdso_findsym could be smaller if it used the GNU hash. Maybe it would save about the same amount of space that turning on the GNU hash would take up.

Quoted 6 lines · Rich Felker

Arguably, it was a mistake for the kernel to expose a virtual ELF to begin with, and it should just have exposed a "lookup function by name" operation to begin with. Yes this can be done in userspace, but I see it more as a matter of "fixing a broken API design".

What the fsck are you smoking? There is immense value in providing a stable and very well-defined data structure,

which also happens to be
what dynamic linkers already want to consume. Providing a helper for crippled libc applications has potential value. Shaving a few hundred bytes off static applications is a very weak argument, simply because it is such a small fraction of the enormous cost of a static application,

and static applications are problematic in a number of other ways, especially the lack of ability to fix bugs.

Treating the kernel as an ersatz dynamic library for "static" applications is kind of silly -- after all, why not provide an entire libc in the vdso? I have actually seen people advocate for doing that.