Re: [RFC PATCH 00/11] Library OS support

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 11/09/2019 18:03, Isaku Yamahata wrote:
> This patch is to add Library OS(LibOS in short) to glibc.
> This is the first version of patch series to support LibOS.

This patchset along the Cauldron presentation give me the impression
it is really tuned to a very specific usercase (x86_64 SGX) rather than
a more generic port. For instance, I am not really sure that ignoring
dynamic R_X86_64_NONE is really the best behaviour in generic x86_64
ABI (it is for most in cases an invalid relocation).

But the main problem, as we discussed briefly on GNU Cauldron, is this
essentially brings back text relocation albeit in a different form
(libOS runtime would be the one that actually rewrite the text segment).
This lowers the memory scalability and might poses some security issues
for generic cases (excluding SGX like usage).  It might not be a problem
to SGX enclaves, but this is most likely for generic case.

Another issue is if this would be another research-like projects that
might be replaced/abandoned once a better hardware extension is available.
For instance, an architecture extension might provide a way the guest 
configure the syscall mechanism where instead of changing the to kernel
mode it calls the {uni}kernel functions directly. 

Also, some requirements such the malloc arena size restriction could be
really implemented in the libOS runtime since it would be one responsible
for the sbrk/mmap syscall (it can track and return -1/ENOMEM when a call
can not be done). Another patch piece that might add even more complexity
is '--enable-libos-num-nops', where in my understanding would possible
that libOS might fail to load older glibc if it does not have sufficient
nops on the syscalls marking (adding compatibility layer, where although
not glibc specific is another runtime issue).

All these points make me wonder if would be better to make libOS an 
specific target and move all the required bits to system specific
files.