[set,get,make,swap]context from glibc for amd64 implementation and question for Norman

[Josef Söntgen]

Hello Alexander,

> as a base I borrow some code from glibc, and remove related files
> (mostly _ucontext.h/ucontext.h) from genode
> 
>> May I ask what is the reason for choosing and incorporating the glibc
>> implementation rather than using/enabling the one in the FreeBSD libc?
> 
> 1. current implementation of context switch in FreeBSD done completely
> in kernel via sys call. E.g. this is full code of getcontext function
> (stored in genode, not used):

> […]

> 2. context family support do require complex and misleading structure,
> e.g. take a look for setcontext code:

> […]

> 3. ucontext.h and related is isolated in current libc and could be
> easily replaced (because it used only in *context family of functions
> and signals which has only rudimentary support
> 
> 4. glibc implementation is straightforward and well supported,
> relatively small and suitable for big set of platforms, without
> complex kernel/__libc_interposing analogous and could be borrowed
> (copied) with minimal efforts, I can confirm this.
> 
> 5. glibc implementation of these functions do contain potentially
> useful security feature of shadow stack support (under SHSTK_ENABLED
> define - not enabled in my patch)
> 
> So, I consider option to use existing freeBSD version and replacement
> of code of functions to ones from glibc - and think that this make
> everything too complex, related infrastructure not clear and not easy
> to support. May be I am wrong.
> 
> for me simplest for implementation and, especially, for future support
> - is chosen approach (with part of glibc port). It is simple and
> straightforward, easy to extend to arm/etc.
> 
> Another option I consider is a usage of native context-switch
> functions for genode low level Os (OS - dependent). Anyway, it will
> significantly lower performance, and not portable option, so, I do not
> choose it.
> 
>> Strictly speaking containg such a large patch makes the commit
>> unsuitable for the Genode main repo as the burden of maintaing it
>> falls on our shoulders at the end and the reason for including it in the
>> first place is not immediately clear.
> 
> significant part of patch is a removal of old files like ucontext.h
> and plain addition of new files, take a look for statistics, no
> complex updates of files involved:

> […]

> By the way, I can make patch smaller if you give me a direction how to
> remove some files during install or patch process without patch
> itself, may be via .mk file (e.g. libc-gen.mk)

Thanks for the thorough answer, which puts things into perspective. We
briefly discussed the matter offline and somehow implementing the API
with a mechanism that is already there (e.g. the setjmp/longjmp based
task model that we use in various drivers and the libc) feels more
natural. That being said, we do not know if there are any requirements
in the *context API that would prevent us from going down that road.

Do you know of any, besides the potentially worse performance?

>> For better or worse, we still lack the resources (read man-power) as well
>> as a deeper understanding for the issues at hand when it comes to the
>> requirements of the golang-runtime (which somewhat is a consequence of
>> the lack of resources) that such an undertaking arguably deserves.
> 
> I need *context() implementation, and it can’t be moved to world
> repository - its a part of libc.
> 
> Also to use functions I need C interface for allocate_seconday_stack()
> which should be somewhere inside (I choose libc
> dummies.cc<http://dummies.cc> file)
> Question: may be better other place? e.g. inline C interface function
> as a part of e.g. thread.h?  Any recommendations are welcome!
> 
> I understand your point, so, another question is: how I can continue
> if patch can’t be stored inside genode core? it can’t be significantly
> smaller (4 functions/files to be add at least)...
> 
> Everything else for golang support I will have in world, this is the
> only part of core (may be together with extended anonymous mmap
> support).

Judging by the freestanding nature of the '*context()' implementation
should it not be possible to get away with putting it into world as well?
For example as part of a supplementary static run-time library that shadows
the libc by resolving everything locally, including the stack functions.


Regards Josef

-- 
Josef Söntgen
Genode Labs

http://www.genode-labs.com/ · http://genode.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.genode.org/pipermail/users/attachments/20210316/5ced39e3/attachment.sig>