I had a bit of read of our documentation and the NetBSD documentation.The name PKGSRC_USE_STACK_CHECK, the option -fstack-check, the usage of PKGSRC_USE_STACK_CHECK in pksgrc and all the various bits of documentation seem to line up fairly well. I don't think it's worth changing any of it. We risk having inconsistent documentation if we don't find all the references.
I can see value in adding a new pkgsrc setting. I'm not in love with the length of the name PKGSRC_USE_STACK_CLASH_PROTECTION but maybe we could have PKGSRC_PROTECT_STACK_CLASH? Then we would just need to add a section B.1.2.3 to https://www.netbsd.org/docs/pkgsrc/hardening.html and call the documentation done.
I don't know what GCC means by "fully support stack clash protection", but the original discoverers of the stack clash attack think that NetBSD is protected from it as well as anyone else is. I can see that my NetSBD/amd64 9.2_STABLE system says "vm.guard_size = 1048576", so that's good. It may well be that "[m]ost targets" simply acknowledges the very many strange and wonderful targets that GCC has.
Cheers, Lloyd On 24/07/22 05:20, Thomas Klausner wrote:
Hi!
pkgsrc's PKGSRC_USE_STACK_CHECK setting adds -fstack-check to the
compiler flags.
Corresponding about a build failure with an upstream, it was pointed
out to me that even the gcc man page documents this as:
-fstack-check= is designed for Ada's needs to detect
infinite recursion and stack overflows. specific is an
excellent choice when compiling Ada code. It is not
generally sufficient to protect against stack-clash
attacks. To protect against those you want
-fstack-clash-protection.
The documentation for that says:
Most targets do not fully support stack clash protection.
Does anyone know the state of -fstack-clash-protection on NetBSD?
Should we switch from -fstack-check to -fstack-clash-protection in
pkgsrc, when PKGSRC_USE_STACK_CHECK is set?
Cheers,
Thomas