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.
[
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. :)
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
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
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?
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
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
> you shouldn't ge
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
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 still
wonder
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?
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 executable sta
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
> abandon
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
> abandon
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:
> What are poor us
21 matches
Mail list logo
