I think rtld must never be built with this thing enabled. In particular, if it references some libc symbol, then just that symbol should be used, without any wrappers.

Also I think that libthr should avoid it, but might be it is not as important as for rtld. In particular, did you checked that e.g. cancellation for read(2) still works as intended?

In D32308#729152, @kib wrote:

I think rtld must never be built with this thing enabled. In particular, if it references some libc symbol, then just that symbol should be used, without any wrappers.

Also I think that libthr should avoid it, but might be it is not as important as for rtld. In particular, did you checked that e.g. cancellation for read(2) still works as intended?

rtld was already not building with it by virtue of MK_SSP=no, but I've applied the FORTIFY_SOURCE=0 hammer as well to ensure that one can't turn it on manually when building with something like WITHOUT_SSP=yes FORTIFY_SOURCE=2.

libthr is in the same boat, but turning it on and this primitive test still seems to cancel at the beginning of the read:

#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
#include <unistd.h>

#define BUFSIZE 512

int
main(int argc, char *argv[])
{
        char buf[BUFSIZE];
        ssize_t rd;

        pthread_cancel(pthread_self());

        rd = read(STDIN_FILENO, buf, sizeof(buf));
        pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL);
        write(STDOUT_FILENO, buf, rd);

        printf("done\n");

        exit(1);
}

(assuming the anticipated failure mode would have been interposing failed and read() was libc-read, so the cancel would fail and maybe cancel at write() thus disabling cancellation just before it)

That said, I don't feel particularly compelled to leave it to the whim of a user-knob that nobody working on libthr is going to test, so I'll force it off in the next version as it will be in rtld.

This one is OK as is, just one question...

Ping

do we have user-facing documentation? maybe just expanding WITHOUT_SSP's description?

In D32308#1024838, @emaste wrote:

do we have user-facing documentation? maybe just expanding WITHOUT_SSP's description?

I wonder if it makes sense to add a section on stack overflow detection to security(7) would make sense

Ping

I wonder if it makes sense to add a section on stack overflow detection to security(7) would make sense

Yeah that sounds good

In D32308#1024957, @kevans wrote:

In D32308#1024838, @emaste wrote:

do we have user-facing documentation? maybe just expanding WITHOUT_SSP's description?

I wonder if it makes sense to add a section on stack overflow detection to security(7) would make sense

I think that'd be useful, and it'd be good to describe/summarize FORTIFY_SOURCE there as well. Then the src.conf entry for WITH_SSP can refer to it.