unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
To: libc-alpha@sourceware.org
Subject: Re: [RFC PATCH 00/11] Library OS support
Date: Tue, 17 Sep 2019 10:19:43 -0300	[thread overview]
Message-ID: <979e6dab-cc06-01a6-e4b5-26b0b559f21d@linaro.org> (raw)
In-Reply-To: <cover.1568219399.git.isaku.yamahata@gmail.com>



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.

      parent reply	other threads:[~2019-09-17 13:19 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-11 21:03 [RFC PATCH 00/11] Library OS support Isaku Yamahata
2019-09-11 21:03 ` [RFC PATCH 01/11] x86-64, elf: make elf_machine_lazy_rel() ignore R_X86_64_NONE Isaku Yamahata
2019-09-11 21:04 ` [RFC PATCH 02/11] elf: add macro to define note section for LibOS Isaku Yamahata
2019-09-11 21:04 ` [RFC PATCH 03/11] elf: " Isaku Yamahata
2019-09-11 21:04 ` [RFC PATCH 04/11] elf: add stub functions for LibOS support Isaku Yamahata
2019-09-11 21:04 ` [RFC PATCH 05/11] elf: add hook, __libos_map_library to dl-open.c Isaku Yamahata
2019-09-11 21:04 ` [RFC PATCH 06/11] elf/rtld: introduce runtime option to disable HP_TIMING_INLINE Isaku Yamahata
2019-09-11 21:04 ` [RFC PATCH 07/11] malloc: make arena size configurable on startup Isaku Yamahata
2019-09-12  1:03   ` DJ Delorie
2019-09-12 18:43     ` Isaku Yamahata
2019-09-11 21:04 ` [RFC PATCH 08/11] x86-64: replace syscall instruction with SYSCALL_INST macro Isaku Yamahata
2019-09-11 21:04 ` [RFC PATCH 09/11] x86-64: add nop instruction after syscall instrunction Isaku Yamahata
2019-09-11 21:04 ` [RFC PATCH 10/11] x86-64: make the number of nops after syscall configurable Isaku Yamahata
2019-09-11 21:04 ` [RFC PATCH 11/11] benchtests: simple benchmark to measure nop effects Isaku Yamahata
2019-09-11 21:35   ` Patrick McGehearty
2019-09-12  0:10 ` [RFC PATCH 00/11] Library OS support Joseph Myers
2019-09-12  1:13   ` Isaku Yamahata
2019-09-16 20:47     ` Joseph Myers
2019-09-17 17:46       ` Isaku Yamahata
2019-09-17 13:19 ` Adhemerval Zanella [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/libc/involved.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=979e6dab-cc06-01a6-e4b5-26b0b559f21d@linaro.org \
    --to=adhemerval.zanella@linaro.org \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).