a2cba99b0d@dec.sakura.ne.jp> <9d4a06bc-44fd-4e9a-8615-cd71127fc90e@FreeBSD.org> Message-ID: <5544c172efe031ecdbabd2a93980cdd5@Leidinger.net> Organization: No organization, this is a private message. Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=_db35927c167ebdf8a095bc77611cda05"; micalg=pgp-sha256 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE] X-Rspamd-Queue-Id: 4Vdnps3Vnlz4tWM This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --=_db35927c167ebdf8a095bc77611cda05 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed 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 wrote: >> >>> On Mon, May 13, 2024 at 11:09:24AM -0700, Cy Schubert wrote: >>>> In message , 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 --=_db35927c167ebdf8a095bc77611cda05 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc; size=833 Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmZDEPQACgkQEg2wmwP4 2IZdUw//WgD8ibpOJbLrZVKvGIr0tZpvAnrbVYoLlqvqShRNFd9Q47g3eoa2wAwW eTCv2+nzLG427JmrfhUfiN8aEPIdOFgvOacu8tOzoRJbkXxXrDJPtmHQdtGvWCFN ozROeN7EhYen5Iuqol9bqz30wFhzbnn5gQkqSwwegIiddwW6InV7NXgQpd1lJaSm eLWO3nixsXaTFjHk+QAQAG1I5HcACZf8goW7vsa+uZhZOjHRPpTT8AXuIz/9xj1g 5g5b9l8ThpkqFDGJwT9Mi88Pce+yaHQa+kIYibEwXY5chaNYMcY3lXcp92aVCWM9 MSxwJ2NwJDhIUJwObK3FUUKdAS75sGqxBNbf0Z5sJZqPeEVKeJ5YrnHok0GAcRWB PBye/cSP15vx0aPoQ01E8nZ+8w1YLugWJCBNb2oYPDDSV8BB7WJH/D75AwbN6zX1 ctGAT2Y4K5Y0oXKOW0wJk2EWn2acACNW0QoNQVwkbi65dkTD/6ELp5eI0T3BOH1J Sh+JIkScFQ2a8mqLFs7vdGQ26cRJEcbYwfXG8BTX9n2BYgh5aDNSgHYErYrdFIW1 BIpyvDkcOUXTr6curuu3ZxSryUUXD3d7grQfIgFSa5cakk+4LDn0U1quCp2LijA/ 9qGYbx+47z8eaKjS5a6T09oXTyoAs/yR00trFOMDKN8KzzXEgsc= =6FM1 -----END PGP SIGNATURE----- --=_db35927c167ebdf8a095bc77611cda05--