klibc - Jul 2020 - [PATCH] Add syscall wrappers required by libkeyutils

On Saturday, 25 July 2020, 23:36:33 CEST, Ben Hutchings
wrote:
> On Wed, 2020-07-08 at 08:37 +0200, Christian Eggers wrote:
> > ...
> > libkeyutils usually invokes syscall() directly. As syscall() is not
> > provided by klibc, libkeyutils has to be slightly modified for using
the
> > klibc wrappers.
>
> Wouldn't it be more useful for klibc to implement syscall() then?
I hope that somebody else could respond to this question as I am likely not
skilled enough to answer this.

For me it looks like there are currently two cases of using syscalls in klibc:
1. Exporting stubs directly: For many syscalls, automatically generated stubs
are directly exported as symbols for use by the linker. Examples: setpgid()/
getpgid()

2. Using stubs internally for implementing public function. The auto generated
stub is used as base for implementing a C library function. Example: exit()

For both cases, the code for the individual stubs is auto generated using a
perl script (with an arch specific "plugin"). All generated stubs call
common
arch specific assembly code (__syscall_common).

The lack of the syscall function itself lead me to the (probably wrong)
conclusion that this is "by design". Should all syscalls use the
generated
stubs?

There are some syscalls which are traditionally not implemented by C libraries
(like keyctl, add_key and request_key). These functions are required for
mounting encrypted / authenticated (root) file systems. Programs using this
functionality call syscall() directly. Providing a syscall function in klibc
would avoid klibc specific modifications of such software.

Are there reasons for NOT providing the syscall() function in klibc? Who is
able to implement syscall() for klibc?

regards
Christian



________________________________
 [http://assets.arri.com/media/sign/2020-04-03-E-mail-signature-Stellar2_V1.jpg]
<https://microsites.arri.com/stellar/>

Get all the latest information from www.arri.com<https://www.arri.com/>,
Facebook<https://www.facebook.com/TeamARRI>,
Twitter<https://twitter.com/ARRIChannel>,
Instagram<https://instagram.com/arri> and
YouTube<https://www.youtube.com/user/ARRIChannel>.

Arnold & Richter Cine Technik GmbH & Co. Betriebs KG
Sitz: M?nchen - Registergericht: Amtsgericht M?nchen - Handelsregisternummer:
HRA 57918
Pers?nlich haftender Gesellschafter: Arnold & Richter Cine Technik GmbH
Sitz: M?nchen - Registergericht: Amtsgericht M?nchen - Handelsregisternummer:
HRB 54477
Gesch?ftsf?hrer: Dr. Michael Neuh?user; Stephan Schenk; Walter Trauninger;
Markus Zeiler

On July 27, 2020 2:43:36 AM PDT, Christian Eggers <ceggers at arri.de>
wrote:
>On Saturday, 25 July 2020, 23:36:33 CEST, Ben Hutchings wrote:
>> On Wed, 2020-07-08 at 08:37 +0200, Christian Eggers wrote:
>> > ...
>> > libkeyutils usually invokes syscall() directly. As syscall() is
not
>> > provided by klibc, libkeyutils has to be slightly modified for
>using the
>> > klibc wrappers.
>>
>> Wouldn't it be more useful for klibc to implement syscall() then?
>
>I hope that somebody else could respond to this question as I am likely
>not
>skilled enough to answer this.
>
>For me it looks like there are currently two cases of using syscalls in
>klibc:
>1. Exporting stubs directly: For many syscalls, automatically generated
>stubs
>are directly exported as symbols for use by the linker. Examples:
>setpgid()/
>getpgid()
>
>2. Using stubs internally for implementing public function. The auto
>generated
>stub is used as base for implementing a C library function. Example:
>exit()
>
>For both cases, the code for the individual stubs is auto generated
>using a
>perl script (with an arch specific "plugin"). All generated stubs
call
>common
>arch specific assembly code (__syscall_common).
>
>The lack of the syscall function itself lead me to the (probably wrong)
>conclusion that this is "by design". Should all syscalls use the
>generated
>stubs?
>
>There are some syscalls which are traditionally not implemented by C
>libraries
>(like keyctl, add_key and request_key). These functions are required
>for
>mounting encrypted / authenticated (root) file systems. Programs using
>this
>functionality call syscall() directly. Providing a syscall function in
>klibc
>would avoid klibc specific modifications of such software.
>
>Are there reasons for NOT providing the syscall() function in klibc?
>Who is
>able to implement syscall() for klibc?
>
>regards
>Christian
>
>
>
>________________________________
>[http://assets.arri.com/media/sign/2020-04-03-E-mail-signature-Stellar2_V1.jpg]
><https://microsites.arri.com/stellar/>
>
>Get all the latest information from
>www.arri.com<https://www.arri.com/>,
>Facebook<https://www.facebook.com/TeamARRI>,
>Twitter<https://twitter.com/ARRIChannel>,
>Instagram<https://instagram.com/arri> and
>YouTube<https://www.youtube.com/user/ARRIChannel>.
>
>Arnold & Richter Cine Technik GmbH & Co. Betriebs KG
>Sitz: M?nchen - Registergericht: Amtsgericht M?nchen -
>Handelsregisternummer: HRA 57918
>Pers?nlich haftender Gesellschafter: Arnold & Richter Cine Technik GmbH
>Sitz: M?nchen - Registergericht: Amtsgericht M?nchen -
>Handelsregisternummer: HRB 54477
>Gesch?ftsf?hrer: Dr. Michael Neuh?user; Stephan Schenk; Walter
>Trauninger; Markus Zeiler
syscall(3) is not implemented by design, because it is silently broken on many
architectures (mainly 32-bit ones.)
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

hpa at zytor.com dixit:
>syscall(3) is not implemented by design, because it is silently broken
>on many architectures (mainly 32-bit ones.)
It?s also where most libcs break on various ports most often,
because it?s surprisingly tricky to get right.

bye,
//mirabilos
--  
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival

On Mon, 2020-07-27 at 05:46 -0700, hpa at zytor.com
wrote:
> On July 27, 2020 2:43:36 AM PDT, Christian Eggers <ceggers at
arri.de> wrote:
> > On Saturday, 25 July 2020, 23:36:33 CEST, Ben Hutchings wrote:
> > > On Wed, 2020-07-08 at 08:37 +0200, Christian Eggers wrote:
> > > > ...
> > > > libkeyutils usually invokes syscall() directly. As syscall()
is not
> > > > provided by klibc, libkeyutils has to be slightly modified
for using the
> > > > klibc wrappers.
> > > 
> > > Wouldn't it be more useful for klibc to implement syscall()
then?
> > 
> > I hope that somebody else could respond to this question as I am
likely not
> > skilled enough to answer this.
[...]
> syscall(3) is not implemented by design, because it is silently
> broken on many architectures (mainly 32-bit ones.)
I understand that it's not portable in general, as there are many
architecture-specific quirks in the system call ABI.  But where there
are other established libraries using it, I assume they're already
dealing with those quirks.  Also, the newer system calls that are
likely to be called this way are less quirky, aren't they?

I think that if we can *cheaply* implement a glibc API that allows more
software to build and run on klibc with fewer changes, then we should.

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
                                                       - Robert Coveyou


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL:
<https://lists.zytor.com/archives/klibc/attachments/20200728/89607ba8/attachment.sig>