On Sun, Apr 11, 2021 at 9:53 PM Guillermo wrote:
>
> Ah, I see. There has to be a static library involved.
Yes, but to be extra clear and to avoid any confusion: your statement
is accurate only as far as it pertains specifically to skarnet
packages, libraries and build scripts. And this point is
El dom, 11 abr 2021 a las 15:03, Xavier Stonestreet escribió:
>
> [...] the breaking point
> is making strip and static linking with packages that are build-time
> dependencies. So for example, make strip skalibs and then statically
> link all other skarnet packages with it. Or make strip execline
On Sun, Apr 11, 2021 at 6:01 PM Guillermo wrote:
>
> I guess this executable stack thing is toolchain- / libc-specific?
It's dependent on the build procedure and/or the toolchain.
> The
> relevant test is using 'readelf -l' to check if there is a GNU_STACK
> program header, and that its flags ar
All my packages, in their git head, now have their Makefile fixed (by
not stripping .note.GNU-stack) and configure changed to not force
noexecstack, so it all defaults to what the toolchain does.
(And indeed the toolchains I was using were bad, because I stripped
.note.GNU-stack from the libc
Hello,
El vie, 9 abr 2021 a las 11:02, Xavier Stonestreet escribió:
>
> I did some more investigation and the problem lies
> in the Makefile's strip instructions which remove the GNU-stack
> section from the object files. Without the GNU-stack section the
> linker reverts to its backwards-compatib
On Fri, Apr 9, 2021 at 3:46 PM Laurent Bercot wrote:
>
> Oh! That's interesting
Interesting, and very nasty:
"Fail open design
Since this is the default, the only way to get a non-executable stack
is if every object file input to the linker explicitly declares that
it does not need an executa
Without the GNU-stack section the
linker reverts to its backwards-compatible default which is to make
the stack executable.
Oh! That's interesting, and actually makes sense. Well, I guess
we've found a reason for the existence of the .note.GNU-stack section,
and stripping it is not as free a wi
On Fri, Apr 9, 2021 at 5:06 AM Laurent Bercot wrote:
>
> To make things perfectly clear: the modification I pushed to git also
> applies to the ld invocations creating shared libraries, including
> libskarnet.so. So with that change, skalibs or libutmps will not
> pollute anything else. ;)
Soun
Fair enough. That's totally fine for self-contained packages in which
you control the build parameters from end-to-end. This may become an
issue with skarnet libraries, such as utmps, that are used with other,
non-skarnet packages. Libutmps pulls in libskarnet and libskarnet
'pollutes' the other p
On Thu, Apr 8, 2021 at 9:57 PM Laurent Bercot wrote:
>
> My toolchain also creates E stack binaries by default, no matter
> whether they're static or dynamic. It may be that my build of musl is
> bad.
That's unexpected.
> I am not interested enough in the details of what happens at the ld
>
On 08/04/2021 21.57, Laurent Bercot wrote:
>> 1) I think I misunderstood how the kernel warning works. It may only
>> apply to images that the kernel execve() itself directly rather than
>> to any execve() syscall.
>
> Looks like it. Otherwise, I would have seen zillions of warning messages
> in
1) I think I misunderstood how the kernel warning works. It may only
apply to images that the kernel execve() itself directly rather than
to any execve() syscall.
Looks like it. Otherwise, I would have seen zillions of warning
messages
in my kernel logs, with all the executable-stack binaries
On Thu, Apr 8, 2021 at 2:25 PM Laurent Bercot wrote:
> What works is setting the attribute at the link level
> (-Wl,-z,noexecstack in LDFLAGS), and if it's not done, apparently
> GNU toolchains still mark the stack as executable by default in the
> binaries.
Yes that is effective at marking th
Okay, so the problem is that setting the noexecstack attribute at the
asm level (-Wa,--noexecstack in CFLAGS) is useless: even without it,
.note.GNU-stack is never marked as executable unless you have nested
functions.
What works is setting the attribute at the link level
(-Wl,-z,noexecstack i
Recent versions of the Linux kernel issue a warning when a process
executes an image with an executable stack, as an indicator of a
_potential_ security vulnerability. Such a warning is issued when
execlineb is executed.
I just checked my kernel logs and indeed, I get such a warning as well.
T
Hello,
First I apologize if this is a FAQ. I searched this mailing list
archive and the interweb at large but didn't find anything relevant.
Recent versions of the Linux kernel issue a warning when a process
executes an image with an executable stack, as an indicator of a
_potential_ security vul
16 matches
Mail list logo
