diff --git a/website/content/en/status/report-2025-04-2025-06/packrat.adoc b/website/content/en/status/report-2025-04-2025-06/packrat.adoc index 7ceaaebd22..f496bccc9c 100644 --- a/website/content/en/status/report-2025-04-2025-06/packrat.adoc +++ b/website/content/en/status/report-2025-04-2025-06/packrat.adoc @@ -1,23 +1,23 @@ === Packrat - NFS client caching on non-volatile storage Contact: Rick Macklem NFSv4.1/4.2 provides support for a feature called delegations. When a NFSv4.1/4.2 client holds a delegation, the client has certain rights to a file, including a guarantee that no other client will make changes to the file unless the delegation is recalled. -As such, when a client holds a delegation for a file, it can agressively cache the file's data, knowing that it will not be modified by other clients until it returns the delegation. +As such, when a client holds a delegation for a file, it can aggressively cache the file's data, knowing that it will not be modified by other clients until it returns the delegation. -This project is intended to allow the NFSv4.1/4.2 client to agressively cache file data on client local non-volatile storage, when the client holds a delegation for the file. +This project is intended to allow the NFSv4.1/4.2 client to aggressively cache file data on client local non-volatile storage, when the client holds a delegation for the file. I created a patch long ago to try and do this for NFSv4.0, but it was never at a stage where it was worth using. This project is a complete rewrite of the patch, done in part because NFSv4.1/4.2 plus other recent NFSv4 related changes makes doing this more feasible. The patch is getting stable now, but I am not sure if it will be ready for inclusion in FreeBSD 15 as an experimental feature enabled via a new mount option called "packrat". The main thing I still need to do is code a writeback kernel thread. Right now, dirty chunks stored on client local non-volatile storage get written back to the NFSv4.1/4.2 server upon umount. This can result in the umount taking a long time (as in many minutes). To alleviate this, I am planning on implementing a writeback kernel process that will walk the non-volatile storage and write the dirty chunks back. The trick is to make it aggressive enough that most dirty chunks have been written back when a umount is done, but not so aggressive that it impedes the performance of synchronous NFSv4.1/4.2 RPCs. -This will be very much an experimental feature, but it is hoped it will allow NFS mounts to be used more effectively, particularily in WAN situations, such as a mobile laptop. +This will be very much an experimental feature, but it is hoped it will allow NFS mounts to be used more effectively, particularly in WAN situations, such as a mobile laptop. -There is still work to be done, particularily with respect to recovery of delegations after a NFSv4.1/4.2 client restart. +There is still work to be done, particularly with respect to recovery of delegations after a NFSv4.1/4.2 client restart. diff --git a/website/content/en/status/report-2025-04-2025-06/ports-security.adoc b/website/content/en/status/report-2025-04-2025-06/ports-security.adoc index d4b4211b77..8fb04f26d6 100644 --- a/website/content/en/status/report-2025-04-2025-06/ports-security.adoc +++ b/website/content/en/status/report-2025-04-2025-06/ports-security.adoc @@ -1,24 +1,24 @@ === Security Hardening Compiler Options for the Ports Collection Links: + link:https://cgit.freebsd.org/ports/commit/Mk/Features/fortify.mk?id=7a489e95c51f47f5e25a5613e375ec000618e52a[Commit of the features] URL: link:https://cgit.freebsd.org/ports/commit/Mk/Features/fortify.mk?id=7a489e95c51f47f5e25a5613e375ec000618e52a[] + link:https://www.leidinger.net/blog/2025/05/24/freebsd-security-hardening-with-compiler-options/[FreeBSD security hardening with compiler options] URL: link:https://www.leidinger.net/blog/2025/05/24/freebsd-security-hardening-with-compiler-options/[] Contact: Alexander Leidinger The Ports Collection gained the possibility to enable some security features of modern compilers for package builds. As not all ports are compatible with them, this is not enabled by default. The 3 new features which can be enabled for the Ports Collection in [.filename]#make.conf# are: - WITH_FORTIFY=yes:: This enables mitigations of common memory safety issues, such as buffer overflows, by adding checks to functions like memcpy, strcpy, sprintf, and others when the compiler can determine the size of the destination buffer at compile time. This requires support from the FreeBSD base system and may only be available in FreeBSD 15 onwards. WITH_STACK_AUTOINIT=yes:: This enables a compiler specific option to automatically initialize local (automatic) variables to prevent the use of uninitialized memory. WITH_ZEROREGS=yes:: Zero call-used registers at function return to increase program security by either mitigating Return-Oriented Programming (ROP) attacks or preventing information leakage through registers. This depends upon support from the compiler for a given architecture. This is disabled for python ports; currently there are issues. -The blog post referenced in the links section explains how to use them, how to exclude certain ports if needed, and provides a more detailed explaination of those 3 new features along the already existing build-time security options of the Ports Collection and the basesystem build. +The blog post referenced in the links section explains how to use them, how to exclude certain ports if needed, and provides a more detailed explanation of those 3 new features along the already existing build-time security options of the Ports Collection and the basesystem build.