* Re: Official Linux system wrapper library?
From: Dave Martin @ 2018-11-15 10:33 UTC (permalink / raw)
To: Florian Weimer
Cc: Andy Lutomirski, Daniel Colascione, Michael Kerrisk (man-pages),
linux-kernel, Joel Fernandes, Linux API, Willy Tarreau,
Vlastimil Babka, Carlos O'Donell, libc-alpha@sourceware.org
In-Reply-To: <877ehfdgzn.fsf@oldenburg.str.redhat.com>
On Wed, Nov 14, 2018 at 12:40:44PM +0100, Florian Weimer wrote:
> * Dave Martin:
>
> > Fair points, though this is rather what I meant by "sane essentials".
> > Because there are strict limits on what can be done in the vDSO, it may
> > be more bloat-resistant and more conservatively maintained.
> >
> > This might provide a way to push some dumb compatibility kludge code
> > that receives little ongoing maintenance outside the privilege wall,
> > whereas it has to sit in the kernel proper today.
> >
> > In theory we could opt to advertise new syscalls only via vDSO entry
> > points, and not maintain __NR_xxx values for them (which may or may
> > not upset ptrace users.) Anyway, I digress...
>
> Is the vDSO available across all architectures? (I don't think we use
> it on all architectures in glibc.)
It's probably not available on all arches.
> If not, a vDSO-based approach would merely lead to even more variance
> between architectures, which can't be a good thing.
That's a fair concern.
Channeling syscalls through the vDSO could allow for a uniform syscall
interface at the ELF linkage level, but only those arches that have a
vDSO. There may be other issues too.
Also, I don't say that we should definitely do this, just that it's
a possibility.
Cheers
---Dave
^ permalink raw reply
* Re: [RFC PATCH] mm, proc: report PR_SET_THP_DISABLE in proc
From: Michal Hocko @ 2018-11-15 9:22 UTC (permalink / raw)
To: David Rientjes
Cc: Andrew Morton, Vlastimil Babka, Alexey Dobriyan,
Kirill A. Shutemov, linux-kernel, linux-mm, linux-api
In-Reply-To: <20181115090242.GH23831@dhcp22.suse.cz>
On Thu 15-11-18 10:02:42, Michal Hocko wrote:
> On Wed 14-11-18 13:41:12, David Rientjes wrote:
> > On Wed, 14 Nov 2018, Michal Hocko wrote:
> >
> > > > > > Do you know of any other userspace except your usecase? Is there
> > > > > > anything fundamental that would prevent a proper API adoption for you?
> > > > > >
> > > > >
> > > > > Yes, it would require us to go back in time and build patched binaries.
> > > >
> > > > I read that as there is a fundamental problem to update existing
> > > > binaries. If that is the case then there surely is no way around it
> > > > and another sad page in the screwed up APIs book we provide.
> > > >
> > > > But I was under impression that the SW stack which actually does the
> > > > monitoring is under your controll. Moreover I was under impression that
> > > > you do not use the current vanilla kernel so there is no need for an
> > > > immediate change on your end. It is trivial to come up with a backward
> > > > compatible way to check for the new flag (if it is not present then
> > > > fallback to vma flags).
> > > >
> >
> > The userspace had a single way to determine if thp had been disabled for a
> > specific vma and that was broken with your commit. We have since fixed
> > it. Modifying our software stack to start looking for some field
> > somewhere else will not help anybody else that this has affected or will
> > affect. I'm interested in not breaking userspace, not trying a wait and
> > see approach to see if anybody else complains once we start looking for
> > some other field. The risk outweighs the reward, it already broke us, and
> > I'd prefer not to even open the possibility of breaking anybody else.
>
> I very much agree on "do not break userspace" part but this is kind of
> gray area. VMA flags are a deep internal implementation detail and
> nobody should really depend on it for anything important. The original
> motivation for introducing it was CRIU where it is kind of
> understandable. I would argue they should find a different way but it is
> just too late for them.
>
> For this particular case there was no other bug report except for yours
> and if it is possible to fix it on your end then I would really love to
> make the a sensible user interface to query the status. If we are going
> to change the semantic of the exported flag again then we risk yet
> another breakage.
>
> Therefore I am asking whether changing your particular usecase to a new
> interface is possible because that would allow to have a longerm
> sensible user interface rather than another kludge which still doesn't
> cover all the usecases (e.g. there is no way to reliably query the
> madvise status after your patch).
Btw. this is essentially the same kind of problem as
http://lkml.kernel.org/r/20181002100531.GC4135@quack2.suse.cz
where the conclusion was to come up with a saner interface rather than
mimic the previous one.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [RFC PATCH] mm, proc: report PR_SET_THP_DISABLE in proc
From: Michal Hocko @ 2018-11-15 9:02 UTC (permalink / raw)
To: David Rientjes
Cc: Andrew Morton, Vlastimil Babka, Alexey Dobriyan,
Kirill A. Shutemov, linux-kernel, linux-mm, linux-api
In-Reply-To: <alpine.DEB.2.21.1811141336010.200345@chino.kir.corp.google.com>
On Wed 14-11-18 13:41:12, David Rientjes wrote:
> On Wed, 14 Nov 2018, Michal Hocko wrote:
>
> > > > > Do you know of any other userspace except your usecase? Is there
> > > > > anything fundamental that would prevent a proper API adoption for you?
> > > > >
> > > >
> > > > Yes, it would require us to go back in time and build patched binaries.
> > >
> > > I read that as there is a fundamental problem to update existing
> > > binaries. If that is the case then there surely is no way around it
> > > and another sad page in the screwed up APIs book we provide.
> > >
> > > But I was under impression that the SW stack which actually does the
> > > monitoring is under your controll. Moreover I was under impression that
> > > you do not use the current vanilla kernel so there is no need for an
> > > immediate change on your end. It is trivial to come up with a backward
> > > compatible way to check for the new flag (if it is not present then
> > > fallback to vma flags).
> > >
>
> The userspace had a single way to determine if thp had been disabled for a
> specific vma and that was broken with your commit. We have since fixed
> it. Modifying our software stack to start looking for some field
> somewhere else will not help anybody else that this has affected or will
> affect. I'm interested in not breaking userspace, not trying a wait and
> see approach to see if anybody else complains once we start looking for
> some other field. The risk outweighs the reward, it already broke us, and
> I'd prefer not to even open the possibility of breaking anybody else.
I very much agree on "do not break userspace" part but this is kind of
gray area. VMA flags are a deep internal implementation detail and
nobody should really depend on it for anything important. The original
motivation for introducing it was CRIU where it is kind of
understandable. I would argue they should find a different way but it is
just too late for them.
For this particular case there was no other bug report except for yours
and if it is possible to fix it on your end then I would really love to
make the a sensible user interface to query the status. If we are going
to change the semantic of the exported flag again then we risk yet
another breakage.
Therefore I am asking whether changing your particular usecase to a new
interface is possible because that would allow to have a longerm
sensible user interface rather than another kludge which still doesn't
cover all the usecases (e.g. there is no way to reliably query the
madvise status after your patch).
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: Official Linux system wrapper library?
From: Theodore Y. Ts'o @ 2018-11-15 5:30 UTC (permalink / raw)
To: Joseph Myers
Cc: Daniel Colascione, Szabolcs Nagy, Dave P Martin, nd,
Florian Weimer, Michael Kerrisk (man-pages), linux-kernel,
Joel Fernandes, Linux API, Willy Tarreau, Vlastimil Babka,
Carlos O'Donell, libc-alpha@sourceware.org
In-Reply-To: <alpine.DEB.2.21.1811141840140.16571@digraph.polyomino.org.uk>
On Wed, Nov 14, 2018 at 06:47:57PM +0000, Joseph Myers wrote:
> On Wed, 14 Nov 2018, Daniel Colascione wrote:
>
> > A good demonstration of a new commitment to pragmatism would be
> > merging the trivial wrappers for gettid(2).
>
> I support the addition of gettid (for use with those syscalls that take
> tids, and with appropriate documentation explaining the properties of
> tids) - and, generally, wrappers for all non-obsolescent
> architecture-independent Linux kernel syscalls, including ones that are
> very Linux-specific, except maybe for a few interfaces fundamentally
> inconsistent with glibc managing TLS etc. - they are, at least, no worse
> as a source of APIs than all the old BSD / SVID interfaces we have from
> when those were used as sources of APIs.
That's great. But is it or is it not true (either de jure or de
facto) that "a single active glibc developer" can block a system call
from being supported by glibc by objecting? And if not, under what is
the process by resolving a conflict?
- Ted
^ permalink raw reply
* Re: [RFC PATCH] mm, proc: report PR_SET_THP_DISABLE in proc
From: David Rientjes @ 2018-11-14 21:41 UTC (permalink / raw)
To: Michal Hocko
Cc: Andrew Morton, Vlastimil Babka, Alexey Dobriyan,
Kirill A. Shutemov, linux-kernel, linux-mm, linux-api
In-Reply-To: <20181114132306.GX23419@dhcp22.suse.cz>
On Wed, 14 Nov 2018, Michal Hocko wrote:
> > > > Do you know of any other userspace except your usecase? Is there
> > > > anything fundamental that would prevent a proper API adoption for you?
> > > >
> > >
> > > Yes, it would require us to go back in time and build patched binaries.
> >
> > I read that as there is a fundamental problem to update existing
> > binaries. If that is the case then there surely is no way around it
> > and another sad page in the screwed up APIs book we provide.
> >
> > But I was under impression that the SW stack which actually does the
> > monitoring is under your controll. Moreover I was under impression that
> > you do not use the current vanilla kernel so there is no need for an
> > immediate change on your end. It is trivial to come up with a backward
> > compatible way to check for the new flag (if it is not present then
> > fallback to vma flags).
> >
The userspace had a single way to determine if thp had been disabled for a
specific vma and that was broken with your commit. We have since fixed
it. Modifying our software stack to start looking for some field
somewhere else will not help anybody else that this has affected or will
affect. I'm interested in not breaking userspace, not trying a wait and
see approach to see if anybody else complains once we start looking for
some other field. The risk outweighs the reward, it already broke us, and
I'd prefer not to even open the possibility of breaking anybody else.
^ permalink raw reply
* Re: [PATCH v5 06/27] x86/cet: Control protection exception handler
From: Borislav Petkov @ 2018-11-14 20:28 UTC (permalink / raw)
To: Yu-cheng Yu
Cc: x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar, linux-kernel,
linux-doc, linux-mm, linux-arch, linux-api, Arnd Bergmann,
Andy Lutomirski, Balbir Singh, Cyrill Gorcunov, Dave Hansen,
Eugene Syromiatnikov, Florian Weimer, H.J. Lu, Jann Horn,
Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pa
In-Reply-To: <307b6162b0270871e664ca88a96b4ea0d1b3f65b.camel@intel.com>
On Wed, Nov 14, 2018 at 12:19:42PM -0800, Yu-cheng Yu wrote:
> Yes, I was not sure if the addition should follow the existing style (which does
> not have identifier names). What do you think is right?
Yeah, we've converted them all now to named params:
https://git.kernel.org/tip/8e1599fcac2efda8b7d433ef69d2492f0b351e3f
It probably would be easier if you redo your patchset ontop of current
tip/master.
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* Re: [PATCH v5 06/27] x86/cet: Control protection exception handler
From: Yu-cheng Yu @ 2018-11-14 20:19 UTC (permalink / raw)
To: Borislav Petkov
Cc: x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar, linux-kernel,
linux-doc, linux-mm, linux-arch, linux-api, Arnd Bergmann,
Andy Lutomirski, Balbir Singh, Cyrill Gorcunov, Dave Hansen,
Eugene Syromiatnikov, Florian Weimer, H.J. Lu, Jann Horn,
Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pa
In-Reply-To: <20181114184436.GK13926@zn.tnic>
On Wed, 2018-11-14 at 19:44 +0100, Borislav Petkov wrote:
> That subject needs a verb:
>
> Subject: [PATCH v5 06/27] x86/cet: Add control protection exception handler
>
> On Thu, Oct 11, 2018 at 08:15:02AM -0700, Yu-cheng Yu wrote:
> > A control protection exception is triggered when a control flow transfer
> > attempt violated shadow stack or indirect branch tracking constraints.
> > For example, the return address for a RET instruction differs from the
> > safe copy on the shadow stack; or a JMP instruction arrives at a non-
> > ENDBR instruction.
> >
> > The control protection exception handler works in a similar way as the
> > general protection fault handler.
> >
> > Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
> > ---
> > arch/x86/entry/entry_64.S | 2 +-
> > arch/x86/include/asm/traps.h | 3 ++
> > arch/x86/kernel/idt.c | 4 ++
> > arch/x86/kernel/signal_compat.c | 2 +-
> > arch/x86/kernel/traps.c | 64 ++++++++++++++++++++++++++++++
> > include/uapi/asm-generic/siginfo.h | 3 +-
> > 6 files changed, 75 insertions(+), 3 deletions(-)
>
> A *lot* of style problems here. Please use checkpatch and then common
> sense to check your patches before sending. All those below are valid,
> AFAICT:
>
> WARNING: function definition argument 'struct pt_regs *' should also have an
> identifier name
> #76: FILE: arch/x86/include/asm/traps.h:81:
> +dotraplinkage void do_control_protection(struct pt_regs *, long);
>
> WARNING: function definition argument 'long' should also have an identifier
> name
> #76: FILE: arch/x86/include/asm/traps.h:81:
> +dotraplinkage void do_control_protection(struct pt_regs *, long);
Yes, I was not sure if the addition should follow the existing style (which does
not have identifier names). What do you think is right?
Thanks,
Yu-cheng
^ permalink raw reply
* Re: Official Linux system wrapper library?
From: Joseph Myers @ 2018-11-14 18:47 UTC (permalink / raw)
To: Daniel Colascione
Cc: Szabolcs Nagy, Dave P Martin, nd, Florian Weimer,
Michael Kerrisk (man-pages), linux-kernel, Joel Fernandes,
Linux API, Willy Tarreau, Vlastimil Babka, Carlos O'Donell,
libc-alpha@sourceware.org
In-Reply-To: <CAKOZuetCGCfNdJ2QM0phu3_3Q29f5Yeh=NHiM_A9MhHsCjK48A@mail.gmail.com>
On Wed, 14 Nov 2018, Daniel Colascione wrote:
> A good demonstration of a new commitment to pragmatism would be
> merging the trivial wrappers for gettid(2).
I support the addition of gettid (for use with those syscalls that take
tids, and with appropriate documentation explaining the properties of
tids) - and, generally, wrappers for all non-obsolescent
architecture-independent Linux kernel syscalls, including ones that are
very Linux-specific, except maybe for a few interfaces fundamentally
inconsistent with glibc managing TLS etc. - they are, at least, no worse
as a source of APIs than all the old BSD / SVID interfaces we have from
when those were used as sources of APIs.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply
* Re: [PATCH v5 06/27] x86/cet: Control protection exception handler
From: Borislav Petkov @ 2018-11-14 18:44 UTC (permalink / raw)
To: Yu-cheng Yu
Cc: x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar, linux-kernel,
linux-doc, linux-mm, linux-arch, linux-api, Arnd Bergmann,
Andy Lutomirski, Balbir Singh, Cyrill Gorcunov, Dave Hansen,
Eugene Syromiatnikov, Florian Weimer, H.J. Lu, Jann Horn,
Jonathan Corbet, Kees Cook, Mike Kravetz, Nadav Amit,
Oleg Nesterov, Pa
In-Reply-To: <20181011151523.27101-7-yu-cheng.yu@intel.com>
That subject needs a verb:
Subject: [PATCH v5 06/27] x86/cet: Add control protection exception handler
On Thu, Oct 11, 2018 at 08:15:02AM -0700, Yu-cheng Yu wrote:
> A control protection exception is triggered when a control flow transfer
> attempt violated shadow stack or indirect branch tracking constraints.
> For example, the return address for a RET instruction differs from the
> safe copy on the shadow stack; or a JMP instruction arrives at a non-
> ENDBR instruction.
>
> The control protection exception handler works in a similar way as the
> general protection fault handler.
>
> Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
> ---
> arch/x86/entry/entry_64.S | 2 +-
> arch/x86/include/asm/traps.h | 3 ++
> arch/x86/kernel/idt.c | 4 ++
> arch/x86/kernel/signal_compat.c | 2 +-
> arch/x86/kernel/traps.c | 64 ++++++++++++++++++++++++++++++
> include/uapi/asm-generic/siginfo.h | 3 +-
> 6 files changed, 75 insertions(+), 3 deletions(-)
A *lot* of style problems here. Please use checkpatch and then common
sense to check your patches before sending. All those below are valid,
AFAICT:
WARNING: function definition argument 'struct pt_regs *' should also have an identifier name
#76: FILE: arch/x86/include/asm/traps.h:81:
+dotraplinkage void do_control_protection(struct pt_regs *, long);
WARNING: function definition argument 'long' should also have an identifier name
#76: FILE: arch/x86/include/asm/traps.h:81:
+dotraplinkage void do_control_protection(struct pt_regs *, long);
WARNING: static const char * array should probably be static const char * const
#124: FILE: arch/x86/kernel/traps.c:581:
+static const char *control_protection_err[] =
ERROR: that open brace { should be on the previous line
#125: FILE: arch/x86/kernel/traps.c:582:
+static const char *control_protection_err[] =
+{
WARNING: quoted string split across lines
#158: FILE: arch/x86/kernel/traps.c:615:
+ WARN_ONCE(1, "CET is disabled but got control "
+ "protection fault\n");
WARNING: Prefer printk_ratelimited or pr_<level>_ratelimited to printk_ratelimit
#165: FILE: arch/x86/kernel/traps.c:622:
+ printk_ratelimit()) {
WARNING: Avoid logging continuation uses where feasible
#176: FILE: arch/x86/kernel/traps.c:633:
+ pr_cont("\n");
ERROR: "(foo*)" should be "(foo *)"
#183: FILE: arch/x86/kernel/traps.c:640:
+ info.si_addr = (void __user*)uprobe_get_trap_addr(regs);
And now that patch doesn't even build anymore because of the siginfo
changes which came in during the merge window. I guess I'll wait for
your v6 patchset.
---
arch/x86/kernel/traps.c: In function ‘do_control_protection’:
arch/x86/kernel/traps.c:627:16: error: passing argument 1 of ‘clear_siginfo’ from incompatible pointer type [-Werror=incompatible-pointer-types]
clear_siginfo(&info);
^~~~~
In file included from ./include/linux/sched/signal.h:6,
from ./include/linux/ptrace.h:7,
from ./include/linux/ftrace.h:14,
from ./include/linux/kprobes.h:42,
from arch/x86/kernel/traps.c:19:
./include/linux/signal.h:20:52: note: expected ‘kernel_siginfo_t *’ {aka ‘struct kernel_siginfo *’} but argument is of type ‘siginfo_t *’ {aka ‘struct siginfo *’}
static inline void clear_siginfo(kernel_siginfo_t *info)
~~~~~~~~~~~~~~~~~~^~~~
arch/x86/kernel/traps.c:632:26: error: passing argument 2 of ‘force_sig_info’ from incompatible pointer type [-Werror=incompatible-pointer-types]
force_sig_info(SIGSEGV, &info, tsk);
^~~~~
In file included from ./include/linux/ptrace.h:7,
from ./include/linux/ftrace.h:14,
from ./include/linux/kprobes.h:42,
from arch/x86/kernel/traps.c:19:
./include/linux/sched/signal.h:327:32: note: expected ‘struct kernel_siginfo *’ but argument is of type ‘siginfo_t *’ {aka ‘struct siginfo *’}
extern int force_sig_info(int, struct kernel_siginfo *, struct task_struct *);
^~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:291: arch/x86/kernel/traps.o] Error 1
make[1]: *** [scripts/Makefile.build:516: arch/x86/kernel] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [Makefile:1060: arch/x86] Error 2
make: *** Waiting for unfinished jobs....
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* Re: Official Linux system wrapper library?
From: Daniel Colascione @ 2018-11-14 18:35 UTC (permalink / raw)
To: Joseph Myers
Cc: Szabolcs Nagy, Dave P Martin, nd, Florian Weimer,
Michael Kerrisk (man-pages), linux-kernel, Joel Fernandes,
Linux API, Willy Tarreau, Vlastimil Babka, Carlos O'Donell,
libc-alpha@sourceware.org
In-Reply-To: <alpine.DEB.2.21.1811141741000.16571@digraph.polyomino.org.uk>
On Wed, Nov 14, 2018 at 10:15 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> Any
> feature (e.g. syscall library) with a design coming solely from the kernel
> rather than a cooperative process is also likely to have an unsuitable
> design meaning it doesn't get used.
Is that so? membarrier came directly from the kernel. It gets used and
appears to have a suitable design. That something isn't used by libc
doesn't mean that it doesn't get used in general.
> Once we have sufficient communication
> to design suitable interfaces *together*, "avoiding the need to
> communicate" becomes irrelevant as a design criterion anyway.
If that approach is going to go work, the libc maintainership needs to
be more pragmatic, less idealistic, and less likely to block work on
purity grounds, e.g., we shouldn't do X because the dynamic linker
really should be out-of-process, we can't do Y because nobody should
be using signals, and we can't do Z because the kernel uses IDs that
have such-and-such ugly properties.
A good demonstration of a new commitment to pragmatism would be
merging the trivial wrappers for gettid(2).
^ permalink raw reply
* Re: Official Linux system wrapper library?
From: Joseph Myers @ 2018-11-14 18:30 UTC (permalink / raw)
To: Arnd Bergmann
Cc: carlos, Szabolcs Nagy, Dave Martin, dancol, nd, Florian Weimer,
Michael Kerrisk, Linux Kernel Mailing List, Joel Fernandes,
Linux API, Willy Tarreau, Vlastimil Babka, GNU C Library,
Firoz Khan
In-Reply-To: <CAK8P3a1S65QSRruig+hg_03XbcNges1oR0YWivypvcp7r79Lew@mail.gmail.com>
On Wed, 14 Nov 2018, Arnd Bergmann wrote:
> Firoz Khan is in the process of doing part of this, by changing the
> in-kernel per-architecture unistd.h and syscall.S files into a
> architecture independent machine-readable format that is used to
> generate the existing files. The format will be similar to what
> we have on arm/s390/x86 in the syscall.tbl files already.
Will this also mean the following are unable to occur in future (both have
occurred in the past):
* A syscall added to unistd.h for an architecture, but not added to the
syscall table until sometime later?
* A syscall added to the native syscall table for some ABI (e.g. 32-bit
x86 or arm) but not added to the corresponding compat syscall table (e.g.
32-bit x86 binaries running on x86_64, 32-bit arm binaries running on
arm64) until sometime later?
Avoiding both of those complications is beneficial to libc (as is a third
thing, avoiding a syscall being added to different architectures in
different versions).
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply
* Re: Official Linux system wrapper library?
From: Joseph Myers @ 2018-11-14 18:15 UTC (permalink / raw)
To: Daniel Colascione
Cc: Szabolcs Nagy, Dave P Martin, nd, Florian Weimer,
Michael Kerrisk (man-pages), linux-kernel, Joel Fernandes,
Linux API, Willy Tarreau, Vlastimil Babka, Carlos O'Donell,
libc-alpha@sourceware.org
In-Reply-To: <CAKOZuesta_V=doXsVLc2E6WCQvywdur3F+u2pFKaPN+CEQd+ZQ@mail.gmail.com>
On Wed, 14 Nov 2018, Daniel Colascione wrote:
> > there is a lot of bikesheding here by people who
> > don't understand the constraints nor the use-cases.
>
> Conversely, there's a lot of doubt-sowing from the other side that
"other side" is the wrong concept here in the first place - it's supposed
to be a matter of cooperating projects trying to find good interfaces
together.
Any new feature from the kernel that is meant to be of use to libcs is
best designed in a way involving such cooperation (with multiple libcs).
I concur with Zack's assessment in
<https://sourceware.org/ml/libc-alpha/2018-11/msg00286.html> that a
technical fix to process / communication issues cannot work here. Any
feature (e.g. syscall library) with a design coming solely from the kernel
rather than a cooperative process is also likely to have an unsuitable
design meaning it doesn't get used. Once we have sufficient communication
to design suitable interfaces *together*, "avoiding the need to
communicate" becomes irrelevant as a design criterion anyway.
> After looking at the history of settid, signal multi-handler
> registration, and other proposed improvements running into the brick
> wall of glibc's API process, I think it's clear that requiring glibc
> signoff on new kernel interfaces would simply lead to stagnation. It's
That there was disagreement on some particular interface does not mean
there are problems with the basic principle of working with libc
maintainers (of multiple libcs, not just one!) to establish what the
intended userspace C API to some new kernel interface should be, and to
nail down the details of how the kernel interface is defined in the
process.
(And as noted elsewhere, I think the main people objecting to generally
having bindings for all non-obsolescent syscalls are no longer active in
glibc.)
If the semantics of some proposed kernel interface, both at the syscall
level and at the userspace C API level, are agreed e.g. by kernel and musl
people, I'd think the API agreement from musl would be a good indication
of the API also being suitable to add to glibc. It's not necessary to get
agreement from every libc on every API - but there should be agreement
from *some* libc that is careful about API review. If enough people with
good sense about libc APIs have judged some API for a new syscall
suitable, I expect other libcs can implement it even if it's not exactly
the API they'd come up with themselves.
(I haven't seen enough comments on libc / kernel API design from people I
know to be associated with bionic, uclibc-ng, etc., to judge if they also
pay similarly careful attention to working out what a good C API design
for some interface should be. Note that there are musl people active on
libc-alpha, which helps everyone arrive at a consensus on better C API
designs.)
> The right answer is a move to an approximation of the BSD model and
> bring the primary interface layer in-house.
I could equally say we should take the kernel in-house and develop it to
better support glibc - that if the kernel doesn't provide what we want, we
should add the features to GNU Linux-libre and say that's the supported
kernel for use with glibc. It's an equally absurd statement in a context
of multiple cooperating projects.
> There's a lot of evidence that this model works.
There's a lot of evidence that the model of separately maintained Linux
kernel and libc works (see: the number of devices using Linux kernels with
a range of different libc implementations that meet different needs).
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply
* Re: Official Linux system wrapper library?
From: Paul Eggert @ 2018-11-14 18:13 UTC (permalink / raw)
To: Joseph Myers, Andy Lutomirski
Cc: Szabolcs Nagy, Dave P Martin, Daniel Colascione, nd,
Florian Weimer, Michael Kerrisk (man-pages), linux-kernel,
Joel Fernandes, Linux API, Willy Tarreau, Vlastimil Babka,
Carlos O'Donell, libc-alpha@sourceware.org
In-Reply-To: <alpine.DEB.2.21.1811141735070.16571@digraph.polyomino.org.uk>
On 11/14/18 9:40 AM, Joseph Myers wrote:
> Historically, there was once an attempt to rework POSIX into a separate
> language-independent definition and language bindings (for C, Fortran, Ada
> etc.), but I don't think it got anywhere, and it's probably doubtful
> whether the idea was ever very practical.
That effort did produce IEEE Std 1003.5-1992 (Ada Bindings to IEEE Std
1003.1-1990), IEEE 1003.5b-1996 (Ada bindings for realtime extensions),
and IEEE Std 1003.9-1992 (F77 Bindings to IEEE Std 1003.1-1992). The Ada
group simply translated the POSIX standard from C into Ada, repeating
functional text and coming up with a "thick" standard; in contrast the
Fortran group did a "thin" standard that focused on Fortran mechanics
and deferred underlying functionality to the main POSIX standard. The
thin Fortran standard was harder to grok and was less successful in
practice.
As you write, these efforts were probably not worth the trouble. Non-C
language systems can provide a standard way to invoke C APIs, and then
let user-level programmers have at it. The performance advantage of
having a pure Ada/Fortran/etc. API for POSIX are so minor that it's not
worth the major hassle of standardizing and using a language-independent
POSIX API.
^ permalink raw reply
* Re: Official Linux system wrapper library?
From: Joseph Myers @ 2018-11-14 17:40 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Szabolcs Nagy, Dave P Martin, Daniel Colascione, nd,
Florian Weimer, Michael Kerrisk (man-pages), linux-kernel,
Joel Fernandes, Linux API, Willy Tarreau, Vlastimil Babka,
Carlos O'Donell, libc-alpha@sourceware.org
In-Reply-To: <1C1B38FC-1266-4A91-B8F6-20A0C49ED1E2@amacapital.net>
[-- Attachment #1: Type: text/plain, Size: 1247 bytes --]
On Wed, 14 Nov 2018, Andy Lutomirski wrote:
> I’m not so sure it’s useless. Historically, POSIX systems have, in
> practice and almost by definition, been very C focused, but the world is
> changing. A less crufty library could be useful for newer languages:
Historically, there was once an attempt to rework POSIX into a separate
language-independent definition and language bindings (for C, Fortran, Ada
etc.), but I don't think it got anywhere, and it's probably doubtful
whether the idea was ever very practical. (See the introduction to
POSIX.1:1990, for example: "Future revisions are expected to contain
bindings for other programming languages as well as for the C language.
This will be accomplished by breaking this part of ISO/IEC 9945 into
multiple portions---one defining core requirements independent of any
programming language, and others composed of programming language
bindings.".)
> > thread internals for syscalls that
> > require coordination between all user created
> > threads (setxid),
>
> We should just deal with this in the kernel. The current state of
> affairs is nuts.
Yes, we should have a few new syscalls to set these ids at the process
level.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply
* Re: Official Linux system wrapper library?
From: Arnd Bergmann @ 2018-11-14 17:15 UTC (permalink / raw)
To: carlos
Cc: Szabolcs Nagy, Dave Martin, dancol, nd, Florian Weimer,
Michael Kerrisk, Linux Kernel Mailing List, Joel Fernandes,
Linux API, Willy Tarreau, Vlastimil Babka, GNU C Library,
Firoz Khan
In-Reply-To: <fb340c72-c484-7f55-a2bd-71e072d7f1f5@redhat.com>
On Wed, Nov 14, 2018 at 6:58 AM Carlos O'Donell <carlos@redhat.com> wrote:
> On 11/14/18 6:58 AM, Szabolcs Nagy wrote:
> > an actual proposal in the thread that i think is
> > worth considering is to make the linux syscall
> > design process involve libc devs so the c api is
> > designed together with the syscall abi.
>
> * Programmatic / Machine readable description of syscalls.
> This way the kernel gives users the ability to autogenerate
> all the wrappers *if they want to* in a consistent way that
> matches this syscall description format.
Firoz Khan is in the process of doing part of this, by changing the
in-kernel per-architecture unistd.h and syscall.S files into a
architecture independent machine-readable format that is used to
generate the existing files. The format will be similar to what
we have on arm/s390/x86 in the syscall.tbl files already.
This is of course only part of the picture, it answers the question
of which syscalls are implemented on an architecture, which number
they have and (ideally) whether they use a standard implementation
or a custom one, but it does not yet relate to the prototype.
Once this work is merged, we can follow up by coming up with a
way to add prototypes and enforcing that the user space wrapper
uses the same argument types as the in-kernel entry point.
Arnd
^ permalink raw reply
* Re: Official Linux system wrapper library?
From: Daniel Colascione @ 2018-11-14 15:40 UTC (permalink / raw)
To: Szabolcs Nagy
Cc: Dave P Martin, nd, Florian Weimer, Michael Kerrisk (man-pages),
linux-kernel, Joel Fernandes, Linux API, Willy Tarreau,
Vlastimil Babka, Carlos O'Donell, libc-alpha@sourceware.org
In-Reply-To: <5853c297-9d84-86e5-dede-aa2957562c6b@arm.com>
On Wed, Nov 14, 2018 at 3:58 AM, Szabolcs Nagy <Szabolcs.Nagy@arm.com> wrote:
> On 13/11/18 19:39, Dave Martin wrote:
>> On Mon, Nov 12, 2018 at 05:19:14AM -0800, Daniel Colascione wrote:
>>> We should adopt a similar approach. Shipping a lower-level
>>> "liblinux.so" tightly bound to the kernel would not only let the
>>> kernel bypass glibc's "editorial discretion" in exposing new
>>> facilities to userspace, but would also allow for tighter user-kernel
>>> integration that one can achieve with a simplistic syscall(2)-style
>>> escape hatch. (For example, for a long time now, I've wanted to go
>>> beyond POSIX and improve the system's signal handling API, and this
>>> improvement requires userspace cooperation.) The vdso is probably too
>>> small and simplistic to serve in this role; I'd want a real library.
>>
>> Can you expand on your reasoning here?
>
> such lib creates a useless abi+api layer that
> somebody has to maintain and document (with or
> without vdso).
People already maintain the kernel man pages and are very good.
> it obviously cannot work together with a posix
> conform libc implementation for which it would
> require knowledge about
You're incorrect on this point. See programs cobbled together out of
syscall(2) invocations today: despite lack of libc integration, things
do mostly work in practice. Calling through a library can't possible
be worse, and in many ways can be much better.
> thread cancellation internals,
As I mentioned upthread, the only thing a libc needs in order to
support cancellation properly (at least the way glibc does it)
is a way to ask the kernel-provided userspace library whether a
particular program counter address belongs to a certain code sequence
immediately before the system call instruction, whatever that is.
Providing this facility is doable without deep knowledge of libc's
internals, and libc can use it without a deep knowledge of the
interface library.
> potentially TLS
> for errno
As someone else mentioned, errno is a libc construct. It's not *hard*
to support setting errno though: libc could just be required to supply
a well-defined libc_set_errno symbol that the kernel ABI library would
then use as needed.
> know libc types even ones that are
> based on compile time feature macros
This library would not have to do the things that libc does. Why would
it have to support libc's feature test macros at all?
> (and expose
> them in headers in a way that does not collide
> with libc headers)
The kernel should have a set of types and a symbol namespace
completely disjoint from libc's, with no compatibility hacks or macros
needed. (That might take some renaming kernel-side.) If libc wants to
provide a POSIX API, it can take on the responsibility for mapping the
kernel's structures to libc's, but within its namespace, the kernel
should be able to add types without fear of conflict.
> abi variants the libc supports
> (e.g. softfp, security hardened abi), libc
> internal signals (for anything that's changing
> signal masks), thread internals for syscalls that
> require coordination between all user created
> threads
Most proposed new system calls do not create threads, manipulate
signal masks, or muck with other internals, so these concerns just
don't apply. That's why syscall(2) mostly works in practice. Even if a
few new system calls *do* involve these internal details and require
closer libc coordination, the majority (e.g., the new mount API,
termios2) don't, and so can be exposed directly from the kernel
project without being blocked by glibc.
> (setxid),
A kernel-side fix here would be the cleanest approach.
> libc internal state for syscalls
> that create/destroy threads.
>
> and thus such lib does not solve the problems
> of users who actually requested wrappers for
> new syscalls (since they want to call into libc
> and create threads).
>
> there is a lot of bikesheding here by people who
> don't understand the constraints nor the use-cases.
Conversely, there's a lot of doubt-sowing from the other side that
makes shipping a kernel-provided interface library seem harder than it
is. Most new system calls do not bear on the integration concerns that
you and others are raising, and whatever problems remain can be solved
with a narrow interface between libc and a new interface library, one
that would let both evolve independently.
> an actual proposal in the thread that i think is
> worth considering is to make the linux syscall
> design process involve libc devs so the c api is
> designed together with the syscall abi.
After looking at the history of settid, signal multi-handler
registration, and other proposed improvements running into the brick
wall of glibc's API process, I think it's clear that requiring glibc
signoff on new kernel interfaces would simply lead to stagnation. It's
not as if we're approaching the problem from a position of ignorance.
The right answer is a move to an approximation of the BSD model and
bring the primary interface layer in-house.
There's a lot of evidence that this model works.
^ permalink raw reply
* Re: Official Linux system wrapper library?
From: Florian Weimer @ 2018-11-14 15:07 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Szabolcs Nagy, Dave P Martin, Daniel Colascione, nd,
Michael Kerrisk (man-pages), linux-kernel, Joel Fernandes,
Linux API, Willy Tarreau, Vlastimil Babka, Carlos O'Donell,
libc-alpha@sourceware.org
In-Reply-To: <1C1B38FC-1266-4A91-B8F6-20A0C49ED1E2@amacapital.net>
* Andy Lutomirski:
> Thread cancellation is a big mess, and we only really need to support
> it because on legacy code. The whole mechanism should IMO be
> considered extremely deprecated.
The part regarding legacy code is not true: people write new code using
it all the time. It's true that this feature is difficult to use, and
it is often employed in cases where it is not needed or
counterproductive. However, there are cases where code becomes simpler.
Thanks,
Florian
^ permalink raw reply
* Re: Official Linux system wrapper library?
From: Carlos O'Donell @ 2018-11-14 14:58 UTC (permalink / raw)
To: Szabolcs Nagy, Dave P Martin, Daniel Colascione
Cc: nd, Florian Weimer, Michael Kerrisk (man-pages), linux-kernel,
Joel Fernandes, Linux API, Willy Tarreau, Vlastimil Babka,
libc-alpha@sourceware.org
In-Reply-To: <5853c297-9d84-86e5-dede-aa2957562c6b@arm.com>
On 11/14/18 6:58 AM, Szabolcs Nagy wrote:
> an actual proposal in the thread that i think is
> worth considering is to make the linux syscall
> design process involve libc devs so the c api is
> designed together with the syscall abi.
Right, I see at least 2 actionable items:
* "The Checklist" which everyone making a syscall should
follow and we create the checklist with input from both
sides and it becomes the thing you reference e.g.
"Did you follow the checklist? Where is X?"
* Programmatic / Machine readable description of syscalls.
This way the kernel gives users the ability to autogenerate
all the wrappers *if they want to* in a consistent way that
matches this syscall description format.
--
Cheers,
Carlos.
^ permalink raw reply
* Re: Official Linux system wrapper library?
From: Andy Lutomirski @ 2018-11-14 14:46 UTC (permalink / raw)
To: Szabolcs Nagy
Cc: Dave P Martin, Daniel Colascione, nd, Florian Weimer,
Michael Kerrisk (man-pages), linux-kernel, Joel Fernandes,
Linux API, Willy Tarreau, Vlastimil Babka, Carlos O'Donell,
libc-alpha@sourceware.org
In-Reply-To: <5853c297-9d84-86e5-dede-aa2957562c6b@arm.com>
> On Nov 14, 2018, at 3:58 AM, Szabolcs Nagy <Szabolcs.Nagy@arm.com> wrote:
>
>> On 13/11/18 19:39, Dave Martin wrote:
>>> On Mon, Nov 12, 2018 at 05:19:14AM -0800, Daniel Colascione wrote:
>>> We should adopt a similar approach. Shipping a lower-level
>>> "liblinux.so" tightly bound to the kernel would not only let the
>>> kernel bypass glibc's "editorial discretion" in exposing new
>>> facilities to userspace, but would also allow for tighter user-kernel
>>> integration that one can achieve with a simplistic syscall(2)-style
>>> escape hatch. (For example, for a long time now, I've wanted to go
>>> beyond POSIX and improve the system's signal handling API, and this
>>> improvement requires userspace cooperation.) The vdso is probably too
>>> small and simplistic to serve in this role; I'd want a real library.
>>
>> Can you expand on your reasoning here?
>
> such lib creates a useless abi+api layer that
> somebody has to maintain and document (with or
> without vdso).
I’m not so sure it’s useless. Historically, POSIX systems have, in practice and almost by definition, been very C focused, but the world is changing. A less crufty library could be useful for newer languages:
>
> it obviously cannot work together with a posix
> conform libc implementation for which it would
> require knowledge about
>
> thread cancellation internals,
Thread cancellation is a big mess, and we only really need to support it because on legacy code. The whole mechanism should IMO be considered extremely deprecated.
> potentially TLS
> for errno,
errno is IMO a libc thing, full stop. A lower level library should *not* support errno.
> know libc types even ones that are
> based on compile time feature macros (and expose
> them in headers in a way that does not collide
> with libc headers),
This one is tricky. I wonder if we could instead get a C compiler extension to set libc declare that a given struct is a layout-compatible variant of another.
> abi variants the libc supports
> (e.g. softfp, security hardened abi),
Hmm.
> libc
> internal signals (for anything that's changing
> signal masks),
This is nasty, but see my cancellation comment above.
> thread internals for syscalls that
> require coordination between all user created
> threads (setxid),
We should just deal with this in the kernel. The current state of affairs is nuts.
> libc internal state for syscalls
> that create/destroy threads.
I disagree. If you make or destroy threads behind libc’s back, I think you get to keep both pieces.
^ permalink raw reply
* Re: [RFC PATCH] mm, proc: report PR_SET_THP_DISABLE in proc
From: Michal Hocko @ 2018-11-14 13:23 UTC (permalink / raw)
To: David Rientjes
Cc: Andrew Morton, Vlastimil Babka, Alexey Dobriyan,
Kirill A. Shutemov, linux-kernel, linux-mm, linux-api
In-Reply-To: <20181018070031.GW18839@dhcp22.suse.cz>
On Thu 18-10-18 09:00:31, Michal Hocko wrote:
> On Wed 17-10-18 12:59:18, David Rientjes wrote:
> > On Wed, 17 Oct 2018, Michal Hocko wrote:
> >
> > > Do you know of any other userspace except your usecase? Is there
> > > anything fundamental that would prevent a proper API adoption for you?
> > >
> >
> > Yes, it would require us to go back in time and build patched binaries.
>
> I read that as there is a fundamental problem to update existing
> binaries. If that is the case then there surely is no way around it
> and another sad page in the screwed up APIs book we provide.
>
> But I was under impression that the SW stack which actually does the
> monitoring is under your controll. Moreover I was under impression that
> you do not use the current vanilla kernel so there is no need for an
> immediate change on your end. It is trivial to come up with a backward
> compatible way to check for the new flag (if it is not present then
> fallback to vma flags).
>
> I am sorry for pushing here but if this is just a matter of a _single_
> user which _can_ be fixed with a reasonable effort then I would love to
> see the future api unscrewed.
ping
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: Official Linux system wrapper library?
From: Florian Weimer @ 2018-11-14 12:10 UTC (permalink / raw)
To: Adam Borowski
Cc: Willy Tarreau, Michael Kerrisk (man-pages), Daniel Colascione,
linux-kernel, Joel Fernandes, Linux API, Vlastimil Babka,
Carlos O'Donell, libc-alpha@sourceware.org
In-Reply-To: <20181114120348.or5id3hzrmltkyvb@angband.pl>
* Adam Borowski:
> On Sun, Nov 11, 2018 at 12:46:35PM +0100, Florian Weimer wrote:
>> A lot of multi-threaded applications assume that most high-level
>> functionality remains usable even after fork in a multi-threaded
>> process.
>
> How would this be even possible? Currently fork kills all threads
> (save for the caller).
glibc's fork acquires several locks around fork. Other mallocs install
fork handlers, too.
> Glibc's manpage also warns:
>
> # After a fork() in a multithreaded program, the child can safely call only
> # async-signal-safe functions (see signal-safety(7)) until such time as it
> # calls execve(2).
>
> Which makes sense as its malloc uses a mutex, and you can't take a breath
> without a library call using malloc somewhere (or in C++, the language
> itself).
Right, but applications require a working malloc after fork,
unfortunately. opendir is often used to enumerate file descriptors
which need closing, for example.
Thanks,
Florian
^ permalink raw reply
* Re: Official Linux system wrapper library?
From: Adam Borowski @ 2018-11-14 12:03 UTC (permalink / raw)
To: Florian Weimer
Cc: Willy Tarreau, Michael Kerrisk (man-pages), Daniel Colascione,
linux-kernel, Joel Fernandes, Linux API, Vlastimil Babka,
Carlos O'Donell, libc-alpha@sourceware.org
In-Reply-To: <87zhufvntw.fsf@oldenburg.str.redhat.com>
On Sun, Nov 11, 2018 at 12:46:35PM +0100, Florian Weimer wrote:
> A lot of multi-threaded applications assume that most high-level
> functionality remains usable even after fork in a multi-threaded
> process.
How would this be even possible? Currently fork kills all threads
(save for the caller).
Glibc's manpage also warns:
# After a fork() in a multithreaded program, the child can safely call only
# async-signal-safe functions (see signal-safety(7)) until such time as it
# calls execve(2).
Which makes sense as its malloc uses a mutex, and you can't take a breath
without a library call using malloc somewhere (or in C++, the language
itself).
So any functionality remaining usable after fork is pretty strictly
limited...
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ I've read an article about how lively happy music boosts
⣾⠁⢰⠒⠀⣿⡁ productivity. You can read it, too, you just need the
⢿⡄⠘⠷⠚⠋⠀ right music while doing so. I recommend Skepticism
⠈⠳⣄⠀⠀⠀⠀ (funeral doom metal).
^ permalink raw reply
* Re: Official Linux system wrapper library?
From: Szabolcs Nagy @ 2018-11-14 11:58 UTC (permalink / raw)
To: Dave P Martin, Daniel Colascione
Cc: nd, Florian Weimer, Michael Kerrisk (man-pages), linux-kernel,
Joel Fernandes, Linux API, Willy Tarreau, Vlastimil Babka,
Carlos O'Donell, libc-alpha@sourceware.org
In-Reply-To: <20181113193859.GJ3505@e103592.cambridge.arm.com>
On 13/11/18 19:39, Dave Martin wrote:
> On Mon, Nov 12, 2018 at 05:19:14AM -0800, Daniel Colascione wrote:
>> We should adopt a similar approach. Shipping a lower-level
>> "liblinux.so" tightly bound to the kernel would not only let the
>> kernel bypass glibc's "editorial discretion" in exposing new
>> facilities to userspace, but would also allow for tighter user-kernel
>> integration that one can achieve with a simplistic syscall(2)-style
>> escape hatch. (For example, for a long time now, I've wanted to go
>> beyond POSIX and improve the system's signal handling API, and this
>> improvement requires userspace cooperation.) The vdso is probably too
>> small and simplistic to serve in this role; I'd want a real library.
>
> Can you expand on your reasoning here?
such lib creates a useless abi+api layer that
somebody has to maintain and document (with or
without vdso).
it obviously cannot work together with a posix
conform libc implementation for which it would
require knowledge about
thread cancellation internals, potentially TLS
for errno, know libc types even ones that are
based on compile time feature macros (and expose
them in headers in a way that does not collide
with libc headers), abi variants the libc supports
(e.g. softfp, security hardened abi), libc
internal signals (for anything that's changing
signal masks), thread internals for syscalls that
require coordination between all user created
threads (setxid), libc internal state for syscalls
that create/destroy threads.
and thus such lib does not solve the problems
of users who actually requested wrappers for
new syscalls (since they want to call into libc
and create threads).
there is a lot of bikesheding here by people who
don't understand the constraints nor the use-cases.
an actual proposal in the thread that i think is
worth considering is to make the linux syscall
design process involve libc devs so the c api is
designed together with the syscall abi.
unfortunately i still haven't seen a solution that
makes using linux uapi headers together with libc
headers reliable, continuously testing them in
isolation is useful, but that does not solve the
potential conflicts with libc definitions.
^ permalink raw reply
* Re: Official Linux system wrapper library?
From: Florian Weimer @ 2018-11-14 11:40 UTC (permalink / raw)
To: Dave Martin
Cc: Andy Lutomirski, Daniel Colascione, Michael Kerrisk (man-pages),
linux-kernel, Joel Fernandes, Linux API, Willy Tarreau,
Vlastimil Babka, Carlos O'Donell, libc-alpha@sourceware.org
In-Reply-To: <20181114105449.GK3505@e103592.cambridge.arm.com>
* Dave Martin:
> Fair points, though this is rather what I meant by "sane essentials".
> Because there are strict limits on what can be done in the vDSO, it may
> be more bloat-resistant and more conservatively maintained.
>
> This might provide a way to push some dumb compatibility kludge code
> that receives little ongoing maintenance outside the privilege wall,
> whereas it has to sit in the kernel proper today.
>
> In theory we could opt to advertise new syscalls only via vDSO entry
> points, and not maintain __NR_xxx values for them (which may or may
> not upset ptrace users.) Anyway, I digress...
Is the vDSO available across all architectures? (I don't think we use
it on all architectures in glibc.)
If not, a vDSO-based approach would merely lead to even more variance
between architectures, which can't be a good thing.
Thanks,
Florian
^ permalink raw reply
* Re: Official Linux system wrapper library?
From: Dave Martin @ 2018-11-14 10:54 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Daniel Colascione, Florian Weimer, Michael Kerrisk (man-pages),
linux-kernel, Joel Fernandes, Linux API, Willy Tarreau,
Vlastimil Babka, Carlos O'Donell, libc-alpha@sourceware.org
In-Reply-To: <69B07026-5E8B-47FC-9313-E51E899FAFB0@amacapital.net>
On Tue, Nov 13, 2018 at 12:58:39PM -0800, Andy Lutomirski wrote:
>
> > On Nov 13, 2018, at 11:39 AM, Dave Martin <Dave.Martin@arm.com> wrote:
> >
> > On Mon, Nov 12, 2018 at 05:19:14AM -0800, Daniel Colascione wrote:
> >
> > [...]
> >
> >> We can learn something from how Windows does things. On that system,
> >> what we think of as "libc" is actually two parts. (More, actually, but
> >> I'm simplifying.) At the lowest level, you have the semi-documented
> >> ntdll.dll, which contains raw system call wrappers and arcane
> >> kernel-userland glue. On top of ntdll live the "real" libc
> >> (msvcrt.dll, kernel32.dll, etc.) that provide conventional
> >> application-level glue. The tight integration between ntdll.dll and
> >> the kernel allows Windows to do very impressive things. (For example,
> >> on x86_64, Windows has no 32-bit ABI as far as the kernel is
> >> concerned! You can still run 32-bit programs though, and that works
> >> via ntdll.dll essentially shimming every system call and switching the
> >> processor between long and compatibility mode as needed.) Normally,
> >> you'd use the higher-level capabilities, but if you need something in
> >> ntdll (e.g., if you're Cygwin) nothing stops your calling into the
> >> lower-level system facilities directly. ntdll is tightly bound to the
> >> kernel; the higher-level libc, not so.
> >>
> >> We should adopt a similar approach. Shipping a lower-level
> >> "liblinux.so" tightly bound to the kernel would not only let the
> >> kernel bypass glibc's "editorial discretion" in exposing new
> >> facilities to userspace, but would also allow for tighter user-kernel
> >> integration that one can achieve with a simplistic syscall(2)-style
> >> escape hatch. (For example, for a long time now, I've wanted to go
> >> beyond POSIX and improve the system's signal handling API, and this
> >> improvement requires userspace cooperation.) The vdso is probably too
> >> small and simplistic to serve in this role; I'd want a real library.
> >
> > Can you expand on your reasoning here?
> >
> > Playing devil's advocate:
> >
> > If the library is just exposing the syscall interface, I don't see
> > why it _couldn't_ fit into the vdso (or something vdso-like).
> >
> > If a separate library, I'd be concerned that it would accumulate
> > value-add bloat over time, and the kernel ABI may start to creep since
> > most software wouldn't invoke the kernel directly any more. Even if
> > it's maintained in the kernel tree, its existence as an apparently
> > standalone component may encourage forking, leading to a potential
> > compatibility mess.
> >
> > The vdso approach would mean we can guarantee that the library is
> > available and up to date at runtime, and may make it easier to keep
> > what's in it down to sane essentials.
>
> Hmm. Putting on my vDSO hat:
>
> The vDSO could provide all kinds of nifty things. Better exception
> handling comes to mind. But it has two major limitations that severely
> restrict what it can do:
>
> - It can’t allocate memory. We probably want to keep it that way.
>
> - It can’t use TLS. Solving this without genuinely awful ABI issues
> may be extremely hard. We *could* require callers to pass a thread
> pointer in, I suppose.
>
> Also, if we make the vDSO stateful, CRIU is going to have a blast. We
> might need to expose explicit save and restore abilities.
>
> As a straw man use case, it would be neat if DSOs (or the loader,
> maybe) could register a list of exception fixups per DSO. The kernel
> could consult these lists before delivering a signal. ISTM it wouldn’t
> be so crazy if the vDSO handled registration, although it could uses
> syscalls as well. If the vDSO did it, it would need somewhere to put
> the lists.
Fair points, though this is rather what I meant by "sane essentials".
Because there are strict limits on what can be done in the vDSO, it may
be more bloat-resistant and more conservatively maintained.
This might provide a way to push some dumb compatibility kludge code
that receives little ongoing maintenance outside the privilege wall,
whereas it has to sit in the kernel proper today.
In theory we could opt to advertise new syscalls only via vDSO entry
points, and not maintain __NR_xxx values for them (which may or may
not upset ptrace users.) Anyway, I digress...
Cheers
---Dave
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox