On Sat, Jul 25, 2020 at 10:27:56PM +0100, Ben Hutchings wrote:
> 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,
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
Le 25/06/2020 à 22:20, Kees Cook a écrit :
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.5298
On Thu, Jun 25, 2020 at 09:16:10PM +, Thorsten Glaser wrote:
> Kees Cook dixit:
>
> >3) fix the use of trampolines in klibc
>
> AIUI done in klibc, but post-2.0.7
Ah-ha, I see it. Ben got it fixed in Feb. :)
https://git.kernel.org/pub/scm/libs/klibc/klibc.git/commit/?id=9d8d648e604026b32cad
Kees Cook dixit:
>3) fix the use of trampolines in klibc
AIUI done in klibc, but post-2.0.7
bye,
//mirabilos
--
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consi
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] process '/usr/bin/fstyp
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] process '/usr/bin/fstype' started with executable stack
>
> Where does fstype come from there?
On Wed, Jun 24, 2020 at 07:51:48PM +0300, Dan Carpenter wrote:
> In Debian testing the initrd triggers the warning.
>
> [ 34.529809] process '/usr/bin/fstype' started with executable stack
Where does fstype come from there? I am going to guess it is either
busybox or linked against klibc?
klib
In Debian testing the initrd triggers the warning.
[ 34.529809] process '/usr/bin/fstype' started with executable stack
$ checksec --format=json --extended
--file=/var/tmp/mkinitramfs_eTyMPQ/bin/fstype | jq
{
"file": {
"relro": "no",
"canary": "no",
"nx": "no",
"pie": "no",
On Tue, 23 Jun 2020, Kees Cook wrote:
> > If you run something with exec stack after the message
> > you shouldn't get it second time.
>
> If you want to reset this flag, you can do:
> # echo 1 > /sys/kernel/debug/clear_warn_once
Thanks. Although, I tend to not mount /sys/kernel/{config,debug,tr
5.6.5 kernel:
> > >
> > > process '/usr/bin/rsync' started with executable stack
> > >
> > > But I can't reproduce this message,
>
> This message is once-per-reboot.
>
> If you run something with exec stack after the message
> y
On Wed, 24 Jun 2020, Alexey Dobriyan wrote:
> BTW this bug was exactly the one described in the changelog:
> compiling assembly brings executable stack by default:
Great, thanks for the pointer, will wait until this lands in Arch. My
search engine brought up the lkml discussion though, no the thr
On Wed, 24 Jun 2020, Alexey Dobriyan wrote:
> > > process '/usr/bin/rsync' started with executable stack
> > > But I can't reproduce this message,
>
> This message is once-per-reboot.
Interesting, thanks. Now I know why I cannot reproduce this. I sti
On Tue, Jun 23, 2020 at 02:33:50PM -0700, Christian Kujau wrote:
> On Tue, 23 Jun 2020, Kees Cook wrote:
> > > $ checksec --format=json --extended --file=`which rsync` | jq
> > > {
> > > "/usr/bin/rsync": {
> > > "relro": "full",
> > > "canary": "yes",
> > > "nx": "no",
> > ^^
On Tue, Jun 23, 2020 at 02:33:50PM -0700, Christian Kujau wrote:
> On Tue, 23 Jun 2020, Kees Cook wrote:
> > > $ checksec --format=json --extended --file=`which rsync` | jq
> > > {
> > > "/usr/bin/rsync": {
> > > "relro": "full",
> > > "canary": "yes",
> > > "nx": "no",
> > ^^
On Tue, Jun 23, 2020 at 02:33:50PM -0700, Christian Kujau wrote:
> On Tue, 23 Jun 2020, Kees Cook wrote:
> > > $ checksec --format=json --extended --file=`which rsync` | jq
> > > {
> > > "/usr/bin/rsync": {
> > > "relro": "full",
> > > "canary": "yes",
> > > "nx": "no",
> > ^^
On Tue, 23 Jun 2020, Kees Cook wrote:
> > $ checksec --format=json --extended --file=`which rsync` | jq
> > {
> > "/usr/bin/rsync": {
> > "relro": "full",
> > "canary": "yes",
> > "nx": "no",
> ^^
>
> It is, indeed, marked executable, it seems. What distro is this?
A
On Wed, Jun 24, 2020 at 12:12:18AM +0300, Alexey Dobriyan wrote:
> On Tue, Jun 23, 2020 at 10:39:26AM -0700, Christian Kujau wrote:
> > Hi,
> >
> > exactly this[0] happened today, on a 5.6.5 kernel:
> >
> > process '/usr/bin/rsync' started with exec
On Tue, Jun 23, 2020 at 10:39:26AM -0700, Christian Kujau wrote:
> Hi,
>
> exactly this[0] happened today, on a 5.6.5 kernel:
>
> process '/usr/bin/rsync' started with executable stack
>
> But I can't reproduce this message, and rsync (v3.2.0, not exactly
On Tue, Jun 23, 2020 at 10:39:26AM -0700, Christian Kujau wrote:
> Hi,
>
> exactly this[0] happened today, on a 5.6.5 kernel:
>
> process '/usr/bin/rsync' started with executable stack
>
> But I can't reproduce this message, and rsync (v3.2.0, not exactly
Hi,
exactly this[0] happened today, on a 5.6.5 kernel:
process '/usr/bin/rsync' started with executable stack
But I can't reproduce this message, and rsync (v3.2.0, not exactly
abandonware) runs several times a day, so to repeat Andrew's questions[0]
from last year:
&
21 matches
Mail list logo
