* [GIT PULL] asm-generic: syscall table script for arch/sh
From: Arnd Bergmann @ 2018-12-20 23:28 UTC (permalink / raw)
To: Linus Torvalds
Cc: Rich Felker, Firoz Khan, Linux API, y2038 Mailman List,
Linux Kernel Mailing List, Linux-sh list, Yoshinori Sato
The following changes since commit 2e6e902d185027f8e3cb8b7305238f7e35d6a436:
Linux 4.20-rc4 (2018-11-25 14:19:31 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git
tags/asm-generic-4.21
for you to fetch changes up to 2b3c5a99d5f314960e00950c1782eac9361de30f:
sh: generate uapi header and syscall table header files (2018-12-19
17:54:40 +0100)
----------------------------------------------------------------
asm-generic: syscall table script for arch/sh
I worked with Firoz Khan to change all architectures to have their system
call tables (syscall.S and asm/unistd.h) generated by a script from a more
readable input file the same way that we already had on x86, s390 and arm.
I offered to take those conversions through the asm-generic tree that
did not get picked up by the architecture maintainers, and fortunately
all but one have now been accepted into arch maintainer trees, so this
branch only contains the conversion for arch/sh/, with permission from
Rich.
The conversion does not include the old 64-bit sh5 architecture, which
has never shipped and not even compiled in a long time. The table
in include/uapi/asm/unistd.h is also not included here, as Firoz is
still working on that one. It will have to wait for the next following
merge window, hopefully together with the addition of the 64-bit
time_t system calls for the y2038 work that led to the system call
table rework.
Acked-by: Rich Felker <dalias@libc.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
----------------------------------------------------------------
Firoz Khan (3):
sh: add __NR_syscalls along with NR_syscalls
sh: add system call table generation support
sh: generate uapi header and syscall table header files
arch/sh/Makefile | 3 +
arch/sh/include/asm/Kbuild | 1 +
arch/sh/include/asm/unistd.h | 2 +
arch/sh/include/uapi/asm/Kbuild | 1 +
arch/sh/include/uapi/asm/unistd_32.h | 4 +-
arch/sh/include/uapi/asm/unistd_64.h | 4 +-
arch/sh/kernel/syscalls/Makefile | 38 +++++++++
arch/sh/kernel/syscalls/syscall.tbl | 392
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
arch/sh/kernel/syscalls/syscallhdr.sh | 36 ++++++++
arch/sh/kernel/syscalls/syscalltbl.sh | 32 +++++++
arch/sh/kernel/syscalls_32.S | 387
+-----------------------------------------------------------------------------------
11 files changed, 514 insertions(+), 386 deletions(-)
create mode 100644 arch/sh/kernel/syscalls/Makefile
create mode 100644 arch/sh/kernel/syscalls/syscall.tbl
create mode 100644 arch/sh/kernel/syscalls/syscallhdr.sh
create mode 100644 arch/sh/kernel/syscalls/syscalltbl.sh
^ permalink raw reply
* [GIT PULL] y2038: more syscalls and cleanups
From: Arnd Bergmann @ 2018-12-20 23:09 UTC (permalink / raw)
To: Linus Torvalds, Thomas Gleixner, y2038 Mailman List,
Deepa Dinamani, Linux FS-devel Mailing List, Linux API,
Linux Kernel Mailing List, Linux-sh list
Hi Linus and Thomas,
I realized that the merge window is now imminent, but I had not sent a
pull request to Thomas for the current y2038 stuff. These patches have
been around for a while though, and were in linux-next through my tree.
I got one bug report on Monday and incorporated a simple fix, which
changed the commit date for the second half of the series, in case you
are wondering.
Thomas, is it ok for you to just provide an Ack for this branch and
have Linus merge it directly?
Arnd
The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:
Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)
are available in the Git repository at:
https://git.kernel.org:/pub/scm/linux/kernel/git/arnd/playground.git
tags/y2038-for-4.21
for you to fetch changes up to e4b92b108c6cd6b311e4b6e85d6a87a34599a6e3:
timekeeping: remove obsolete time accessors (2018-12-18 16:13:05 +0100)
----------------------------------------------------------------
y2038: more syscalls and cleanups
This concludes the main part of the system call rework for 64-bit time_t,
which has spread over most of year 2018, the last six system calls being
- ppoll
- pselect6
- io_pgetevents
- recvmmsg
- futex
- rt_sigtimedwait
As before, nothing changes for 64-bit architectures, while 32-bit
architectures gain another entry point that differs only in the layout
of the timespec structure. Hopefully in the next release we can wire up
all 22 of those system calls on all 32-bit architectures, which gives
us a baseline version for glibc to start using them.
This does not include the clock_adjtime, getrusage/waitid, and
getitimer/setitimer system calls. I still plan to have new versions
of those as well, but they are not required for correct operation of
the C library since they can be emulated using the old 32-bit time_t
based system calls.
Aside from the system calls, there are also a few cleanups here,
removing old kernel internal interfaces that have become unused after
all references got removed. The arch/sh cleanups are part of this,
there were posted several times over the past year without a reaction
from the maintainers, while the corresponding changes made it into all
other architectures.
----------------------------------------------------------------
Arnd Bergmann (13):
y2038: futex: Move compat implementation into futex.c
y2038: futex: Add support for __kernel_timespec
y2038: socket: Add compat_sys_recvmmsg_time64
y2038: signal: Add sys_rt_sigtimedwait_time32
y2038: signal: Add compat_sys_rt_sigtimedwait_time64
sh: dreamcast: rtc: push down rtc class ops into driver
sh: sh03: rtc: push down rtc class ops into driver
sh: remove unused rtc_sh_get/set_time infrastructure
sh: remove board_time_init() callback
timekeeping: remove unused {read,update}_persistent_clock
timekeeping: remove timespec_add/timespec_del
vfs: replace current_kernel_time64 with ktime equivalent
timekeeping: remove obsolete time accessors
Deepa Dinamani (5):
signal: Add set_user_sigmask()
signal: Add restore_user_sigmask()
ppoll: use __kernel_timespec
pselect6: use __kernel_timespec
io_pgetevents: use __kernel_timespec
Documentation/sh/new-machine.txt | 8 --
arch/sh/boards/mach-dreamcast/Makefile | 4 +-
arch/sh/boards/mach-dreamcast/rtc.c | 45 +++++++---
arch/sh/boards/mach-dreamcast/setup.c | 1 -
arch/sh/boards/mach-sh03/Makefile | 3 +-
arch/sh/boards/mach-sh03/rtc.c | 51 ++++++-----
arch/sh/boards/mach-sh03/setup.c | 9 --
arch/sh/boards/of-generic.c | 8 --
arch/sh/configs/dreamcast_defconfig | 2 +
arch/sh/configs/sh03_defconfig | 2 +
arch/sh/include/asm/rtc.h | 3 -
arch/sh/include/mach-dreamcast/mach/sysasic.h | 1 -
arch/sh/kernel/time.c | 74 +---------------
fs/aio.c | 134
++++++++++++++++++++---------
fs/eventpoll.c | 52 ++----------
fs/inode.c | 4 +-
fs/select.c | 360
+++++++++++++++++++++++++++++++++++++++++++++---------------------------------
include/linux/compat.h | 26 ++++++
include/linux/futex.h | 8 --
include/linux/signal.h | 4 +
include/linux/socket.h | 9 +-
include/linux/syscalls.h | 29 +++++--
include/linux/time32.h | 25 ------
include/linux/timekeeping.h | 14 ---
include/linux/timekeeping32.h | 15 ----
kernel/Makefile | 3 -
kernel/futex.c | 207
+++++++++++++++++++++++++++++++++++++++++++--
kernel/futex_compat.c | 202
--------------------------------------------
kernel/signal.c | 143
+++++++++++++++++++++++++++++++
kernel/sys_ni.c | 2 +
kernel/time/ntp.c | 10 +--
kernel/time/time.c | 36 --------
kernel/time/timekeeping.c | 12 +--
net/compat.c | 34 +++-----
net/socket.c | 62 ++++++++++----
35 files changed, 847 insertions(+), 755 deletions(-)
delete mode 100644 kernel/futex_compat.c
^ permalink raw reply
* Re: [PATCH v5 1/1] signal: add pidfd_send_signal() syscall
From: Christian Brauner @ 2018-12-17 17:10 UTC (permalink / raw)
To: Serge E. Hallyn, ebiederm
Cc: linux-kernel, linux-api, luto, arnd, keescook, jannh, akpm, oleg,
cyphar, viro, linux-fsdevel, dancol, timmurray, fweimer, tglx,
x86
In-Reply-To: <20181213222300.GA9648@mail.hallyn.com>
On Thu, Dec 13, 2018 at 04:23:00PM -0600, Serge Hallyn wrote:
> On Sat, Dec 08, 2018 at 06:40:59AM +0100, Christian Brauner wrote:
> > The kill() syscall operates on process identifiers (pid). After a process
> > has exited its pid can be reused by another process. If a caller sends a
> > signal to a reused pid it will end up signaling the wrong process. This
> > issue has often surfaced and there has been a push to address this problem [1].
> >
> > This patch uses file descriptors (fd) from proc/<pid> as stable handles on
> > struct pid. Even if a pid is recycled the handle will not change. The fd
> > can be used to send signals to the process it refers to.
> > Thus, the new syscall pidfd_send_signal() is introduced to solve this
> > problem. Instead of pids it operates on process fds (pidfd).
> >
> > /* prototype and argument /*
> > long pidfd_send_signal(int pidfd, int sig, siginfo_t *info, unsigned int flags);
> >
> > In addition to the pidfd and signal argument it takes an additional
> > siginfo_t and flags argument. If the siginfo_t argument is NULL then
> > pidfd_send_signal() is equivalent to kill(<positive-pid>, <signal>). If it
> > is not NULL pidfd_send_signal() is equivalent to rt_sigqueueinfo().
> > The flags argument is added to allow for future extensions of this syscall.
> > It currently needs to be passed as 0. Failing to do so will cause EINVAL.
> >
> > /* pidfd_send_signal() replaces multiple pid-based syscalls */
> > The pidfd_send_signal() syscall currently takes on the job of
> > rt_sigqueueinfo(2) and parts of the functionality of kill(2), Namely, when a
> > positive pid is passed to kill(2). It will however be possible to also
> > replace tgkill(2) and rt_tgsigqueueinfo(2) if this syscall is extended.
> >
> > /* sending signals to threads (tid) and process groups (pgid) */
> > Specifically, the pidfd_send_signal() syscall does currently not operate on
> > process groups or threads. This is left for future extensions.
> > In order to extend the syscall to allow sending signal to threads and
> > process groups appropriately named flags (e.g. PIDFD_TYPE_PGID, and
> > PIDFD_TYPE_TID) should be added. This implies that the flags argument will
> > determine what is signaled and not the file descriptor itself. Put in other
> > words, grouping in this api is a property of the flags argument not a
> > property of the file descriptor (cf. [13]).
> > When appropriate extensions through the flags argument are added then
> > pidfd_send_signal() can additionally replace the part of kill(2) which
> > operates on process groups as well as the tgkill(2) and
> > rt_tgsigqueueinfo(2) syscalls.
> > How such an extension could be implemented has been very roughly sketched
> > in [14], [15], and [16]. However, this should not be taken as a commitment
> > to a particular implementation. There might be better ways to do it.
> > Right now this is intentionally left out to keep this patchset as simple as
> > possible (cf. [4]). For example, if a pidfd for a tid from
> > /proc/<pid>/task/<tid> is passed EOPNOTSUPP will be returned to give
> > userspace a way to detect when I add support for signaling to threads (cf. [10]).
> >
> > /* naming */
> > The syscall had various names throughout iterations of this patchset:
> > - procfd_signal()
> > - procfd_send_signal()
> > - taskfd_send_signal()
> > In the last round of reviews it was pointed out that given that if the
> > flags argument decides the scope of the signal instead of different types
> > of fds it might make sense to either settle for "procfd_" or "pidfd_" as
> > prefix. The community was willing to accept either (cf. [17] and [18]).
> > Given that one developer expressed strong preference for the "pidfd_"
> > prefix (cf. [13] and with other developers less opinionated about the name
> > we should settle for "pidfd_" to avoid further bikeshedding.
> >
> > The "_send_signal" suffix was chosen to reflect the fact that the syscall
> > takes on the job of multiple syscalls. It is therefore intentional that the
> > name is not reminiscent of neither kill(2) nor rt_sigqueueinfo(2). Not the
> > fomer because it might imply that pidfd_send_signal() is a replacement for
> > kill(2), and not the latter because it is a hassle to remember the correct
> > spelling - especially for non-native speakers - and because it is not
> > descriptive enough of what the syscall actually does. The name
> > "pidfd_send_signal" makes it very clear that its job is to send signals.
> >
> > /* O_PATH file descriptors */
> > pidfds opened as O_PATH fds cannot be used to send signals to a process
> > (cf. [2]). Signaling processes through pidfds is the equivalent of writing
> > to a file. Thus, this is not an operation that operates "purely at the file
> > descriptor level" as required by the open(2) manpage.
> >
> > /* zombies */
> > Zombies can be signaled just as any other process. No special error will be
> > reported since a zombie state is an unreliable state (cf. [3]). However,
> > this can be added as an extension through the @flags argument if the need
> > ever arises.
> >
> > /* cross-namespace signals */
> > The patch currently enforces that the signaler and signalee either are in
> > the same pid namespace or that the signaler's pid namespace is an ancestor
> > of the signalee's pid namespace. This is done for the sake of simplicity
> > and because it is unclear to what values certain members of struct
> > siginfo_t would need to be set to (cf. [5], [6]).
> >
> > /* compat syscalls */
> > It became clear that we would like to avoid adding compat syscalls
> > (cf. [7]). The compat syscall handling is now done in kernel/signal.c
> > itself by adding __copy_siginfo_from_user_generic() which lets us avoid
> > compat syscalls (cf. [8]). It should be noted that the addition of
> > __copy_siginfo_from_user_any() is caused by a bug in the original
> > implementation of rt_sigqueueinfo(2) (cf. 12).
> > With upcoming rework for syscall handling things might improve
> > significantly (cf. [11]) and __copy_siginfo_from_user_any() will not gain
> > any additional callers.
> >
> > /* testing */
> > This patch was tested on x64 and x86.
> >
> > /* userspace usage */
> > An asciinema recording for the basic functionality can be found under [9].
> > With this patch a process can be killed via:
> >
> > #define _GNU_SOURCE
> > #include <errno.h>
> > #include <fcntl.h>
> > #include <signal.h>
> > #include <stdio.h>
> > #include <stdlib.h>
> > #include <string.h>
> > #include <sys/stat.h>
> > #include <sys/syscall.h>
> > #include <sys/types.h>
> > #include <unistd.h>
> >
> > static inline int do_pidfd_send_signal(int pidfd, int sig, siginfo_t *info,
> > unsigned int flags)
> > {
> > #ifdef __NR_pidfd_send_signal
> > return syscall(__NR_pidfd_send_signal, pidfd, sig, info, flags);
> > #else
> > return -ENOSYS;
> > #endif
> > }
> >
> > int main(int argc, char *argv[])
> > {
> > int fd, ret, saved_errno, sig;
> >
> > if (argc < 3)
> > exit(EXIT_FAILURE);
> >
> > fd = open(argv[1], O_DIRECTORY | O_CLOEXEC);
> > if (fd < 0) {
> > printf("%s - Failed to open \"%s\"\n", strerror(errno), argv[1]);
> > exit(EXIT_FAILURE);
> > }
> >
> > sig = atoi(argv[2]);
> >
> > printf("Sending signal %d to process %s\n", sig, argv[1]);
> > ret = do_pidfd_send_signal(fd, sig, NULL, 0);
> >
> > saved_errno = errno;
> > close(fd);
> > errno = saved_errno;
> >
> > if (ret < 0) {
> > printf("%s - Failed to send signal %d to process %s\n",
> > strerror(errno), sig, argv[1]);
> > exit(EXIT_FAILURE);
> > }
> >
> > exit(EXIT_SUCCESS);
> > }
> >
> > [1]: https://lore.kernel.org/lkml/20181029221037.87724-1-dancol@google.com/
> > [2]: https://lore.kernel.org/lkml/874lbtjvtd.fsf@oldenburg2.str.redhat.com/
> > [3]: https://lore.kernel.org/lkml/20181204132604.aspfupwjgjx6fhva@brauner.io/
> > [4]: https://lore.kernel.org/lkml/20181203180224.fkvw4kajtbvru2ku@brauner.io/
> > [5]: https://lore.kernel.org/lkml/20181121213946.GA10795@mail.hallyn.com/
> > [6]: https://lore.kernel.org/lkml/20181120103111.etlqp7zop34v6nv4@brauner.io/
> > [7]: https://lore.kernel.org/lkml/36323361-90BD-41AF-AB5B-EE0D7BA02C21@amacapital.net/
> > [8]: https://lore.kernel.org/lkml/87tvjxp8pc.fsf@xmission.com/
> > [9]: https://asciinema.org/a/IQjuCHew6bnq1cr78yuMv16cy
> > [10]: https://lore.kernel.org/lkml/20181203180224.fkvw4kajtbvru2ku@brauner.io/
> > [11]: https://lore.kernel.org/lkml/F53D6D38-3521-4C20-9034-5AF447DF62FF@amacapital.net/
> > [12]: https://lore.kernel.org/lkml/87zhtjn8ck.fsf@xmission.com/
> > [13]: https://lore.kernel.org/lkml/871s6u9z6u.fsf@xmission.com/
> > [14]: https://lore.kernel.org/lkml/20181206231742.xxi4ghn24z4h2qki@brauner.io/
> > [15]: https://lore.kernel.org/lkml/20181207003124.GA11160@mail.hallyn.com/
> > [16]: https://lore.kernel.org/lkml/20181207015423.4miorx43l3qhppfz@brauner.io/
> > [17]: https://lore.kernel.org/lkml/CAGXu5jL8PciZAXvOvCeCU3wKUEB_dU-O3q0tDw4uB_ojMvDEew@mail.gmail.com/
> > [18]: https://lore.kernel.org/lkml/20181206222746.GB9224@mail.hallyn.com/
> >
> > Cc: "Eric W. Biederman" <ebiederm@xmission.com>
>
> Hi Eric,
>
> have you had a chance to look at the latest version?
>
> -serge
Hi Eric,
Gentle ping again: Have you had a chance to look at the latest version?
I'm not sure if you saw Serge's ping.
If there are no objections I would very much like to see this land in
-next for some testing. Especially, given that we have accumulated some
acks and reviews for the patch by now. :)
Christian
>
> > Cc: Jann Horn <jannh@google.com>
> > Cc: Andy Lutomirsky <luto@kernel.org>
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Oleg Nesterov <oleg@redhat.com>
> > Cc: Al Viro <viro@zeniv.linux.org.uk>
> > Cc: Florian Weimer <fweimer@redhat.com>
> > Signed-off-by: Christian Brauner <christian@brauner.io>
> > Reviewed-by: Kees Cook <keescook@chromium.org>
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
> > Acked-by: Serge Hallyn <serge@hallyn.com>
> > Acked-by: Aleksa Sarai <cyphar@cyphar.com>
> > ---
> > Changelog:
> > v5:
> > - s/may_signal_taskfd/access_taskfd_pidns/g
> > - make it clear that process grouping is a property of the @flags argument
> > Eric has argued that he would like to know when we add thread and process
> > group signal support whether grouping will be a property of the file
> > descriptor or the flag argument and he would oppose this until a
> > commitment has been made. It seems that the cleanest strategy is to make
> > grouping a property of the @flags argument.
> > He also argued that in this case the prefix of the syscall should be
> > "pidfd_" (cf. https://lore.kernel.org/lkml/871s6u9z6u.fsf@xmission.com/).
> > - use "pidfd_" as prefix for the syscall since grouping will be a property
> > of the @flags argument
> > - substantial rewrite of the commit message to reflect the discussion
> > v4:
> > - updated asciinema to use "taskfd_" prefix
> > - s/procfd_send_signal/taskfd_send_signal/g
> > - s/proc_is_tgid_procfd/tgid_taskfd_to_pid/b
> > - s/proc_is_tid_procfd/tid_taskfd_to_pid/b
> > - s/__copy_siginfo_from_user_generic/__copy_siginfo_from_user_any/g
> > - make it clear that __copy_siginfo_from_user_any() is a workaround caused
> > by a bug in the original implementation of rt_sigqueueinfo()
> > - when spoofing signals turn them into regular kill signals if si_code is
> > set to SI_USER
> > - make proc_is_t{g}id_procfd() return struct pid to allow proc_pid() to
> > stay private to fs/proc/
> > v3:
> > - add __copy_siginfo_from_user_generic() to avoid adding compat syscalls
> > - s/procfd_signal/procfd_send_signal/g
> > - change type of flags argument from int to unsigned int
> > - add comment about what happens to zombies
> > - add proc_is_tid_procfd()
> > - return EOPNOTSUPP when /proc/<pid>/task/<tid> fd is passed so userspace
> > has a way of knowing that tidfds are not supported currently.
> > v2:
> > - define __NR_procfd_signal in unistd.h
> > - wire up compat syscall
> > - s/proc_is_procfd/proc_is_tgid_procfd/g
> > - provide stubs when CONFIG_PROC_FS=n
> > - move proc_pid() to linux/proc_fs.h header
> > - use proc_pid() to grab struct pid from /proc/<pid> fd
> > v1:
> > - patch introduced
> > ---
> > arch/x86/entry/syscalls/syscall_32.tbl | 1 +
> > arch/x86/entry/syscalls/syscall_64.tbl | 1 +
> > fs/proc/base.c | 20 +++-
> > include/linux/proc_fs.h | 12 +++
> > include/linux/syscalls.h | 3 +
> > include/uapi/asm-generic/unistd.h | 4 +-
> > kernel/signal.c | 141 +++++++++++++++++++++++--
> > 7 files changed, 173 insertions(+), 9 deletions(-)
> >
> > diff --git a/arch/x86/entry/syscalls/syscall_32.tbl b/arch/x86/entry/syscalls/syscall_32.tbl
> > index 3cf7b533b3d1..6804c1e84b36 100644
> > --- a/arch/x86/entry/syscalls/syscall_32.tbl
> > +++ b/arch/x86/entry/syscalls/syscall_32.tbl
> > @@ -398,3 +398,4 @@
> > 384 i386 arch_prctl sys_arch_prctl __ia32_compat_sys_arch_prctl
> > 385 i386 io_pgetevents sys_io_pgetevents __ia32_compat_sys_io_pgetevents
> > 386 i386 rseq sys_rseq __ia32_sys_rseq
> > +387 i386 pidfd_send_signal sys_pidfd_send_signal __ia32_sys_pidfd_send_signal
> > diff --git a/arch/x86/entry/syscalls/syscall_64.tbl b/arch/x86/entry/syscalls/syscall_64.tbl
> > index f0b1709a5ffb..aa4b858fa0f1 100644
> > --- a/arch/x86/entry/syscalls/syscall_64.tbl
> > +++ b/arch/x86/entry/syscalls/syscall_64.tbl
> > @@ -343,6 +343,7 @@
> > 332 common statx __x64_sys_statx
> > 333 common io_pgetevents __x64_sys_io_pgetevents
> > 334 common rseq __x64_sys_rseq
> > +335 common pidfd_send_signal __x64_sys_pidfd_send_signal
> >
> > #
> > # x32-specific system call numbers start at 512 to avoid cache impact
> > diff --git a/fs/proc/base.c b/fs/proc/base.c
> > index ce3465479447..bf680b7b603a 100644
> > --- a/fs/proc/base.c
> > +++ b/fs/proc/base.c
> > @@ -716,8 +716,6 @@ static int proc_pid_permission(struct inode *inode, int mask)
> > return generic_permission(inode, mask);
> > }
> >
> > -
> > -
> > static const struct inode_operations proc_def_inode_operations = {
> > .setattr = proc_setattr,
> > };
> > @@ -3038,6 +3036,15 @@ static const struct file_operations proc_tgid_base_operations = {
> > .llseek = generic_file_llseek,
> > };
> >
> > +struct pid *tgid_pidfd_to_pid(const struct file *file)
> > +{
> > + if (!d_is_dir(file->f_path.dentry) ||
> > + (file->f_op != &proc_tgid_base_operations))
> > + return ERR_PTR(-EBADF);
> > +
> > + return proc_pid(file_inode(file));
> > +}
> > +
> > static struct dentry *proc_tgid_base_lookup(struct inode *dir, struct dentry *dentry, unsigned int flags)
> > {
> > return proc_pident_lookup(dir, dentry,
> > @@ -3422,6 +3429,15 @@ static const struct file_operations proc_tid_base_operations = {
> > .llseek = generic_file_llseek,
> > };
> >
> > +struct pid *tid_pidfd_to_pid(const struct file *file)
> > +{
> > + if (!d_is_dir(file->f_path.dentry) ||
> > + (file->f_op != &proc_tid_base_operations))
> > + return ERR_PTR(-EBADF);
> > +
> > + return proc_pid(file_inode(file));
> > +}
> > +
> > static const struct inode_operations proc_tid_base_inode_operations = {
> > .lookup = proc_tid_base_lookup,
> > .getattr = pid_getattr,
> > diff --git a/include/linux/proc_fs.h b/include/linux/proc_fs.h
> > index d0e1f1522a78..eb150e5c0ab8 100644
> > --- a/include/linux/proc_fs.h
> > +++ b/include/linux/proc_fs.h
> > @@ -73,6 +73,8 @@ struct proc_dir_entry *proc_create_net_single_write(const char *name, umode_t mo
> > int (*show)(struct seq_file *, void *),
> > proc_write_t write,
> > void *data);
> > +extern struct pid *tgid_pidfd_to_pid(const struct file *file);
> > +extern struct pid *tid_pidfd_to_pid(const struct file *file);
> >
> > #else /* CONFIG_PROC_FS */
> >
> > @@ -114,6 +116,16 @@ static inline int remove_proc_subtree(const char *name, struct proc_dir_entry *p
> > #define proc_create_net(name, mode, parent, state_size, ops) ({NULL;})
> > #define proc_create_net_single(name, mode, parent, show, data) ({NULL;})
> >
> > +static inline struct pid *tgid_pidfd_to_pid(const struct file *file)
> > +{
> > + return ERR_PTR(-EBADF);
> > +}
> > +
> > +static inline struct pid *tid_pidfd_to_pid(const struct file *file)
> > +{
> > + return ERR_PTR(-EBADF);
> > +}
> > +
> > #endif /* CONFIG_PROC_FS */
> >
> > struct net;
> > diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
> > index 2ac3d13a915b..fd85b9045a9f 100644
> > --- a/include/linux/syscalls.h
> > +++ b/include/linux/syscalls.h
> > @@ -907,6 +907,9 @@ asmlinkage long sys_statx(int dfd, const char __user *path, unsigned flags,
> > unsigned mask, struct statx __user *buffer);
> > asmlinkage long sys_rseq(struct rseq __user *rseq, uint32_t rseq_len,
> > int flags, uint32_t sig);
> > +asmlinkage long sys_pidfd_send_signal(int pidfd, int sig,
> > + siginfo_t __user *info,
> > + unsigned int flags);
> >
> > /*
> > * Architecture-specific system calls
> > diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h
> > index 538546edbfbd..0822abc5927a 100644
> > --- a/include/uapi/asm-generic/unistd.h
> > +++ b/include/uapi/asm-generic/unistd.h
> > @@ -738,9 +738,11 @@ __SYSCALL(__NR_statx, sys_statx)
> > __SC_COMP(__NR_io_pgetevents, sys_io_pgetevents, compat_sys_io_pgetevents)
> > #define __NR_rseq 293
> > __SYSCALL(__NR_rseq, sys_rseq)
> > +#define __NR_pidfd_send_signal 294
> > +__SYSCALL(__NR_pidfd_send_signal, sys_pidfd_send_signal)
> >
> > #undef __NR_syscalls
> > -#define __NR_syscalls 294
> > +#define __NR_syscalls 295
> >
> > /*
> > * 32 bit systems traditionally used different
> > diff --git a/kernel/signal.c b/kernel/signal.c
> > index 9a32bc2088c9..3c83d3a5c7c5 100644
> > --- a/kernel/signal.c
> > +++ b/kernel/signal.c
> > @@ -19,7 +19,9 @@
> > #include <linux/sched/task.h>
> > #include <linux/sched/task_stack.h>
> > #include <linux/sched/cputime.h>
> > +#include <linux/file.h>
> > #include <linux/fs.h>
> > +#include <linux/proc_fs.h>
> > #include <linux/tty.h>
> > #include <linux/binfmts.h>
> > #include <linux/coredump.h>
> > @@ -3286,6 +3288,16 @@ COMPAT_SYSCALL_DEFINE4(rt_sigtimedwait, compat_sigset_t __user *, uthese,
> > }
> > #endif
> >
> > +static inline void prepare_kill_siginfo(int sig, struct kernel_siginfo *info)
> > +{
> > + clear_siginfo(info);
> > + info->si_signo = sig;
> > + info->si_errno = 0;
> > + info->si_code = SI_USER;
> > + info->si_pid = task_tgid_vnr(current);
> > + info->si_uid = from_kuid_munged(current_user_ns(), current_uid());
> > +}
> > +
> > /**
> > * sys_kill - send a signal to a process
> > * @pid: the PID of the process
> > @@ -3295,16 +3307,133 @@ SYSCALL_DEFINE2(kill, pid_t, pid, int, sig)
> > {
> > struct kernel_siginfo info;
> >
> > - clear_siginfo(&info);
> > - info.si_signo = sig;
> > - info.si_errno = 0;
> > - info.si_code = SI_USER;
> > - info.si_pid = task_tgid_vnr(current);
> > - info.si_uid = from_kuid_munged(current_user_ns(), current_uid());
> > + prepare_kill_siginfo(sig, &info);
> >
> > return kill_something_info(sig, &info, pid);
> > }
> >
> > +/*
> > + * Verify that the signaler and signalee either are in the same pid namespace
> > + * or that the signaler's pid namespace is an ancestor of the signalee's pid
> > + * namespace.
> > + */
> > +static bool access_pidfd_pidns(struct pid *pid)
> > +{
> > + struct pid_namespace *active = task_active_pid_ns(current);
> > + struct pid_namespace *p = ns_of_pid(pid);
> > +
> > + for (;;) {
> > + if (!p)
> > + return false;
> > + if (p == active)
> > + break;
> > + p = p->parent;
> > + }
> > +
> > + return true;
> > +}
> > +
> > +static int copy_siginfo_from_user_any(kernel_siginfo_t *kinfo, siginfo_t *info)
> > +{
> > +#ifdef CONFIG_COMPAT
> > + /*
> > + * Avoid hooking up compat syscalls and instead handle necessary
> > + * conversions here. Note, this is a stop-gap measure and should not be
> > + * considered a generic solution.
> > + */
> > + if (in_compat_syscall())
> > + return copy_siginfo_from_user32(
> > + kinfo, (struct compat_siginfo __user *)info);
> > +#endif
> > + return copy_siginfo_from_user(kinfo, info);
> > +}
> > +
> > +/**
> > + * sys_pidfd_send_signal - send a signal to a process through a task file
> > + * descriptor
> > + * @pidfd: the file descriptor of the process
> > + * @sig: signal to be sent
> > + * @info: the signal info
> > + * @flags: future flags to be passed
> > + *
> > + * The syscall currently only signals via PIDTYPE_PID which covers
> > + * kill(<positive-pid>, <signal>. It does not signal threads or process
> > + * groups.
> > + * In order to extend the syscall to threads and process groups the @flags
> > + * argument should be used. In essence, the @flags argument will determine
> > + * what is signaled and not the file descriptor itself. Put in other words,
> > + * grouping is a property of the flags argument not a property of the file
> > + * descriptor.
> > + *
> > + * Return: 0 on success, negative errno on failure
> > + */
> > +SYSCALL_DEFINE4(pidfd_send_signal, int, pidfd, int, sig,
> > + siginfo_t __user *, info, unsigned int, flags)
> > +{
> > + int ret;
> > + struct fd f;
> > + struct pid *pid;
> > + kernel_siginfo_t kinfo;
> > +
> > + /* Enforce flags be set to 0 until we add an extension. */
> > + if (flags)
> > + return -EINVAL;
> > +
> > + f = fdget_raw(pidfd);
> > + if (!f.file)
> > + return -EBADF;
> > +
> > + pid = tid_pidfd_to_pid(f.file);
> > + if (!IS_ERR(pid)) {
> > + /*
> > + * Give userspace a way to detect /proc/<pid>/task/<tid>
> > + * support when we add it.
> > + */
> > + ret = -EOPNOTSUPP;
> > + goto err;
> > + }
> > +
> > + /* Is this a pidfd? */
> > + pid = tgid_pidfd_to_pid(f.file);
> > + if (IS_ERR(pid)) {
> > + ret = PTR_ERR(pid);
> > + goto err;
> > + }
> > +
> > + ret = -EINVAL;
> > + if (!access_pidfd_pidns(pid))
> > + goto err;
> > +
> > + if (info) {
> > + ret = copy_siginfo_from_user_any(&kinfo, info);
> > + if (unlikely(ret))
> > + goto err;
> > +
> > + ret = -EINVAL;
> > + if (unlikely(sig != kinfo.si_signo))
> > + goto err;
> > +
> > + if ((task_pid(current) != pid) &&
> > + (kinfo.si_code >= 0 || kinfo.si_code == SI_TKILL)) {
> > + /* Only allow sending arbitrary signals to yourself. */
> > + ret = -EPERM;
> > + if (kinfo.si_code != SI_USER)
> > + goto err;
> > +
> > + /* Turn this into a regular kill signal. */
> > + prepare_kill_siginfo(sig, &kinfo);
> > + }
> > + } else {
> > + prepare_kill_siginfo(sig, &kinfo);
> > + }
> > +
> > + ret = kill_pid_info(sig, &kinfo, pid);
> > +
> > +err:
> > + fdput(f);
> > + return ret;
> > +}
> > +
> > static int
> > do_send_specific(pid_t tgid, pid_t pid, int sig, struct kernel_siginfo *info)
> > {
> > --
> > 2.19.1
^ permalink raw reply
* Re: Can we drop upstream Linux x32 support?
From: Andy Lutomirski @ 2018-12-15 15:30 UTC (permalink / raw)
To: Thomas Schoebel-Theuer
Cc: Andy Lutomirski, X86 ML, LKML, Linux API, H. Peter Anvin,
Peter Zijlstra, Borislav Petkov, Florian Weimer, Mike Frysinger,
H. J. Lu, Rich Felker, x32, Arnd Bergmann, Will Deacon,
Catalin Marinas, Linus Torvalds
In-Reply-To: <54449048-a057-5005-1b50-b884628643eb@schoebel-theuer.de>
> On Dec 14, 2018, at 11:41 PM, Thomas Schoebel-Theuer <tst@schoebel-theuer.de> wrote:
>
>> On 12/14/18 22:41, Thomas Schöbel-Theuer wrote:
>>> On 12/14/18 22:24, Andy Lutomirski wrote:
>>>
>>> I'm talking about x32, which is a different beast.
>>>
>>
>> So from my viewpoint the mentioned roadmap / timing requirements will remain the same, whatever you are dropping.
>>
>> Enterprise-critical use cases will probably need to be migrated to KVM/qemu together with their old kernel versions, anyway (because the original hardware will be no longer available in a few decades).
>>
>
> Here is a systematic approach to the problem.
>
This is way off topic. Let’s not discuss it on this thread, please.
^ permalink raw reply
* [PATCH 4/4] vt: ignore sequences that contain ':' in parameters.
From: Martin Hostettler @ 2018-12-15 14:34 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: linux-kernel, linux-api, Nicolas Pitre, Adam Borowski,
Egmont Koblinger, Martin Hostettler
In-Reply-To: <20181215143423.4556-1-textshell@uchuujin.de>
csi sequences can contain subparameters delimited by ':' characters. For
now just ignore the whole sequence in this case. Such sequences are used by
more capable terminal implementations with T.416 high color modes or
extended underline rendition attributes.
Also ignore sequences with private use characters '?', '>', '='
and '>' that are not at the initial position.
Signed-off-by: Martin Hostettler <textshell@uchuujin.de>
---
drivers/tty/vt/vt.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 24cd0e9c037b..0aaa15c723fa 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1629,9 +1629,9 @@ static void rgb_background(struct vc_data *vc, const struct rgb *c)
/*
* ITU T.416 Higher colour modes. They break the usual properties of SGR codes
- * and thus need to be detected and ignored by hand. Strictly speaking, that
- * standard also wants : rather than ; as separators, contrary to ECMA-48, but
- * no one produces such codes and almost no one accepts them.
+ * and thus need to be detected and ignored by hand. That standard also
+ * wants : rather than ; as separators but sequences containing : are currently
+ * completely ignored by the parser.
*
* Subcommands 3 (CMY) and 4 (CMYK) are so insane there's no point in
* supporting them.
@@ -2259,7 +2259,7 @@ static void do_con_trol(struct tty_struct *tty, struct vc_data *vc, int c)
vc->vc_par[vc->vc_npar] += c - '0';
return;
}
- if (c >= 0x20 && c <= 0x2f) {
+ if (c >= 0x20 && c <= 0x3f) { /* 0x2x, 0x3a and 0x3c - 0x3f */
vc->vc_state = EScsiignore;
return;
}
--
2.11.0
^ permalink raw reply related
* [PATCH 3/4] vt: ignore csi sequences with intermediate characters.
From: Martin Hostettler @ 2018-12-15 14:34 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: linux-kernel, linux-api, Nicolas Pitre, Adam Borowski,
Egmont Koblinger, Martin Hostettler
In-Reply-To: <20181215143423.4556-1-textshell@uchuujin.de>
Various csi sequences contain intermediate characters between the
parameters and the final character. Introduce a additional state that
cleanly ignores these sequences.
This allows the vt to ignore these sequences used by more capable
terminal implementations such as "request mode", etc.
Signed-off-by: Martin Hostettler <textshell@uchuujin.de>
---
drivers/tty/vt/vt.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 448b4f6be7d1..24cd0e9c037b 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -2023,7 +2023,7 @@ static void restore_cur(struct vc_data *vc)
}
enum { ESnormal, ESesc, ESsquare, ESgetpars, ESfunckey,
- EShash, ESsetG0, ESsetG1, ESpercent, ESignore, ESnonstd,
+ EShash, ESsetG0, ESsetG1, ESpercent, EScsiignore, ESnonstd,
ESpalette, ESosc };
/* console_lock is held (except via vc_init()) */
@@ -2259,6 +2259,10 @@ static void do_con_trol(struct tty_struct *tty, struct vc_data *vc, int c)
vc->vc_par[vc->vc_npar] += c - '0';
return;
}
+ if (c >= 0x20 && c <= 0x2f) {
+ vc->vc_state = EScsiignore;
+ return;
+ }
vc->vc_state = ESnormal;
switch(c) {
case 'h':
@@ -2421,6 +2425,11 @@ static void do_con_trol(struct tty_struct *tty, struct vc_data *vc, int c)
return;
}
return;
+ case EScsiignore:
+ if (c >= 20 && c <= 0x3f)
+ return;
+ vc->vc_state = ESnormal;
+ return;
case ESpercent:
vc->vc_state = ESnormal;
switch (c) {
--
2.11.0
^ permalink raw reply related
* [PATCH 2/4] vt: Implement parsing for >, =, < private sequences.
From: Martin Hostettler @ 2018-12-15 14:34 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: linux-kernel, linux-api, Nicolas Pitre, Adam Borowski,
Egmont Koblinger, Martin Hostettler
In-Reply-To: <20181215143423.4556-1-textshell@uchuujin.de>
Private sequences can start with '>', '=' and (in theory) '<'.
Implement correct parsing for these. The newly parsable sequences are
cleanly ignored as it is customary with terminal emulators.
This allows the vt to ignore various sequences used by more capable
terminal implementations such as "Secondary Device Attributes",
"Tertiary Device Attributes" and various advanced configuration commands
that don't have dedicated terminfo entries.
Signed-off-by: Martin Hostettler <textshell@uchuujin.de>
---
drivers/tty/vt/vt.c | 22 ++++++++++++++++++----
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 75826a97b0c3..448b4f6be7d1 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -2235,9 +2235,21 @@ static void do_con_trol(struct tty_struct *tty, struct vc_data *vc, int c)
vc->vc_state=ESfunckey;
return;
}
- vc->vc_priv = (c == '?') ? EPdec : EPecma;
- if (vc->vc_priv != EPecma)
+ switch (c) {
+ case '?':
+ vc->vc_priv = EPdec;
+ return;
+ case '>':
+ vc->vc_priv = EPgt;
+ return;
+ case '=':
+ vc->vc_priv = EPeq;
return;
+ case '<':
+ vc->vc_priv = EPlt;
+ return;
+ }
+ vc->vc_priv = EPecma;
case ESgetpars:
if (c == ';' && vc->vc_npar < NPAR - 1) {
vc->vc_npar++;
@@ -2250,10 +2262,12 @@ static void do_con_trol(struct tty_struct *tty, struct vc_data *vc, int c)
vc->vc_state = ESnormal;
switch(c) {
case 'h':
- set_mode(vc, 1);
+ if (vc->vc_priv <= EPdec)
+ set_mode(vc, 1);
return;
case 'l':
- set_mode(vc, 0);
+ if (vc->vc_priv <= EPdec)
+ set_mode(vc, 0);
return;
case 'c':
if (vc->vc_priv == EPdec) {
--
2.11.0
^ permalink raw reply related
* [PATCH 1/4] vt: refactor vc_ques to allow of other private sequences.
From: Martin Hostettler @ 2018-12-15 14:34 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: linux-kernel, linux-api, Nicolas Pitre, Adam Borowski,
Egmont Koblinger, Martin Hostettler
In-Reply-To: <20181215143423.4556-1-textshell@uchuujin.de>
The vc_ques keeps track if a csi sequence is a private DEC control
function beginning with '?'. Nowadays some private control functions
begin with '>' and '='. Switch the code to instead use a new 3-bit
vc_priv that allows for all private use parameter prefixes.
Signed-off-by: Martin Hostettler <textshell@uchuujin.de>
---
drivers/tty/vt/vt.c | 20 +++++++++++---------
include/linux/console_struct.h | 2 +-
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 41ec8e5010f3..75826a97b0c3 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1341,6 +1341,8 @@ struct vc_data *vc_deallocate(unsigned int currcons)
* VT102 emulator
*/
+enum { EPecma = 0, EPdec, EPeq, EPgt, EPlt};
+
#define set_kbd(vc, x) vt_set_kbd_mode_bit((vc)->vc_num, (x))
#define clr_kbd(vc, x) vt_clr_kbd_mode_bit((vc)->vc_num, (x))
#define is_kbd(vc, x) vt_get_kbd_mode_bit((vc)->vc_num, (x))
@@ -1814,7 +1816,7 @@ static void set_mode(struct vc_data *vc, int on_off)
int i;
for (i = 0; i <= vc->vc_npar; i++)
- if (vc->vc_ques) {
+ if (vc->vc_priv == EPdec) {
switch(vc->vc_par[i]) { /* DEC private modes set/reset */
case 1: /* Cursor keys send ^[Ox/^[[x */
if (on_off)
@@ -2030,7 +2032,7 @@ static void reset_terminal(struct vc_data *vc, int do_clear)
vc->vc_top = 0;
vc->vc_bottom = vc->vc_rows;
vc->vc_state = ESnormal;
- vc->vc_ques = 0;
+ vc->vc_priv = EPecma;
vc->vc_translate = set_translate(LAT1_MAP, vc);
vc->vc_G0_charset = LAT1_MAP;
vc->vc_G1_charset = GRAF_MAP;
@@ -2233,8 +2235,8 @@ static void do_con_trol(struct tty_struct *tty, struct vc_data *vc, int c)
vc->vc_state=ESfunckey;
return;
}
- vc->vc_ques = (c == '?');
- if (vc->vc_ques)
+ vc->vc_priv = (c == '?') ? EPdec : EPecma;
+ if (vc->vc_priv != EPecma)
return;
case ESgetpars:
if (c == ';' && vc->vc_npar < NPAR - 1) {
@@ -2254,7 +2256,7 @@ static void do_con_trol(struct tty_struct *tty, struct vc_data *vc, int c)
set_mode(vc, 0);
return;
case 'c':
- if (vc->vc_ques) {
+ if (vc->vc_priv == EPdec) {
if (vc->vc_par[0])
vc->vc_cursor_type = vc->vc_par[0] | (vc->vc_par[1] << 8) | (vc->vc_par[2] << 16);
else
@@ -2263,7 +2265,7 @@ static void do_con_trol(struct tty_struct *tty, struct vc_data *vc, int c)
}
break;
case 'm':
- if (vc->vc_ques) {
+ if (vc->vc_priv == EPdec) {
clear_selection();
if (vc->vc_par[0])
vc->vc_complement_mask = vc->vc_par[0] << 8 | vc->vc_par[1];
@@ -2273,7 +2275,7 @@ static void do_con_trol(struct tty_struct *tty, struct vc_data *vc, int c)
}
break;
case 'n':
- if (!vc->vc_ques) {
+ if (vc->vc_priv == EPecma) {
if (vc->vc_par[0] == 5)
status_report(tty);
else if (vc->vc_par[0] == 6)
@@ -2281,8 +2283,8 @@ static void do_con_trol(struct tty_struct *tty, struct vc_data *vc, int c)
}
return;
}
- if (vc->vc_ques) {
- vc->vc_ques = 0;
+ if (vc->vc_priv != EPecma) {
+ vc->vc_priv = EPecma;
return;
}
switch(c) {
diff --git a/include/linux/console_struct.h b/include/linux/console_struct.h
index ab137f97ecbd..ed798e114663 100644
--- a/include/linux/console_struct.h
+++ b/include/linux/console_struct.h
@@ -119,7 +119,7 @@ struct vc_data {
unsigned int vc_s_blink : 1;
unsigned int vc_s_reverse : 1;
/* misc */
- unsigned int vc_ques : 1;
+ unsigned int vc_priv : 3;
unsigned int vc_need_wrap : 1;
unsigned int vc_can_do_color : 1;
unsigned int vc_report_mouse : 2;
--
2.11.0
^ permalink raw reply related
* vt: Improve CSI parsing
From: Martin Hostettler @ 2018-12-15 14:34 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby
Cc: linux-kernel, linux-api, Nicolas Pitre, Adam Borowski,
Egmont Koblinger
This patch series improves parsing of csi sequences to be more compliant
with current practice.
ECMA-64 defines the format of CSI sequences which allow more characters
than what the vt parser currently accepts. More importantly many of
these characters are used in sequences that more capable terminal
terminal implementations use.
Adjust the parsing of CSI sequences to match xterm* by ignoring all
unknown sequences of the form
(ESC [)|CSI [\x20-\x3f]*[\x40-\x7e]
This avoids printing unwanted characters when application send valid
sequences not supported by linux either while querying the terminal for
it's identity or when applications print sequences without knowing what
terminal implementation they are connected to (e.g. when connected over
serial lines, android's adb, simple tcp connects, etc)
* and other common terminals
^ permalink raw reply
* Re: Can we drop upstream Linux x32 support?
From: Thomas Schoebel-Theuer @ 2018-12-15 7:41 UTC (permalink / raw)
To: Andy Lutomirski
Cc: X86 ML, LKML, Linux API, H. Peter Anvin, Peter Zijlstra,
Borislav Petkov, Florian Weimer, Mike Frysinger, H. J. Lu,
Rich Felker, x32, Arnd Bergmann, Will Deacon, Catalin Marinas,
Linus Torvalds
In-Reply-To: <35905587-2d7b-c0ab-e081-2b938d60e881@schoebel-theuer.de>
On 12/14/18 22:41, Thomas Schöbel-Theuer wrote:
> On 12/14/18 22:24, Andy Lutomirski wrote:
>>
>> I'm talking about x32, which is a different beast.
>>
>
> So from my viewpoint the mentioned roadmap / timing requirements will
> remain the same, whatever you are dropping.
>
> Enterprise-critical use cases will probably need to be migrated to
> KVM/qemu together with their old kernel versions, anyway (because the
> original hardware will be no longer available in a few decades).
>
Here is a systematic approach to the problem.
AFAICS legacy 32bit userspace code (which exists in some notable masses)
can be executed at least in the following ways:
1) natively on 32bit-capable hardware, under 32bit kernels. Besides
legacy hardware, this also encompasses most current Intel / AMD 64bit
hardware in 32bit compatibility mode.
2) under 64bit kernels, using the 32bit compat layer from practically
any kernel version.
3) under KVM/qemu.
When you just drop 1), users have a fair chance by migrating to any of
the other two possibilities.
As explained, a time frame of ~5 years should work for the vast majority.
If you clearly explain the migration paths to your users (and to the
press), I think it will be acceptable.
[side note: I know of a single legacy instance which is now ~20 years
old, but makes a revenue of several millions per month. These guys have
large quantities of legacy hardware in stock. And they have enough money
to hire a downstream maintainer in case of emergency.]
Fatal problems would only arise if you would drop all three
possibilities in the very long term.
In ~100 years, possibility 3) should be sufficient for handling use
cases like preservation of historic documents. The latter is roughly
equivalent to running binary-only MSDOS, Windows NT, and similar, even
in 100 years, and even non-natively under future hardware architectures.
^ permalink raw reply
* Re: Can we drop upstream Linux x32 support?
From: Thorsten Glaser @ 2018-12-15 4:53 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Linus Torvalds, X86 ML, LKML, Linux API, H. Peter Anvin,
Peter Zijlstra, Borislav Petkov, Florian Weimer, Mike Frysinger,
H. J. Lu, Rich Felker, x32, Arnd Bergmann, Will Deacon,
Catalin Marinas
In-Reply-To: <CALCETrUYn=S=hmJ0tKdm2LoSgkWchY2_65sH7hJZp7wfS30giw@mail.gmail.com>
Andy Lutomirski dixit:
>x32 is not this at all. The kernel ABI part of x32 isn't ILP32. It's
>IP32, 32-bit size_t, and *64-bit* long. The core kernel doesn't
Yeah, I was looking at this from userspace PoV, as I said I’m not
a Linux kernel programmer.
In BSD we have register_t which is probably the equivalent to your
__kernel_long_t? Maybe removing the “long” from the name helps.
But yes, x32 is just a (second to i386) ILP32 userspace API in an
amd64 kernel. This does imply mapping on the userspace (x32) to
kernel (amd64) boundary and back. I would have thought full struct
member mapping, as dalias described, to be the most robust.
>something similar to work using the normal x86_64 syscalls. And I'm
But those would require the longer structs etc. and therefore
lose all the benefits of x32…
bye,
//mirabilos
--
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)
^ permalink raw reply
* Re: Can we drop upstream Linux x32 support?
From: Thomas Schöbel-Theuer @ 2018-12-14 21:41 UTC (permalink / raw)
To: Andy Lutomirski
Cc: X86 ML, LKML, Linux API, H. Peter Anvin, Peter Zijlstra,
Borislav Petkov, Florian Weimer, Mike Frysinger, H. J. Lu,
Rich Felker, x32, Arnd Bergmann, Will Deacon, Catalin Marinas,
Linus Torvalds
In-Reply-To: <CALCETrV0fVLZKG6JrOvzvOzP06UxhZW=LbHpPXbonoeFdPJB1A@mail.gmail.com>
On 12/14/18 22:24, Andy Lutomirski wrote:
> I should clarify again: I am not suggesting that we drop 32-bit
> support in the forseeable future. (Well, I might eventually suggest
> that we drop support for 32-bit *hardware* at some point, but not for
> 32-bit compat software.) Linux's compat code is quite robust and is
> even fairly maintainable.
>
> I'm talking about x32, which is a different beast.
>
OK, this does not really make a big difference for large-scale
enterprise users. Some day in the very distant future any legacy system
will disappear, eventually.
So from my viewpoint the mentioned roadmap / timing requirements will
remain the same, whatever you are dropping.
Enterprise-critical use cases will probably need to be migrated to
KVM/qemu together with their old kernel versions, anyway (because the
original hardware will be no longer available in a few decades).
^ permalink raw reply
* Re: Can we drop upstream Linux x32 support?
From: Andy Lutomirski @ 2018-12-14 21:27 UTC (permalink / raw)
To: Linus Torvalds
Cc: Rich Felker, Florian Weimer, Bernd Petrovitsch,
John Paul Adrian Glaubitz, Andrew Lutomirski, X86 ML, LKML,
Linux API, H. Peter Anvin, Peter Zijlstra, Borislav Petkov,
Mike Frysinger, H. J. Lu, x32, Arnd Bergmann, Will Deacon,
Catalin Marinas
In-Reply-To: <CAHk-=wj0ejxYVV1xPfNX5YD6ZakRoSx+wQR==rFoj4J4SzLWhg@mail.gmail.com>
On Fri, Dec 14, 2018 at 12:13 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Fri, Dec 14, 2018 at 10:58 AM Andy Lutomirski <luto@amacapital.net> wrote:
> >
> > Does anyone know *why* Linux’s x32 has __kernel_long_t defined as long long?
>
> It *needs* to be long long, since the headers are used for builds in
> user mode using ILP32.
>
> Since __kernel_long_t is a 64-bit (the _kernel_ is not ILP32), you
> need to use "long long" when building in ILP32.
>
> Obviously, it could be something like
>
> #ifdef __KERNEL__
> typedef long __kernel_long_t;
> #else
> typedef long long __kernel_long_t;
> #endif
>
> or similar to make it more obvious what's going on.
>
> Or we could encourage all the uapi header files to always just use
> explicit sizing like __u64, but some of the structures really end up
> being "kernel long size" for sad historical reasons. Not lovely, but
> there we are..
>
This is probably water under the bridge, but I disagree with you here.
Or rather, I agree with you in principle but I really don't like the
way it turned out.
For legacy uapi structs (and probably some new ones too, sigh), as a
practical matter, user code is going to shove them at the C compiler,
and the C compiler is going to interpret them in the usual way, and
either we need a usermode translation layer or the kernel needs to
deal with the result.
It's a nice thought that, by convincing an x32 compiler that
__kernel_long_t is 64 bits, we end up with the x32 struct being
compatible with the native Linux struct, but it only works for structs
where the only ABI-dependent type is long. But the real structs in
uapi aren't all like this. We have struct iovec:
struct iovec
{
void __user *iov_base; /* BSD uses caddr_t (1003.1g requires void *) */
__kernel_size_t iov_len; /* Must be size_t (1003.1g) */
};
Whoops, this one looks the same on x32 and i386, but neither one of
them match x86_64, and, just randomly grepping around a bit, I see:
struct snd_hwdep_dsp_image {
unsigned int index; /* W: DSP index */
unsigned char name[64]; /* W: ID (e.g. file name) */
unsigned char __user *image; /* W: binary image */
size_t length; /* W: size of image in bytes */
unsigned long driver_data; /* W: driver-specific data */
};
struct __sysctl_args {
int __user *name;
int nlen;
void __user *oldval;
size_t __user *oldlenp;
void __user *newval;
size_t newlen;
unsigned long __unused[4];
};
If these had been switched from "unsigned long" to __kernel_ulong_t,
they would have had three different layouts on i386, x32, and x86_64.
So now we have a situation where, if we were to make x32 work 100%,
the whole kernel would need to recognize that there are three possible
ABIs, not two. And this sucks.
So I think it would have been a better choice to let long be 32-bit on
x32 and to therefore make x32 match the x86_32 "compat" layout as much
as possible. Sure, this would make x32 be more of a second-class
citizen, but I think it would have worked better, had fewer bugs, and
been more maintainable.
--Andy
^ permalink raw reply
* Re: Can we drop upstream Linux x32 support?
From: Andy Lutomirski @ 2018-12-14 21:24 UTC (permalink / raw)
To: thomas
Cc: Andrew Lutomirski, X86 ML, LKML, Linux API, H. Peter Anvin,
Peter Zijlstra, Borislav Petkov, Florian Weimer, Mike Frysinger,
H. J. Lu, Rich Felker, x32, Arnd Bergmann, Will Deacon,
Catalin Marinas, Linus Torvalds
In-Reply-To: <6577ac4f-524c-37f4-a4d0-6eb94ec7d9a5@schoebel-theuer.de>
On Fri, Dec 14, 2018 at 1:22 PM Thomas Schöbel-Theuer
<thomas@schoebel-theuer.de> wrote:
>
> On 12/11/18 02:23, Andy Lutomirski wrote:
> > I'm seriously considering sending a patch to remove x32 support from
> > upstream Linux.
>
> I am downstream maintainer of several self-patched kernels at 1&1 Ionos.
> The kernels are rolled out to several tenthousands of production servers
> running in several datacenters and in multiple continents.
>
> Currently, we have a few thousands of servers relying on 32bit ABIs in
> some thousands of VMs and/or containers of various types (LXC, OpenVZ, etc).
I should clarify again: I am not suggesting that we drop 32-bit
support in the forseeable future. (Well, I might eventually suggest
that we drop support for 32-bit *hardware* at some point, but not for
32-bit compat software.) Linux's compat code is quite robust and is
even fairly maintainable.
I'm talking about x32, which is a different beast.
^ permalink raw reply
* Re: Can we drop upstream Linux x32 support?
From: Thomas Schöbel-Theuer @ 2018-12-14 21:16 UTC (permalink / raw)
To: Andy Lutomirski, X86 ML, LKML, Linux API, H. Peter Anvin,
Peter Zijlstra, Borislav Petkov, Florian Weimer, Mike Frysinger,
H. J. Lu, Rich Felker, x32, Arnd Bergmann, Will Deacon,
Catalin Marinas, Linus Torvalds
In-Reply-To: <CALCETrXoRAibsbWa9nfbDrt0iEuebMnCMhSFg-d9W-J2g8mDjw@mail.gmail.com>
On 12/11/18 02:23, Andy Lutomirski wrote:
> I'm seriously considering sending a patch to remove x32 support from
> upstream Linux.
I am downstream maintainer of several self-patched kernels at 1&1 Ionos.
The kernels are rolled out to several tenthousands of production servers
running in several datacenters and in multiple continents.
Currently, we have a few thousands of servers relying on 32bit ABIs in
some thousands of VMs and/or containers of various types (LXC, OpenVZ, etc).
Here is my private opinion, not speaking for 1&1: at some point the
future, 32bit userspace support needs to be dropped anyway, somewhen in
future. This is inevitable in the very long term.
Thus the discussion should be about _timing_ / _roadmaps_, but not about
the fact as such.
My suggestion:
1) please release / declare a new LTS kernel, with upstream support for
at least 5 years (as usual). Currently, only 4.4 and 4.9 are marked as
LTS. Either mark another existing stable kernel as LTS, or a future one.
2) please _announce_ _now_ that after the _next_ LTS kernel (whichever
you want to declare as such), you will _afterwards_ drop the legacy
32bit support for 64 kernels (I am deliberately using "management speak"
here).
=> result: the industry should have to fair chance to deal with such a
roadmap. Yes, it will hurt some people, but they will have enough time
for their migration projects.
Example: I know that out of several millions of customers of webhosting,
a very low number of them have some very old legacy 32bit software
installed in their webspace. This cannot be supported forever. But the
number of such cases is very small, and there just needs to be enough
time for finding a solution for those few customers.
3) the next development kernel _after_ that LTS release can then
immediately drop the 32bit support. Enterprise users should have enough
time for planning, and for lots of internal projects modernizing their
infrastructure. Usually, they will need to do this anyway in the long term.
A roadmap should be _reliable_ for planning, and there should be no
"unexpected surprises". That's the most important requirements.
Notice: 5 years is what I know will very likely work for 1&1 Ionos. I
cannot speak for other large-scale enterprise users, but I think most of
them should be able to deal with suchalike intervals in a clear roadmap.
Addendum / side note: I know of cases where _critical_ / sometimes even
proprietary 32bit enterprise software needs to run for several
_decades_. Please don't drop KVM/qemu support for 32bit guests using
_old_ (unchanged) 32bit kernels, which are just happen to run on 64bit
hypervisors. But AFAICS that was not the intention of this initiative.
Just keep the latter in mind as another (independent) requirement.
Cheers,
Thomas
^ permalink raw reply
* Re: [PATCH v6 00/27] ptrace: add PTRACE_GET_SYSCALL_INFO request
From: Paul Moore @ 2018-12-14 20:15 UTC (permalink / raw)
To: ldv
Cc: linux-snps-arc, dalias, linux-ia64, linux-sh, benh,
alexey.brodkin, heiko.carstens, linux-api, jejb, jcmvbkbc, guoren,
ralf, linux-kselftest, hpa, leitao, linux, linux-riscv, deanbo422,
shuah, tglx, paulus, jonas, linux-s390, sparclinux, linux-arch,
linux-c6x-dev, ysato, linux-xtensa, mpe, deller, x86,
linux-kernel, esyr, linux-alpha, lineprinter, geert,
catalin.marinas
In-Reply-To: <20181213171833.GA5240@altlinux.org>
On Thu, Dec 13, 2018 at 12:18 PM Dmitry V. Levin <ldv@altlinux.org> wrote:
> PTRACE_GET_SYSCALL_INFO is a generic ptrace API that lets ptracer obtain
> details of the syscall the tracee is blocked in.
>
> There are two reasons for a special syscall-related ptrace request.
>
> Firstly, with the current ptrace API there are cases when ptracer cannot
> retrieve necessary information about syscalls. Some examples include:
> * The notorious int-0x80-from-64-bit-task issue. See [1] for details.
> In short, if a 64-bit task performs a syscall through int 0x80, its tracer
> has no reliable means to find out that the syscall was, in fact,
> a compat syscall, and misidentifies it.
> * Syscall-enter-stop and syscall-exit-stop look the same for the tracer.
> Common practice is to keep track of the sequence of ptrace-stops in order
> not to mix the two syscall-stops up. But it is not as simple as it looks;
> for example, strace had a (just recently fixed) long-standing bug where
> attaching strace to a tracee that is performing the execve system call
> led to the tracer identifying the following syscall-exit-stop as
> syscall-enter-stop, which messed up all the state tracking.
> * Since the introduction of commit 84d77d3f06e7e8dea057d10e8ec77ad71f721be3
> ("ptrace: Don't allow accessing an undumpable mm"), both PTRACE_PEEKDATA
> and process_vm_readv become unavailable when the process dumpable flag
> is cleared. On such architectures as ia64 this results in all syscall
> arguments being unavailable for the tracer.
>
> Secondly, ptracers also have to support a lot of arch-specific code for
> obtaining information about the tracee. For some architectures, this
> requires a ptrace(PTRACE_PEEKUSER, ...) invocation for every syscall
> argument and return value.
>
> PTRACE_GET_SYSCALL_INFO returns the following structure:
>
> struct ptrace_syscall_info {
> __u8 op; /* PTRACE_SYSCALL_INFO_* */
> __u32 arch __attribute__((__aligned__(sizeof(__u32))));
> __u64 instruction_pointer;
> __u64 stack_pointer;
> union {
> struct {
> __u64 nr;
> __u64 args[6];
> } entry;
> struct {
> __s64 rval;
> __u8 is_error;
> } exit;
> struct {
> __u64 nr;
> __u64 args[6];
> __u32 ret_data;
> } seccomp;
> };
> };
>
> The structure was chosen according to [2], except for the following
> changes:
> * seccomp substructure was added as a superset of entry substructure;
> * the type of nr field was changed from int to __u64 because syscall
> numbers are, as a practical matter, 64 bits;
> * stack_pointer field was added along with instruction_pointer field
> since it is readily available and can save the tracer from extra
> PTRACE_GETREGS/PTRACE_GETREGSET calls;
> * arch is always initialized to aid with tracing system calls
> * such as execve();
> * instruction_pointer and stack_pointer are always initialized
> so they could be easily obtained for non-syscall stops;
> * a boolean is_error field was added along with rval field, this way
> the tracer can more reliably distinguish a return value
> from an error value.
>
> strace has been ported to PTRACE_GET_SYSCALL_INFO, you can find it
> in [3] and [4].
>
> [1] https://lore.kernel.org/lkml/CA+55aFzcSVmdDj9Lh_gdbz1OzHyEm6ZrGPBDAJnywm2LF_eVyg@mail.gmail.com/
> [2] https://lore.kernel.org/lkml/CAObL_7GM0n80N7J_DFw_eQyfLyzq+sf4y2AvsCCV88Tb3AwEHA@mail.gmail.com/
> [3] https://github.com/strace/strace/commits/ldv/PTRACE_GET_SYSCALL_INFO
> [4] https://gitlab.com/strace/strace/commits/ldv/PTRACE_GET_SYSCALL_INFO
>
> ---
>
> Notes:
> v6:
> * Add syscall_get_arguments and syscall_set_arguments wrappers
> to asm-generic/syscall.h, requested by Geert.
> * Change PTRACE_GET_SYSCALL_INFO return code: do not take trailing paddings
> into account, use the end of the last field of the structure being written.
> * Change struct ptrace_syscall_info:
> * remove .frame_pointer field, is is not needed and not portable;
> * make .arch field explicitly aligned, remove no longer needed
> padding before .arch field;
> * remove trailing pads, they are no longer needed.
>
> v5:
> * Merge separate series and patches into the single series.
> * Change PTRACE_EVENTMSG_SYSCALL_{ENTRY,EXIT} values as requested by Oleg.
> * Change struct ptrace_syscall_info: generalize instruction_pointer,
> stack_pointer, and frame_pointer fields by moving them from
> ptrace_syscall_info.{entry,seccomp} substructures to ptrace_syscall_info
> and initializing them for all stops.
> * Add PTRACE_SYSCALL_INFO_NONE, set it when not in a syscall stop,
> so e.g. "strace -i" could use PTRACE_SYSCALL_INFO_SECCOMP to obtain
> instruction_pointer when the tracee is in a signal stop.
> * Patch all remaining architectures to provide all necessary
> syscall_get_* functions.
> * Make available for all architectures: do not conditionalize on
> CONFIG_HAVE_ARCH_TRACEHOOK since all syscall_get_* functions
> are implemented on all architectures.
> * Add a test for PTRACE_GET_SYSCALL_INFO to selftests/ptrace.
>
> v4:
> * Do not introduce task_struct.ptrace_event,
> use child->last_siginfo->si_code instead.
> * Implement PTRACE_SYSCALL_INFO_SECCOMP and ptrace_syscall_info.seccomp
> support along with PTRACE_SYSCALL_INFO_{ENTRY,EXIT} and
> ptrace_syscall_info.{entry,exit}.
>
> v3:
> * Change struct ptrace_syscall_info.
> * Support PTRACE_EVENT_SECCOMP by adding ptrace_event to task_struct.
> * Add proper defines for ptrace_syscall_info.op values.
> * Rename PT_SYSCALL_IS_ENTERING and PT_SYSCALL_IS_EXITING to
> PTRACE_EVENTMSG_SYSCALL_ENTRY and PTRACE_EVENTMSG_SYSCALL_EXIT
> * and move them to uapi.
>
> v2:
> * Do not use task->ptrace.
> * Replace entry_info.is_compat with entry_info.arch, use syscall_get_arch().
> * Use addr argument of sys_ptrace to get expected size of the struct;
> return full size of the struct.
>
> Dmitry V. Levin (25):
> asm-generic/syscall.h: prepare for inclusion by other files
> asm-generic/syscall.h: turn syscall_[gs]et_arguments into wrappers
> alpha: define remaining syscall_get_* functions
> Move EM_ARCOMPACT and EM_ARCV2 to uapi/linux/elf-em.h
> arc: define syscall_get_arch()
> c6x: define syscall_get_arch()
> elf-em.h: add EM_CSKY
> csky: define syscall_get_arch()
> h8300: define remaining syscall_get_* functions
> Move EM_HEXAGON to uapi/linux/elf-em.h
> hexagon: define remaining syscall_get_* functions
> Move EM_NDS32 to uapi/linux/elf-em.h
> nds32: define syscall_get_arch()
> nios2: define syscall_get_arch()
> m68k: add asm/syscall.h
> mips: define syscall_get_error()
> parisc: define syscall_get_error()
> powerpc: define syscall_get_error()
> riscv: define syscall_get_arch()
> Move EM_XTENSA to uapi/linux/elf-em.h
> xtensa: define syscall_get_* functions
> Move EM_UNICORE to uapi/linux/elf-em.h
> unicore32: add asm/syscall.h
> syscall_get_arch: add "struct task_struct *" argument
> selftests/ptrace: add a test case for PTRACE_GET_SYSCALL_INFO
>
> Elvira Khabirova (2):
> powerpc/ptrace: replace ptrace_report_syscall() with a tracehook call
> ptrace: add PTRACE_GET_SYSCALL_INFO request
As mentioned in the previous patchsets, this all looks fine to me from
an audit perspective (although there is not much audit code to really
comment on). Feel free to add my ACK to the audit related patches.
Acked-by: Paul Moore <paul@paul-moore.com>
> arch/alpha/include/asm/syscall.h | 31 +-
> arch/arc/include/asm/elf.h | 6 +-
> arch/arc/include/asm/syscall.h | 11 +
> arch/arm/include/asm/syscall.h | 2 +-
> arch/arm64/include/asm/syscall.h | 4 +-
> arch/c6x/include/asm/syscall.h | 7 +
> arch/csky/include/asm/syscall.h | 7 +
> arch/h8300/include/asm/syscall.h | 19 ++
> arch/hexagon/include/asm/elf.h | 6 +-
> arch/hexagon/include/asm/syscall.h | 22 ++
> arch/ia64/include/asm/syscall.h | 2 +-
> arch/m68k/include/asm/syscall.h | 42 +++
> arch/microblaze/include/asm/syscall.h | 2 +-
> arch/mips/include/asm/syscall.h | 12 +-
> arch/mips/kernel/ptrace.c | 2 +-
> arch/nds32/include/asm/elf.h | 3 +-
> arch/nds32/include/asm/syscall.h | 8 +
> arch/nios2/include/asm/syscall.h | 6 +
> arch/openrisc/include/asm/syscall.h | 2 +-
> arch/parisc/include/asm/syscall.h | 11 +-
> arch/powerpc/include/asm/syscall.h | 20 +-
> arch/powerpc/kernel/ptrace.c | 7 +-
> arch/riscv/include/asm/syscall.h | 10 +
> arch/s390/include/asm/syscall.h | 4 +-
> arch/sh/include/asm/syscall_32.h | 2 +-
> arch/sh/include/asm/syscall_64.h | 2 +-
> arch/sparc/include/asm/syscall.h | 5 +-
> arch/unicore32/include/asm/elf.h | 3 +-
> arch/unicore32/include/asm/syscall.h | 46 +++
> arch/x86/include/asm/syscall.h | 8 +-
> arch/x86/um/asm/syscall.h | 2 +-
> arch/xtensa/include/asm/elf.h | 2 +-
> arch/xtensa/include/asm/syscall.h | 65 +++++
> include/asm-generic/syscall.h | 85 ++++--
> include/linux/tracehook.h | 9 +-
> include/uapi/linux/audit.h | 16 ++
> include/uapi/linux/elf-em.h | 8 +
> include/uapi/linux/ptrace.h | 35 +++
> kernel/auditsc.c | 4 +-
> kernel/ptrace.c | 101 ++++++-
> kernel/seccomp.c | 4 +-
> tools/testing/selftests/ptrace/.gitignore | 1 +
> tools/testing/selftests/ptrace/Makefile | 2 +-
> .../selftests/ptrace/get_syscall_info.c | 271 ++++++++++++++++++
> 44 files changed, 851 insertions(+), 66 deletions(-)
> create mode 100644 arch/m68k/include/asm/syscall.h
> create mode 100644 arch/unicore32/include/asm/syscall.h
> create mode 100644 tools/testing/selftests/ptrace/get_syscall_info.c
>
> --
> ldv
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: Can we drop upstream Linux x32 support?
From: Linus Torvalds @ 2018-12-14 20:13 UTC (permalink / raw)
To: Andy Lutomirski
Cc: dalias, fweimer, bernd, glaubitz, Andrew Lutomirski,
the arch/x86 maintainers, Linux List Kernel Mailing, linux-api,
Peter Anvin, Peter Zijlstra, bp, vapier, hjl.tools, x32,
Arnd Bergmann, Will Deacon, Catalin Marinas
In-Reply-To: <EC1F028D-4382-41D6-B539-A9662FD53820@amacapital.net>
On Fri, Dec 14, 2018 at 10:58 AM Andy Lutomirski <luto@amacapital.net> wrote:
>
> Does anyone know *why* Linux’s x32 has __kernel_long_t defined as long long?
It *needs* to be long long, since the headers are used for builds in
user mode using ILP32.
Since __kernel_long_t is a 64-bit (the _kernel_ is not ILP32), you
need to use "long long" when building in ILP32.
Obviously, it could be something like
#ifdef __KERNEL__
typedef long __kernel_long_t;
#else
typedef long long __kernel_long_t;
#endif
or similar to make it more obvious what's going on.
Or we could encourage all the uapi header files to always just use
explicit sizing like __u64, but some of the structures really end up
being "kernel long size" for sad historical reasons. Not lovely, but
there we are..
Linus
^ permalink raw reply
* Re: Can we drop upstream Linux x32 support?
From: Lance Richardson @ 2018-12-14 19:59 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Rich Felker, Florian Weimer, Bernd Petrovitsch,
John Paul Adrian Glaubitz, Andy Lutomirski, X86 ML, LKML,
Linux API, H. Peter Anvin, Peter Zijlstra, Borislav Petkov,
Mike Frysinger, H. J. Lu, x32, Arnd Bergmann, Will Deacon,
Catalin Marinas, Linus Torvalds
In-Reply-To: <EC1F028D-4382-41D6-B539-A9662FD53820@amacapital.net>
My impression is it was mostly a desire to reuse existing x86_64 system calls
as much as possible without modification or additional compat layer work.
The 64-bit time requirement seems to have come from an lkml discussion, which
has quite a bit of interesting background about x32:
https://lkml.org/lkml/2011/8/26/415
https://lkml.org/lkml/2011/8/26/453
On Fri, Dec 14, 2018 at 2:05 PM Andy Lutomirski <luto@amacapital.net> wrote:
>
>
>
> > On Dec 14, 2018, at 8:55 AM, Rich Felker <dalias@libc.org> wrote:
> >
> >> On Fri, Dec 14, 2018 at 05:38:33PM +0100, Florian Weimer wrote:
> >> * Rich Felker:
> >>
> >>> This is all useless (and wrong since tv_nsec is required to have type
> >>> long as part of C and POSIX, regardless of ILP32-vs-LP64; that's a bug
> >>> in glibc's x32).
> >>
> >> We should be able to fix standards if they prove unworkable in practice.
> >> In my opinion, if standards require complex solutions where an obvious
> >> and simple solution exists, then standards are wrong.
> >
> > The requirement doesn't mandate complex solutions. There's nothing
> > complex about tv_nsec being long. long is the smallest type that C
> > guarantees to be large enough to store the range of values, which is
> > forever fixed and can't grow (because the definition of "nano" prefix
> > is fixed :). The type has been long ever since the structure was
> > introduced, and its being long means that there's lots of (correct!)
> > code using %ld (e.g. ".%.9ld" to format results as a decimal without
> > using floating point approximations) to print it. There might also be
> > code taking pointers to it to pass to functions, etc.
> >
> > The only reason a "complex" need arises is that Linux did something
> > horribly wrong here, ignoring the specified type, when introducing an
> > obscure subarch that almost nobody uses. This kind of mistake is
> > becoming a theme in Linux (see also: msghdr). Application authors
> > should not have to pay the price for fixing this by retrofitting yet
> > another silly type like "snseconds_t" or something into programs to
> > accommodate the mistakes of x32.
> >
> >
>
> Does anyone know *why* Linux’s x32 has __kernel_long_t defined as long long? I assume that this is where this bug, and most of the other bugs, came from.
>
> This may be silly, but the kernel could plausibly add a x32v2 where long is genuinely 32-bit, and then maybe we could drop the old x32 at some point. From all the discussion so far, it seems like there really is some demand for ILP32, but it’s still not really clear that preserving compatibility with existing x32 binaries in the long run is critical.
^ permalink raw reply
* Re: Can we drop upstream Linux x32 support?
From: Andy Lutomirski @ 2018-12-14 18:58 UTC (permalink / raw)
To: Rich Felker
Cc: Florian Weimer, Bernd Petrovitsch, John Paul Adrian Glaubitz,
Andy Lutomirski, X86 ML, LKML, Linux API, H. Peter Anvin,
Peter Zijlstra, Borislav Petkov, Mike Frysinger, H. J. Lu, x32,
Arnd Bergmann, Will Deacon, Catalin Marinas, Linus Torvalds
In-Reply-To: <20181214165535.GZ23599@brightrain.aerifal.cx>
> On Dec 14, 2018, at 8:55 AM, Rich Felker <dalias@libc.org> wrote:
>
>> On Fri, Dec 14, 2018 at 05:38:33PM +0100, Florian Weimer wrote:
>> * Rich Felker:
>>
>>> This is all useless (and wrong since tv_nsec is required to have type
>>> long as part of C and POSIX, regardless of ILP32-vs-LP64; that's a bug
>>> in glibc's x32).
>>
>> We should be able to fix standards if they prove unworkable in practice.
>> In my opinion, if standards require complex solutions where an obvious
>> and simple solution exists, then standards are wrong.
>
> The requirement doesn't mandate complex solutions. There's nothing
> complex about tv_nsec being long. long is the smallest type that C
> guarantees to be large enough to store the range of values, which is
> forever fixed and can't grow (because the definition of "nano" prefix
> is fixed :). The type has been long ever since the structure was
> introduced, and its being long means that there's lots of (correct!)
> code using %ld (e.g. ".%.9ld" to format results as a decimal without
> using floating point approximations) to print it. There might also be
> code taking pointers to it to pass to functions, etc.
>
> The only reason a "complex" need arises is that Linux did something
> horribly wrong here, ignoring the specified type, when introducing an
> obscure subarch that almost nobody uses. This kind of mistake is
> becoming a theme in Linux (see also: msghdr). Application authors
> should not have to pay the price for fixing this by retrofitting yet
> another silly type like "snseconds_t" or something into programs to
> accommodate the mistakes of x32.
>
>
Does anyone know *why* Linux’s x32 has __kernel_long_t defined as long long? I assume that this is where this bug, and most of the other bugs, came from.
This may be silly, but the kernel could plausibly add a x32v2 where long is genuinely 32-bit, and then maybe we could drop the old x32 at some point. From all the discussion so far, it seems like there really is some demand for ILP32, but it’s still not really clear that preserving compatibility with existing x32 binaries in the long run is critical.
^ permalink raw reply
* Re: Can we drop upstream Linux x32 support?
From: Rich Felker @ 2018-12-14 16:55 UTC (permalink / raw)
To: Florian Weimer
Cc: Bernd Petrovitsch, John Paul Adrian Glaubitz, Andy Lutomirski,
X86 ML, LKML, Linux API, H. Peter Anvin, Peter Zijlstra,
Borislav Petkov, Mike Frysinger, H. J. Lu, x32, Arnd Bergmann,
Will Deacon, Catalin Marinas, Linus Torvalds
In-Reply-To: <87mup8gj1y.fsf@oldenburg2.str.redhat.com>
On Fri, Dec 14, 2018 at 05:38:33PM +0100, Florian Weimer wrote:
> * Rich Felker:
>
> > This is all useless (and wrong since tv_nsec is required to have type
> > long as part of C and POSIX, regardless of ILP32-vs-LP64; that's a bug
> > in glibc's x32).
>
> We should be able to fix standards if they prove unworkable in practice.
> In my opinion, if standards require complex solutions where an obvious
> and simple solution exists, then standards are wrong.
The requirement doesn't mandate complex solutions. There's nothing
complex about tv_nsec being long. long is the smallest type that C
guarantees to be large enough to store the range of values, which is
forever fixed and can't grow (because the definition of "nano" prefix
is fixed :). The type has been long ever since the structure was
introduced, and its being long means that there's lots of (correct!)
code using %ld (e.g. ".%.9ld" to format results as a decimal without
using floating point approximations) to print it. There might also be
code taking pointers to it to pass to functions, etc.
The only reason a "complex" need arises is that Linux did something
horribly wrong here, ignoring the specified type, when introducing an
obscure subarch that almost nobody uses. This kind of mistake is
becoming a theme in Linux (see also: msghdr). Application authors
should not have to pay the price for fixing this by retrofitting yet
another silly type like "snseconds_t" or something into programs to
accommodate the mistakes of x32.
Rich
^ permalink raw reply
* Re: Can we drop upstream Linux x32 support?
From: Florian Weimer @ 2018-12-14 16:38 UTC (permalink / raw)
To: Rich Felker
Cc: Bernd Petrovitsch, John Paul Adrian Glaubitz, Andy Lutomirski,
X86 ML, LKML, Linux API, H. Peter Anvin, Peter Zijlstra,
Borislav Petkov, Mike Frysinger, H. J. Lu, x32, Arnd Bergmann,
Will Deacon, Catalin Marinas, Linus Torvalds
In-Reply-To: <20181214161732.GY23599@brightrain.aerifal.cx>
* Rich Felker:
> This is all useless (and wrong since tv_nsec is required to have type
> long as part of C and POSIX, regardless of ILP32-vs-LP64; that's a bug
> in glibc's x32).
We should be able to fix standards if they prove unworkable in practice.
In my opinion, if standards require complex solutions where an obvious
and simple solution exists, then standards are wrong.
Thanks,
Florian
^ permalink raw reply
* Re: Can we drop upstream Linux x32 support?
From: Bernd Petrovitsch @ 2018-12-14 16:29 UTC (permalink / raw)
To: Rich Felker
Cc: John Paul Adrian Glaubitz, Andy Lutomirski, X86 ML, LKML,
Linux API, H. Peter Anvin, Peter Zijlstra, Borislav Petkov,
Florian Weimer, Mike Frysinger, H. J. Lu, x32, Arnd Bergmann,
Will Deacon, Catalin Marinas, Linus Torvalds
In-Reply-To: <20181214161732.GY23599@brightrain.aerifal.cx>
[-- Attachment #1: Type: text/plain, Size: 2391 bytes --]
On 14/12/2018 17:17, Rich Felker wrote:
> On Fri, Dec 14, 2018 at 03:13:10PM +0100, Bernd Petrovitsch wrote:
[..]
>> FWIW I have
>> ---- snip ----
>> #if defined __x86_64__
>> # if defined __ILP32__ // x32
>> # define PRI_time_t "lld" // for time_t
>> # define PRI_nsec_t "lld" // for tv_nsec in struct timespec
>> # else // x86_64
>> # define PRI_time_t "ld" // for time_t
>> # define PRI_nsec_t "ld" // for tv_nsec in struct timespec
>> # endif
>> #else // i[3-6]68
>> # define PRI_time_t "ld" // for time_t
>> # define PRI_nsec_t "ld" // for tv_nsec in struct timespec
>> #endif
>> ---- snip ----
>> in my userspace code for printf() and friends - I don't know how libc's
>> react to such a patch (and I don't care for the name of the macros as
>> long it's obviously clear for which type they are).
>> I assume/fear we won't get additional modifiers into the relevant
>> standards for libc types (as they are far more like pid_t, uid_t etc.).
>> And casting to u/intmaxptr_t to get a defined printf()-modifier doesn't
>> look appealing to me to "solve" such issues.
>
> This is all useless (and wrong since tv_nsec is required to have type
> long as part of C and POSIX, regardless of ILP32-vs-LP64; that's a bug
Thanks. OK, I didn't know that - and 32bit is enough to represent 1E9
(as a second won't have more nanosecs).
Hmm, can we fix that in the x32 world?
Sry, I'm not the expert on glibc vs ABI va syscall interface vs breakage
there though.
> in glibc's x32). Just do:
>
> printf("%jd", (intmax_t)t);
>
> Saving 2 or 3 insns (for sign or zero extension) around a call to
> printf is not going to make any measurable difference to performance
Until someone comes up with hardware with ASIC support for 1k bit int's
and (ab)uses intmax_t for that. SCNR ....
> or any significant difference to size, and it's immeasurably more
> readable than the awful PRI* macros and the
> adjacent-string-concatenation they rely on.
One gets used to the PRI_* macros over time (and there no calculated
format strings in my world) - and type casts are not better in my eyes ...
MfG,
Bernd
--
"I dislike type abstraction if it has no real reason. And saving
on typing is not a good reason - if your typing speed is the main
issue when you're coding, you're doing something seriously wrong."
- Linus Torvalds
[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 2513 bytes --]
^ permalink raw reply
* Re: Can we drop upstream Linux x32 support?
From: Rich Felker @ 2018-12-14 16:17 UTC (permalink / raw)
To: Bernd Petrovitsch
Cc: John Paul Adrian Glaubitz, Andy Lutomirski, X86 ML, LKML,
Linux API, H. Peter Anvin, Peter Zijlstra, Borislav Petkov,
Florian Weimer, Mike Frysinger, H. J. Lu, x32, Arnd Bergmann,
Will Deacon, Catalin Marinas, Linus Torvalds
In-Reply-To: <c8987b31-ed79-acef-a300-31ebf2c29d2e@petrovitsch.priv.at>
On Fri, Dec 14, 2018 at 03:13:10PM +0100, Bernd Petrovitsch wrote:
> On 13/12/2018 17:02, Rich Felker wrote:
> > On Tue, Dec 11, 2018 at 11:29:14AM +0100, John Paul Adrian Glaubitz wrote:
> >> I can't say anything about the syscall interface. However, what I do know
> >> is that the weird combination of a 32-bit userland with a 64-bit kernel
> >> interface is sometimes causing issues. For example, application code usually
> >> expects things like time_t to be 32-bit on a 32-bit system. However, this
>
> IMHO this just historically grown (as in "it has been forever that way"
> - it sounds way better in Viennese dialect though;-).
>
> >> isn't the case for x32 which is why code fails to build.
> >
> > I don't see any basis for this claim about expecting time_t to be
> > 32-bit. I've encountered some programs that "implicitly assume" this
> > by virtue of assuming they can cast time_t to long to print it, or
> > similar. IIRC this was an issue in busybox at one point; I'm not sure
> > if it's been fixed. But any software that runs on non-Linux unices has
> > long been corrected. If not, 2038 is sufficiently close that catching
> > and correcting any such remaining bugs is more useful than covering
> > them up and making the broken code work as expected.
>
> Yup, unconditionally providing 64bit
> time_t/timespec/timeval/...-equivalents with libc and syscall support
> also for 32bit architectures (and deprecating all 32bit versions) should
> be the way to go.
>
> FWIW I have
> ---- snip ----
> #if defined __x86_64__
> # if defined __ILP32__ // x32
> # define PRI_time_t "lld" // for time_t
> # define PRI_nsec_t "lld" // for tv_nsec in struct timespec
> # else // x86_64
> # define PRI_time_t "ld" // for time_t
> # define PRI_nsec_t "ld" // for tv_nsec in struct timespec
> # endif
> #else // i[3-6]68
> # define PRI_time_t "ld" // for time_t
> # define PRI_nsec_t "ld" // for tv_nsec in struct timespec
> #endif
> ---- snip ----
> in my userspace code for printf() and friends - I don't know how libc's
> react to such a patch (and I don't care for the name of the macros as
> long it's obviously clear for which type they are).
> I assume/fear we won't get additional modifiers into the relevant
> standards for libc types (as they are far more like pid_t, uid_t etc.).
> And casting to u/intmaxptr_t to get a defined printf()-modifier doesn't
> look appealing to me to "solve" such issues.
This is all useless (and wrong since tv_nsec is required to have type
long as part of C and POSIX, regardless of ILP32-vs-LP64; that's a bug
in glibc's x32). Just do:
printf("%jd", (intmax_t)t);
Saving 2 or 3 insns (for sign or zero extension) around a call to
printf is not going to make any measurable difference to performance
or any significant difference to size, and it's immeasurably more
readable than the awful PRI* macros and the
adjacent-string-concatenation they rely on.
Rich
^ permalink raw reply
* Re: Can we drop upstream Linux x32 support?
From: Rich Felker @ 2018-12-14 16:13 UTC (permalink / raw)
To: Florian Weimer
Cc: Catalin Marinas, Andy Lutomirski, tg, Linus Torvalds, X86 ML,
LKML, Linux API, H. Peter Anvin, Peter Zijlstra, Borislav Petkov,
Mike Frysinger, H. J. Lu, x32, Arnd Bergmann, Will Deacon
In-Reply-To: <875zvwibbp.fsf@oldenburg2.str.redhat.com>
On Fri, Dec 14, 2018 at 12:42:34PM +0100, Florian Weimer wrote:
> * Rich Felker:
>
> > On Thu, Dec 13, 2018 at 05:04:59PM +0100, Florian Weimer wrote:
> >> * Rich Felker:
> >>
> >> >> If the compiler can handle the zeroing, that would be great, though not
> >> >> sure how (some __attribute__((zero)) which generates a type constructor
> >> >> for such structure; it kind of departs from what the C language offers).
> >> >
> >> > The compiler fundamentally can't. At the very least it would require
> >> > effective type tracking, which requires shadow memory and is even more
> >> > controversial than -fstrict-aliasing (because in a sense it's a
> >> > stronger version thereof).
> >>
> >> It's possible to do it with the right types. See _Bool on 32-bit Darwin
> >> PowerPC for an example, which is four bytes instead of the usual one.
> >>
> >> Similarly, we could have integer types with trap representations.
> >> Whether it is a good idea is a different matter, but the amount of
> >> compiler magic required is actually limited.
> >
> > If you do this you just have LP64 with value range restricted to
> > 32-bit.
>
> You have to a type different from long int for the relevant struct
> fields. This type would have zero padding.
Just upthread (Message-ID: <20181212165237.GT23599@brightrain.aerifal.cx>)
I explained why this does not work:
>>> If on the other hand you tried to make just some pointers "wide
>>> pointers", you'd also be completely breaking the specified API
>>> contracts of standard interfaces. For example in struct iovec's
>>> iov_base, &foo->iov_base is no longer a valid pointer to an object of
>>> type void* that you can pass to interfaces expecting void**. Sloppy
>>> misunderstandings like what you're making now are exactly why x32 is
>>> already broken and buggy (&foo->tv_nsec already has wrong type for
>>> struct timespec foo).
Rich
^ permalink raw reply
* Re: Can we drop upstream Linux x32 support?
From: Richard Weinberger @ 2018-12-14 15:17 UTC (permalink / raw)
To: David Laight
Cc: 'Richard Weinberger', kevin@guarana.org,
glaubitz@physik.fu-berlin.de, Andy Lutomirski, x86@kernel.org,
LKML, open list:ABI/API, H. Peter Anvin, Peter Zijlstra,
Borislav Petkov, fweimer@redhat.com, Mike Frysinger, H.J. Lu,
dalias@libc.org, x32@buildd.debian.org, Arnd Bergmann,
Will Deacon, Catalin Marinas, Linus Torvalds
In-Reply-To: <d54d7ea7c558474583dfed0d26f05ccd@AcuMS.aculab.com>
Am Freitag, 14. Dezember 2018, 15:38:53 CET schrieb David Laight:
> From: Richard Weinberger
> > Sent: 13 December 2018 09:05
> > On Thu, Dec 13, 2018 at 6:03 AM Kevin Easton <kevin@guarana.org> wrote:
> > >
> > > On Tue, Dec 11, 2018 at 11:29:14AM +0100, John Paul Adrian Glaubitz wrote:
> > > ...
> > > > I can't say anything about the syscall interface. However, what I do know
> > > > is that the weird combination of a 32-bit userland with a 64-bit kernel
> > > > interface is sometimes causing issues. For example, application code usually
> > > > expects things like time_t to be 32-bit on a 32-bit system. However, this
> > > > isn't the case for x32 which is why code fails to build.
> > >
> > > OpenBSD and NetBSD both have 64-bit time_t on 32-bit systems and have
> > > had for four or five years at this point.
> >
> > They can also do flag-day changes and break existing applications, Linux not.
>
> Not true at all.
> The binary compatibility in NetBSD is probably better than that in Linux
> and goes back a long way.
>
> For the time_t changes new system calls numbers were assigned where needed.
> The system headers and libc were updated so that recompiled code would
> use the new system calls.
>
> The only real advantage that NetBSD has is that its libc (and standard
> utilities) are released with the kernel making it much easier to get
> applications to use the new features.
>
> This was also done a very long time ago when file offsets were extended
> to 64 bits.
>
> Some of the system calls have quite a few 'compatibility' versions.
> As well as the ones for emulations of other operating systems.
> It has been possible to run copies of firefox compiled for Linux
> under NetBSD.
I stand corrected, I was under the impression that NetBSD went the same
path as OpenBSD did. Thanks for pointing this out.
Thanks,
//richard
^ 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