Do we need the bootstrap if we compile the loader statically?

[illwieckz]

On all platforms but Linux, no bootstrap is used. And in fact using the Windows loader on Linux will not use any bootstrap.

Maybe I'm wrong, but I suspect the bootstrap is there because we need to reserve some memory before the ld loader does some stuff.

But if the loader is statically compiled, the ld loader will do nothing.

In my branches I investigated building a static loader, but this was only on purpose to be able to redistribute a loader without libs (to make armhf multiarch works out of the box, this would also help box64 to not bundle libs). This was not done to remove the bootstrap, and unfortunately on arm, the bootstrap fails to load the static loader.

Now, if using a static loader removes the need for a bootstrap, then we don't have to care about the bootstrap not loading a static loader.

So:

• is this true we don't need a bootstrap if the loader is fully static ?
• do we need the loader to be a dynamic executable ?

On Linux it's common practice to dynamically link binaries because the glibc loads stuff at runtime. But maybe we don't need what glibc loads at runtime to begin with.

[slipher]

There's a patchwork of different tricks to secure the address space depending on the platform. On 64-bit platforms bootstrap memory reservation is not needed since it is easy to grab a continuous 4GiB block. On x86 segmented memory tricks are used to prevent the untrusted code from breaking out. But maybe a bootstrap is still needed to ensure a large enough range of contiguous memory for the app? On ARM neither of those strategies is possible, so the bootstrap is most needed. On Windows and Mac there is no stable syscall interface, so making a fully static executable as needed for the bootstrap is not possible.

https://stackoverflow.com/questions/57476533/why-is-statically-linking-glibc-discouraged shows a lot of reasons to avoid statically linking glibc. I think the loader uses tons of different APIs, though we don't use all of them in Daemon. If you want to statically link the C runtime musl is the way to go. I think that would be viable, as long as there aren't any annoying allocations in startup routines.

If you're concerned about the 16k page size issue with the bootstrap, I think I have enough knowledge now to solve that in a few more hours of work. I've studied the loader's allocation code and learned how to build kernels. Just prioritizing Windows right now.

[illwieckz]

OK, I now have done some research too (with less understanding as you) and I was also afraid that arm had some specificity, for example it doesn't have alternate code when !NaClFindPrereservedSandboxMemory(), though I didn't knew if that was just not implemented or not implementable.

We know how to bundle the libs and set the ld-loader on multiarch so we can live with the loader being dynamic, but I was still wondering if we could remove this annoyance.

If you're concerned about the 16k page size issue with the bootstrap, I think I have enough knowledge now to solve that in a few more hours of work. I've studied the loader's allocation code and learned how to build kernels. Just prioritizing Windows right now.

That would be very good.

[illwieckz]

On my end with my patch plus trixie libs the dynamic loader with bootstrap already works on 16k pagesize arm64 kernel, but it's probable I missed some stuff and not everything is fixed and I'm just lucky.