Re: Initial implementation of _FORTIFY_SOURCE
- Reply: Shawn Webb : "Re: Initial implementation of _FORTIFY_SOURCE"
- In reply to: Kyle Evans : "Re: Initial implementation of _FORTIFY_SOURCE"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 14 May 2024 07:21:09 UTC
Am 2024-05-14 05:16, schrieb Kyle Evans: > On 5/13/24 18:05, Tomoaki AOKI wrote: >> On Mon, 13 May 2024 18:57:26 +0000 >> Shawn Webb <shawn.webb@hardenedbsd.org> wrote: >> >>> On Mon, May 13, 2024 at 11:09:24AM -0700, Cy Schubert wrote: >>>> In message <f8000e6b-226b-45f3-a751-aca790f4f8c8@FreeBSD.org>, Kyle >>>> Evans >>>> write >>>> s: >>>>> Hi, >>>>> >>>>> As of 9bfd3b407 ("Add a build knob for _FORTIFY_SOURCE"), I've >>>>> imported >>>>> an initial version of FORTIFY_SOURCE from FreeBSD. FORTIFY_SOURCE >>>>> is an >>>>> improvement over classical SSP, doing compiler-aided checking of >>>>> stack >>>>> object sizes to detect more fine-grained stack overflow without >>>>> relying >>>>> on the randomized stack canary just past the stack frame. >>>>> >>>>> This implementation is not yet complete, but we've done a review of >>>>> useful functions and syscalls to add checked variants of and intend >>>>> to >>>>> complete the implementation over the next month or so. >>>>> >>>>> Please test _FORTIFY_SOURCE out now by setting FORTIFY_SOURCE=2 in >>>>> the >>>>> buildworld env -- I intend to flip the default to 2 when WITH_SSP >>>>> is set >>>>> in the next month if nobody complains about serious breakage. I've >>>>> personally been rolling with FORTIFY_SOURCE=2 for the last three >>>>> years >>>>> that this has been sitting in a local branch, so I don't really >>>>> anticipate any super-fundamental breakage. >>>> >>>> Should this trigger a __FreeBSD_version bump? >>> >>> I would encourage that so to help the ports tree determine >>> availability of the import. >> >> If it can be enabled/disabled with sysctls/tunables on >> runtime/boottime, >> bump should be preferred. Maybe this isn't yet the case here, IIUC. >> >> But if it could be done only on build time with WITH_ or WITHOUT_ knob >> ad not yet enabled by default for now, now ins't the time to bump. >> Bump should be done when it becomes to be built by default. >> >> Bump for non-default build time knob should force poudriere[-devel] >> users massive unneeded rebuilds. So should be avoided, if it still >> cannot switch on boot or runtime. >> > > It's strictly build time, and I didn't really see the value in bumping > __FreeBSD_version for it. I don't see any reason to, e.g., turn it > into a per-port option that we may not want to have if the feature > isn't there, and the knob to build it in is a preprocessor define > that's harmless if the feature isn't actually available. Ports: We have WITH_PIE, WITH_BIND_NOW and WITH_RELRO (e.g. for make.conf) which enables those build time options globally. Ports then can have e.g. PIE_UNSAFE=yes to opt-out of WITH_PIE builds. I think it would be beneficial if we get something similar for FORTIFY. I already use all of the afore mentioned options in my own builds (and have provided NO_PIE hints where it fails), and I would surely give a similar FORTIFY option a try. On a somewhat related note, has someone already played with CFI (https://clang.llvm.org/docs/ControlFlowIntegrity.html)? Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF