similar to: process '/usr/bin/rsync' started with executable stack

With latest kernel (Linus tree as of 5.6 merge window), I get the following warning in the kernel 'dmesg': [ 5.746588] process '/bin/sh' started with executable stack This comes from commit https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/exec.c?id=47a2ebb7f5053387f5753b524f4920b9b829f922 "execve: warn if process starts with executable

On Tue, 2020-02-25 at 13:36 -0800, Kees Cook wrote: > On Thu, Feb 06, 2020 at 04:38:34PM +0100, Christophe Leroy wrote: [...] > > Indeed, the stack is rwx, which is unexpected. And it is the case for all > > klibc tools. > > > > How can we fix that ? > > klibc uses trampolines for its setjmp implementation. I ran into this > years ago when eradicating

On Thu, 2020-06-25 at 13:20 -0700, Kees Cook wrote: > On Thu, Jun 25, 2020 at 01:04:29PM +0300, Dan Carpenter wrote: > > On Wed, Jun 24, 2020 at 12:39:24PM -0700, Kees Cook wrote: > > > On Wed, Jun 24, 2020 at 07:51:48PM +0300, Dan Carpenter wrote: > > > > In Debian testing the initrd triggers the warning. > > > > > > > > [ 34.529809]

This reverts commit 9d8d648e604026b32cad00a84ed6c29cbd157641, which broke signal handing on some architectures. On m68k and parisc, signal return depends on a trampoline that the kernel writes on the stack. On alpha, s390, and sparc (32-bit), we can avoid this by providing our own function as sa_restorer, but we currently don't. Signed-off-by: Ben Hutchings <ben at decadent.org.uk>

On Thu, Feb 06, 2020 at 04:38:34PM +0100, Christophe Leroy wrote: > With latest kernel (Linus tree as of 5.6 merge window), I get the following > warning in the kernel 'dmesg': > > [ 5.746588] process '/bin/sh' started with executable stack > > This comes from commit

Hello what is the difference between busybox and klibc? Say, I want to use an initramfs in order to mount root over nfs, I can choose to use klibc with ipconfig and nfsmount? But I can also choose to use busybox with ifconfig and mount. So what's the difference, and why and in which case one is preferable to the other? If it's a FAQ, I'm sorry, just give me the link Thanks

On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook at chromium.org> wrote: > > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote: > > If none of the 140 patches here fix a real bug, and there is no change > > to machine code then it sounds to me like a W=2 kind of a warning. > > FWIW, this series has found at least one bug so far: >

On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook at chromium.org> wrote: > > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote: > > If none of the 140 patches here fix a real bug, and there is no change > > to machine code then it sounds to me like a W=2 kind of a warning. > > FWIW, this series has found at least one bug so far: >

On Sun, Nov 22, 2020 at 8:17 AM Kees Cook <keescook at chromium.org> wrote: > > On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote: > > If none of the 140 patches here fix a real bug, and there is no change > > to machine code then it sounds to me like a W=2 kind of a warning. > > FWIW, this series has found at least one bug so far: >

On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote: > On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote: > > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote: > > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote: > > > > This series aims to fix almost all remaining fall-through warnings in > > > > order to enable

On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote: > On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote: > > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote: > > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote: > > > > This series aims to fix almost all remaining fall-through warnings in > > > > order to enable

On Fri, Nov 20, 2020 at 11:51:42AM -0800, Jakub Kicinski wrote: > On Fri, 20 Nov 2020 11:30:40 -0800 Kees Cook wrote: > > On Fri, Nov 20, 2020 at 10:53:44AM -0800, Jakub Kicinski wrote: > > > On Fri, 20 Nov 2020 12:21:39 -0600 Gustavo A. R. Silva wrote: > > > > This series aims to fix almost all remaining fall-through warnings in > > > > order to enable

Well, as of right now, both Linus and Andrew have rejected klibc in the kernel based on "it doesn't add anything new" (Linus) and "lack of interest" (Andrew). It seems that there is little hope of getting it into the kernel any time soon, unless there is additional features, and/or people start actively asking for it. I would appreciate hearing suggestions. The

new klibc sparc build failure against gcc 4.2 ----- Forwarded message from Kilian Krause <kilian at debian.org> ----- Subject: Bug#440721: FTBFS on sparc while linking usr/klibc/libc.so From: Kilian Krause <kilian at debian.org> To: Debian Bug Tracking System <submit at bugs.debian.org> Date: Mon, 03 Sep 2007 23:35:23 +0200 Package: klibc Version: 1.5.6-2 Severity: serious

On Wed, Jul 23, 2008 at 11:24:49AM +0200, Karel Zak wrote: > On Wed, Jul 23, 2008 at 04:43:30AM -0400, Christoph Hellwig wrote: > > On Wed, Jul 23, 2008 at 10:39:38AM +0200, maximilian attems wrote: > > > klibc mount has only short options thus uses the following syntax > > Frankly, it seems like a klibc problem... well not directly, but right klibc-utils should have

I've looked through the code for sys_mmap2 on several architectures, and it looks like some architectures plays by the "shift is always 12" rule, e.g. SPARC, and some expect userspace to actually obtain the page size, e.g. PowerPC and MIPS. On some architectures, e.g. x86 and ARM, the point is moot since PAGE_SIZE is always 2^12. a. Is this correct, or have I misunderstood

I have the following toolchain: $ ld --version GNU ld version 2.15.90.0.3 20040415 $ gcc --version gcc (GCC) 3.3.2 I attempted to build klibc with this toolchain. It builds without errors, but the included "ash" shell does not function properly. Testcase: read cmdline </proc/cmdline echo $cmdline The first command prints a message: cannot open /proc/cmdline: error 14 Other

I guess what I wanted to say is that it might be desirable to have the klibc shell do some dancing (perhaps controlled by some flags, but on by default?) If getpid() == 1 then fork a child, continue in the child, have the parent wait for the child to terminate, then exit child should setsid() close(2) close(1) close(0) open("/dev/ttyS0", O_RDONLY) open("/dev/ttyS0",

hello hpa, pushed out new patch queue :) It contains the sync with latest dash git, renaming of some README's to ease their packaging, sparc32 socket test and a sh4 fix by Debian porters (numbers of changes is huge, but mostly contained in dash). git pull git://git.debian.org/users/maks/klibc.git maks initramfs-tools seems happy with that version of dash, saw no regression on boot test with

Hello! Okay i tried again with only staticly linked busybox: offlinehacker:~/ $ /home/offlinehacker/busybox/busybox BusyBox v1.17.1 (Debian 1:1.17.1-8) multi-call binary. Copyright (C) 1998-2009 Erik Andersen, Rob Landley, Denys Vlasenko and others. Licensed under GPLv2. See source distribution for full notice. .... Again my id: uid=499(offlinehacker) gid=100(users)