Novo mascote aqui na empresa! Olha só que coisinha mais fofinha from hell!!! 🤘🏻🤘🏻🤘🏻

@freebsd

Some of the highlights:

OpenSSH has been updated to version 9.5p1.

OpenSSL has been updated to version 3.0.12, a major upgrade from OpenSSL 1.1.1t in FreeBSD 13.2-RELEASE.

The bhyve hypervisor now supports TPM and GPU passthrough.

FreeBSD supports up to 1024 cores on the amd64 and arm64 platforms.

ZFS has been upgraded to OpenZFS release 2.2, providing significant performance improvements.

It is now possible to perform background filesystem checks on UFS file systems running with journaled soft updates.

Experimental ZFS images are now available for AWS and Azure.

The default congestion control mechanism for TCP is now CUBIC.

And much more…​

For a complete list of new features and known problems, please see the online release notes and errata list, available at:

https://www.FreeBSD.org/releases/14.0R/relnotes/

II. Problem Description

Some of the Sanitizers cannot work correctly when ASLR is enabled. Therefore, at the initialization of such Sanitizers, ASLR is detected via procctl(2). If ASLR is enabled, it is first disabled, and then the main executable containing the Sanitizer is re-executed, after printing an appropriate message.

However, the Sanitizers work by intercepting various function calls, and by mistake the already-intercepted procctl(2) function was used. This causes an internal error, which usually results in a segfault.

III. Impact

Binaries linked to AddressSanitizer (using -fsanitize=address), MemorySanitizer (using -fsanitize=memory) or ThreadSanitizer (using -fsanitize=thread) can crash at startup with a segfault, if ASLR is enabled. Other binaries are not affected.

IV. Workaround

If ASLR is enabled system-wide, the problem can be worked around by running the specific binary with proccontrol(1), to temporarily disable ASLR for only that program. For example:

proccontrol -m aslr -s disable /path/to/example_program

II. Problem Description

A check did not test both the dnode itself and its data for dirtiness. This provides a very small window of time while a file is being modified where the dirtiness check can falsely report that the dnode is clean. If this happens a hole may incorrectly be reported where data was written.

III. Impact

If an access occurs while a file is being modified and a hole is incorrectly reported, the data may instead be interpreted as zero bytes. Any application which checks for holes may be affected by this issue; if this occurs during a file copy it will result in a corrupt copy that retains the incorrect data. Note that the source file remains intact (a subsequent read will return the correct data).

IV. Workaround

Setting the vfs.zfs.dmu_offset_next_sync sysctl to 0 disables forcing TXG sync to find holes. This is an effective workaround that greatly reduces the likelihood of encountering data corruption, although it does not completely eliminate it. Note that with the workaround holes will not be reported in recently dirtied files. See the zfs(4) man page for more information of the impact of this sysctl setting.

The workaround should be removed once the system is updated to include the fix described in this notice.

Screengrab from my Lenovo laptop from back in February

Looking to get started with FreeBSD jails? bastille is a jail manager that feels like a better, cleaner idea of what Docker was meant to be. It is easy to install, and uses zfs to cache OS versions to reduce the size and footprint of jails. There are template to make it easier to install common services.

Probably the best place to get started on learning the nitty-gritty of FreeBSD, including how to set up desktop environments.