Tweet
I wanted to ping the HardenedBSD community, asking about the usefulness of crunchgen(1)-built applications in 2024.
From the crunchgen(1) manual page:
> The main reason to crunch programs together is for fitting as many
> programs as possible onto an installation or system recovery floppy.
The binaries in /rescue are built with crunchgen. It seems that crunchgen-built applications are not (currently) compatible with a libc built with LTO due to the recent CSU and libc changes.
The size of the binaries in /rescue on HardenedBSD 15-CURRENT/amd64 are 17MB in size. That application size alone makes it impossible to build a "system recovery floppy". Additionally, floppy drives aren't all too common on the amd64, arm64, and riscv64 systems HardenedBSD targets.
Control Flow Integrity (CFI) is a compiler-based exploit mitigation that we apply to applications in HardenedBSD 15-CURRENT and 14-STABLE.
In order to apply CFI to applications, application code must be built with Link Time Optimization (LTO).
Over the past few years, I've slowly been working on applying CFI to shared objects (aka, Cross-DSO CFI). This requires building library code with LTO as well.
It seems that with the recent changes to the CSU and libc, the crunchgen(1) built tool does not produce workable applications when libc is built with LTO. With libc having such a huge surface area, it would be prudent to apply Cross-DSO CFI to it.
This presents two possible solutions:
1. Enhance crunchgen(1) to support libc built with LTO.
2. Kick crunchgen(1) to the curb.
3. Other ideas from the community are possible.
Does anyone find crunchgen(1) to be truly useful in 2024? If we kick crunchgen(1) to the curb, we need to modify the build system for /rescue binaries.
My own preference would indeed to rid ourselves of crunchgen(1) so that we can progress towards applying Cross-DSO CFI and LTO to libc​.
From the crunchgen(1) manual page:
> The main reason to crunch programs together is for fitting as many
> programs as possible onto an installation or system recovery floppy.
The binaries in /rescue are built with crunchgen. It seems that crunchgen-built applications are not (currently) compatible with a libc built with LTO due to the recent CSU and libc changes.
The size of the binaries in /rescue on HardenedBSD 15-CURRENT/amd64 are 17MB in size. That application size alone makes it impossible to build a "system recovery floppy". Additionally, floppy drives aren't all too common on the amd64, arm64, and riscv64 systems HardenedBSD targets.
Control Flow Integrity (CFI) is a compiler-based exploit mitigation that we apply to applications in HardenedBSD 15-CURRENT and 14-STABLE.
In order to apply CFI to applications, application code must be built with Link Time Optimization (LTO).
Over the past few years, I've slowly been working on applying CFI to shared objects (aka, Cross-DSO CFI). This requires building library code with LTO as well.
It seems that with the recent changes to the CSU and libc, the crunchgen(1) built tool does not produce workable applications when libc is built with LTO. With libc having such a huge surface area, it would be prudent to apply Cross-DSO CFI to it.
This presents two possible solutions:
1. Enhance crunchgen(1) to support libc built with LTO.
2. Kick crunchgen(1) to the curb.
3. Other ideas from the community are possible.
Does anyone find crunchgen(1) to be truly useful in 2024? If we kick crunchgen(1) to the curb, we need to modify the build system for /rescue binaries.
My own preference would indeed to rid ourselves of crunchgen(1) so that we can progress towards applying Cross-DSO CFI and LTO to libc​.
Comment