HardenedBSD issueshttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues2021-07-10T18:55:45Zhttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/57hbsd-update: Provide a "download only" option2021-07-10T18:55:45ZShawn Webbhbsd-update: Provide a "download only" optionMake it easy to simply download the update archive and not do anything with it, not even extracting it. This will enable a user to be able to inspect the archive and manually apply parts of it if needed.Make it easy to simply download the update archive and not do anything with it, not even extracting it. This will enable a user to be able to inspect the archive and manually apply parts of it if needed.LoicLoichttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/56Hook llvm-ar into the tools bootstrap2021-10-01T18:04:28ZShawn WebbHook llvm-ar into the tools bootstrapWhen building base, we use the system llvm-ar. This can cause issues when the LLVM IR bitcode has been modified (and the bitcode version number bumped) and we build static/shared libraries in base with LTO.
FreeBSD recently merged llvm ...When building base, we use the system llvm-ar. This can cause issues when the LLVM IR bitcode has been modified (and the bitcode version number bumped) and we build static/shared libraries in base with LTO.
FreeBSD recently merged llvm 12.0.0 into base in 14-CURRENT. The LLVM IR bitcode spec and implementation was modified. clang had outputted object files that contained the newer bitcode. The system llvm-ar (which is at 11.0), naturally, didn't understand the new bitcode, causing a failure.
The way to solve this chicken-and-egg scenario is to include llvm-ar in the bootstrap-tools stage in `buildworld`. As of the time of writing this bug report, I made a naive attempt at hooking llvm-ar into the bootstrap-tools. The attempt failed due to llvm-ar needing to pull in the full libllvm, rather than the libllvmminimal that the bootstrap-tools installs.
Right now, in 14-CURRENT, the system must be build with MK_LTOLIB disabled for the first build. The second build can re-enable MK_LTOLIB (since the updated system has the new version of llvm-ar).Shawn WebbShawn Webbhttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/55hbsd-update -r /path/to/empty/directory fails2022-01-16T08:19:35ZSylvie Rinnerhbsd-update -r /path/to/empty/directory failsI'm trying to use hbsd-update to bootstrap some jails, but it looks like it's broken for this usecase at the moment.
When I simply run `hbsd-update -r /jails/something`, where `/jails/something` is an empty directory, I get the followin...I'm trying to use hbsd-update to bootstrap some jails, but it looks like it's broken for this usecase at the moment.
When I simply run `hbsd-update -r /jails/something`, where `/jails/something` is an empty directory, I get the following error and the whole process is aborted:
```
cp: /jails/something/boot/kernel: No such file or directory
```
Based on the man page stating that `-r` does not need to point to an existing installation, I'd expect this to work.
It does get a little but further when I specify `-n` to skip installing the kernel (which I actually wanted in this case). Then it fails with:
```
./usr/libexec/dwatch/proc-exec: Hard-link target './usr/libexec/dwatch/proc' does not exist.
./usr/libexec/dwatch/proc-signal-clear: Hard-link target './usr/libexec/dwatch/proc' does not exist.
./usr/libexec/dwatch/proc-status: Hard-link target './usr/libexec/dwatch/proc' does not exist.
./usr/libexec/dwatch/proc-signal-discard: Hard-link target './usr/libexec/dwatch/proc' does not exist.
./usr/libexec/dwatch/proc-exec-failure: Hard-link target './usr/libexec/dwatch/proc' does not exist.
./usr/libexec/dwatch/proc-exec-success: Hard-link target './usr/libexec/dwatch/proc' does not exist.
./usr/libexec/dwatch/proc-signal: Hard-link target './usr/libexec/dwatch/proc' does not exist.
./usr/libexec/dwatch/proc-signal-send: Hard-link target './usr/libexec/dwatch/proc' does not exist.
./usr/libexec/dwatch/proc-exit: Hard-link target './usr/libexec/dwatch/proc' does not exist.
./usr/libexec/dwatch/proc-create: Hard-link target './usr/libexec/dwatch/proc' does not exist.
```
I have no idea how to debug that or if there maybe is a flag I'm missing that would make it work.
My jail host system is fully updated as far as I can tell:
```
[+] Local version: hbsd-v1300061-5dbd0eeaab8b687ee5ec183cb7e782ae24cd550b
[+] Remote version: hbsd-v1300061-5dbd0eeaab8b687ee5ec183cb7e782ae24cd550b sha256 c956d5804d66408dd99cdb23efeada556bf907a678d71dbeaa7ceed6bdb4ae78
```https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/54Implement Cross-DSO CFI support2023-11-30T22:43:52ZShawn WebbImplement Cross-DSO CFI supportHardenedBSD currently supports non-Cross-DSO CFI. One major goal for HardenedBSD is to support building all of HardenedBSD with CFI. Meaning, we need to apply CFI to both static/shared libraries and applications.HardenedBSD currently supports non-Cross-DSO CFI. One major goal for HardenedBSD is to support building all of HardenedBSD with CFI. Meaning, we need to apply CFI to both static/shared libraries and applications.Control-Flow IntegrityShawn WebbShawn Webbhttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/53Release engineering: Create bittorrent files2021-10-17T16:47:49ZShawn WebbRelease engineering: Create bittorrent filesWe could make it easier for the community to mirror and distribute HardenedBSD builds. Using only tools in base, we could create the bittorrent files used for downloading and seeding. There may be some infrastructure needed to provide th...We could make it easier for the community to mirror and distribute HardenedBSD builds. Using only tools in base, we could create the bittorrent files used for downloading and seeding. There may be some infrastructure needed to provide the initial seed. That is something HardenedBSD could provide, given a set of instructions (in this issue) to build out that infrastructure.
Now that we have replaced 90% of our old build servers with newer ones, we can utilize the decommissioned servers to perform non-build-related tasks. We have three such systems.https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/52Update libexpat in base2021-05-26T20:30:39ZShawn WebbUpdate libexpat in baseThe version of libexpat in base is 2.2.9. The latest release is 2.4.1. Bring libexpat up-to-date.The version of libexpat in base is 2.2.9. The latest release is 2.4.1. Bring libexpat up-to-date.https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/51vmrun.sh: Reorder devices2021-05-24T17:17:16ZShawn Webbvmrun.sh: Reorder devicesBooting from DVD is broken due to a conflict with virtual PCI slot 31. We changed LPC to slot 31 since that's what Windows requires. That change conflicts with the DVD booting logic.Booting from DVD is broken due to a conflict with virtual PCI slot 31. We changed LPC to slot 31 since that's what Windows requires. That change conflicts with the DVD booting logic.Shawn WebbShawn Webbhttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/50Improve EFI framebuffer startup2022-02-03T19:45:19ZLoicImprove EFI framebuffer startupThe EFI framebuffer boot in FreeBSD (so HardenedBSD) often crashes on modern computers:
![20210517_162746](/uploads/2ed672f6d1d13403b2076d9a6bb109bf/20210517_162746.jpg)
See: [Bug 255208](https://bugs.freebsd.org/bugzilla/show_bug.cgi?i...The EFI framebuffer boot in FreeBSD (so HardenedBSD) often crashes on modern computers:
![20210517_162746](/uploads/2ed672f6d1d13403b2076d9a6bb109bf/20210517_162746.jpg)
See: [Bug 255208](https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209821#c35)
OpenBSD does not have this problem, we should see if we can borrow a solution.LoicLoichttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/49Harden the kenv syscalls2021-09-21T22:02:05ZShawn WebbHarden the kenv syscallsThe `kenv(2)` syscall currently allows anyone to inspect the kernel environment, regardless of privilege or jail. Since `kenv` can expose potentially sensitive information, we should limit its access to privileged, unjailed accounts.The `kenv(2)` syscall currently allows anyone to inspect the kernel environment, regardless of privilege or jail. Since `kenv` can expose potentially sensitive information, we should limit its access to privileged, unjailed accounts.https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/48Resolve cfi-icall violations2023-11-30T22:45:14ZShawn WebbResolve cfi-icall violationsMany applications violate the cfi-icall scheme. A cursory list, found by grep, is listed below. This bug report should be the master issue, tracking sub-issues to fix each individual application. So this ticket should be broken out for e...Many applications violate the cfi-icall scheme. A cursory list, found by grep, is listed below. This bug report should be the master issue, tracking sub-issues to fix each individual application. So this ticket should be broken out for each application (for example: one for md5, another for mount_nfs, another for bhyveload, etc.)
Some of these cannot be fixed until we gain Cross-DSO CFI support. For example, if a function pointer crosses a DSO boundary (dlopen/dlsym).
```
hbsd-current-01[shawn]:/usr/src $ grep -rnF CFI_OVERRIDE .
./sbin/md5/Makefile:7:CFI_OVERRIDE=-fno-sanitize=cfi-icall
./sbin/mount_nfs/Makefile:14:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./usr.sbin/rpc.yppasswdd/Makefile:18:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./usr.sbin/bhyveload/Makefile:8:CFI_OVERRIDE=-fno-sanitize=cfi-icall
./usr.sbin/mountd/Makefile:7:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./usr.sbin/pwd_mkdb/Makefile:11:CFI_OVERRIDE=-fno-sanitize=cfi-icall
./usr.sbin/blacklistd/Makefile:23:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./usr.sbin/rpc.ypupdated/Makefile:11:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./usr.sbin/rpc.umntall/Makefile:10:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./usr.sbin/rpc.ypxfrd/Makefile:10:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./usr.sbin/ppp/Makefile:19:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./usr.sbin/unbound/checkconf/Makefile:16:CFI_OVERRIDE=-fno-sanitize=cfi-icall
./usr.sbin/rpcbind/Makefile:10:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./usr.sbin/services_mkdb/Makefile:10:CFI_OVERRIDE=-fno-sanitize=cfi-icall
./usr.sbin/sendmail/Makefile:31:CFI_OVERRIDE=-fno-sanitize=cfi-icall
./usr.sbin/rpc.lockd/Makefile:12:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./usr.sbin/rpc.statd/Makefile:10:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./usr.bin/rpcgen/Makefile:7:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./usr.bin/showmount/Makefile:7:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./usr.bin/mail/Makefile:15:CFI_OVERRIDE=-fno-sanitize=cfi-icall
./usr.bin/rpcinfo/Makefile:12:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./usr.bin/nc/Makefile:13:CFI_OVERRIDE=-fno-sanitize=cfi-icall
./usr.bin/svn/svn/Makefile:70:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./usr.bin/vi/Makefile:19:CFI_OVERRIDE=-fno-sanitize=cfi-icall
./usr.bin/tsort/Makefile:6:CFI_OVERRIDE=-fno-sanitize=cfi-icall
./kerberos5/usr.sbin/kstash/Makefile:12:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./kerberos5/usr.sbin/iprop-log/Makefile:14:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./kerberos5/usr.sbin/ktutil/Makefile:19:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./kerberos5/libexec/hprop/Makefile:19:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./kerberos5/libexec/hpropd/Makefile:12:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./kerberos5/libexec/kcm/Makefile:20:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./kerberos5/libexec/ipropd-slave/Makefile:13:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./kerberos5/libexec/kadmind/Makefile:10:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./kerberos5/libexec/kdigest/Makefile:13:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./kerberos5/libexec/kdc/Makefile:11:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./kerberos5/libexec/kpasswdd/Makefile:11:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./kerberos5/libexec/digest-service/Makefile:15:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./kerberos5/libexec/ipropd-master/Makefile:13:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./kerberos5/libexec/kimpersonate/Makefile:11:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./kerberos5/libexec/kfd/Makefile:9:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./kerberos5/usr.bin/kdestroy/Makefile:8:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./kerberos5/usr.bin/kcc/Makefile:19:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./kerberos5/usr.bin/string2key/Makefile:13:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./kerberos5/usr.bin/kadmin/Makefile:27:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./kerberos5/usr.bin/kf/Makefile:9:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./kerberos5/usr.bin/kpasswd/Makefile:8:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./kerberos5/usr.bin/kinit/Makefile:7:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./kerberos5/usr.bin/kgetcred/Makefile:8:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./kerberos5/usr.bin/hxtool/Makefile:14:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./kerberos5/usr.bin/verify_krb5_conf/Makefile:9:CFI_OVERRIDE= -fno-sanitize=cfi-icall
./kerberos5/usr.bin/ksu/Makefile:13:CFI_OVERRIDE= -fno-sanitize=cfi-icall
```Control-Flow IntegrityLoicLoichttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/47Disable INCLUDE_CONFIG_FILE2023-01-31T13:57:59ZShawn WebbDisable INCLUDE_CONFIG_FILEIn our quest to remove "kernel infoleaks as features", we should disable the `INCLUDE_CONFIG_FILE` kernel config option. Doing this has a negative impact in kernel crash dump analysis, but helps with our overall goal of removing kernel i...In our quest to remove "kernel infoleaks as features", we should disable the `INCLUDE_CONFIG_FILE` kernel config option. Doing this has a negative impact in kernel crash dump analysis, but helps with our overall goal of removing kernel infoleaks.LoicLoichttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/46Bring in jemalloc sized-delete size-checking patch2021-05-18T16:24:00ZShawn WebbBring in jemalloc sized-delete size-checking patchThis hit my radar: https://github.com/jemalloc/jemalloc/commit/eaed1e39be8574b1a59d21824b68e31af378cd0fThis hit my radar: https://github.com/jemalloc/jemalloc/commit/eaed1e39be8574b1a59d21824b68e31af378cd0fhttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/45Create bootloader branding2021-05-28T18:42:49ZShawn WebbCreate bootloader brandingFreeBSD drastically updated the capabilities of the UEFI bootloader to support a framebuffer ( https://reviews.freebsd.org/D27420 ), enabling use of PNG files in the bootloader. We can now use high-resolution images to brand the bootload...FreeBSD drastically updated the capabilities of the UEFI bootloader to support a framebuffer ( https://reviews.freebsd.org/D27420 ), enabling use of PNG files in the bootloader. We can now use high-resolution images to brand the bootloader. This issue is to track the creation of said branding.LoicLoichttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/44Teach bhyve to lock memory2023-12-01T15:41:51ZShawn WebbTeach bhyve to lock memoryTeach bhyve to use `mlockall` when configured to do so via the command-line. Doing so will ensure that the VM's memory will not be swapped to disk.Teach bhyve to use `mlockall` when configured to do so via the command-line. Doing so will ensure that the VM's memory will not be swapped to disk.Shawn WebbShawn Webbhttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/43hbsd-update EFI problem2022-05-22T16:03:46ZGhost Userhbsd-update EFI problemOn Tuesday, May 11, 2021 at 9:22:57 AM UTC+2 Pawel Kraszewski wrote:
I have 2 fresh HardenedBSD devices. Everything went OK, but I can't
hbsd-update them. Each attempt ends with:
```
hbsd-v1300061-1b8f98e0dc43779ceefacc1774c386f70c0d5...On Tuesday, May 11, 2021 at 9:22:57 AM UTC+2 Pawel Kraszewski wrote:
I have 2 fresh HardenedBSD devices. Everything went OK, but I can't
hbsd-update them. Each attempt ends with:
```
hbsd-v1300061-1b8f98e0dc43779ceefacc1774c386f70c0d5d49
/tmp/tmp.oQXHvxYP/update.tar 530 MB 1132 kBps
07m59s
./efi/: Can't restore time
tar: Error exit delayed from previous errors.
```
Partitions are default for EFI install:
# cat /etc/fstab
```
# Device Mountpoint FStype Options Dump Pass#
/dev/ada0p2 / ufs rw 1 1
/dev/ada0p1 /boot/efi msdosfs rw 2 2
/dev/ada0p3 none swap sw 0 0
```
# mount
```
/dev/ada0p2 on / (ufs, local, journaled soft-updates)
devfs on /dev (devfs)
/dev/ada0p1 on /boot/efi (msdosfs, local)
```
Free space is plenty:
# df -h
```
Filesystem Size Used Avail Capacity Mounted on
/dev/ada0p2 111G 2.3G 100G 2% /
devfs 1.0K 1.0K 0B 100% /dev
/dev/ada0p1 256M 1.7M 254M 1% /boot/efi
```
installed packages don't go beyond mc/rsync/tmux/zsh with dependencies.
--
On Tue, May 11, 2021 at 06:30:57AM -0700, Balazs Toth wrote:
I have the same problem, I do not know the final solution but you will be
able to update if you umount the EFI partition until you execute the
hbsd-update. I can not guarantee your system will boot afterwards but mine
did, and I think yours will boot as well as there only the EFI loader how
far I know.
--
On Tue, May 11, 2021 at 09:39:44AM -0400, Shawn Webb wrote:
I remember reading a FreeBSD commit that enforces the mount of
/boot/efi. This probably conflicts with how hbsd-update untars the
base tarball.
I'll take a look this week. Thanks for the report, Pawel, and the
confirmation it applies to multiple systems, Balazs.
I'll report back when I have more info.Shawn WebbLoicShawn Webbhttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/42Harden FreeBSD's recent coredump changes2021-05-18T18:42:19ZShawn WebbHarden FreeBSD's recent coredump changesFreeBSD commit 86ffb3d1a0cbb09ba0123ff8d34149e691b461c4 introduced the capability to dump non-dumpable memory mappings. We need to harden against potential abuse of this.FreeBSD commit 86ffb3d1a0cbb09ba0123ff8d34149e691b461c4 introduced the capability to dump non-dumpable memory mappings. We need to harden against potential abuse of this.Shawn WebbShawn Webbhttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/4113-STABLE Build 71: random_pid conflict with enable_aslr?2021-10-01T18:01:20Zflyingplastic13-STABLE Build 71: random_pid conflict with enable_aslr?Just installing 13-STABLE version, build 71 (latest) using disc1.iso. During hardening setup at the end of installation, I chose both **random_pid** and **enable_aslr**. However, after reboot, it's just went to kernel panic, and keeps re...Just installing 13-STABLE version, build 71 (latest) using disc1.iso. During hardening setup at the end of installation, I chose both **random_pid** and **enable_aslr**. However, after reboot, it's just went to kernel panic, and keeps rebooting with the error:
```
sysctl: oid 'kern.randompid' is read only at line 15
panic: ET_DYN_ADDR_RAND but !MAP_ASLR
cpuid = 4
time = 1619410691
__HardenedBSD_Version = 1300061 __FreeBSD_version = 1300501
version = FreeBSD 13.0-STABLE-HBSD #59 hardened/13-stable/master-n190182-39d8f0a3bd1: Sun Apr 25 11:44:05 EDT 2021
ro...@ci-01.md.hardenedbsd.org:/usr/obj/src/13-stable/amd64.amd64/sys/HARDENEDBSD
KBD: stack backtrace:
#0 0xffffffff80c52f5b at kdb_backtrace+0x6b
#1 0xffffffff80c086c6 at vpanic+0x186
#2 0xffffffff80c08493 at panic+0x43
#3 0xffffffff80b97480 at exec_elf64_imgact+0x1170
#4 0xffffffff80bbca4b at kern_execve+0x67b
#5 0xffffffff80bbc05a at sys_execve+0x5a
#6 0xffffffff810a8c9a at amd64_syscall+0x13a
#7 0xffffffff8107d39e at fast_syscall_common+0xf8
Uptime: 4s
```
![HBSD_KernelPanic_ASLR](/uploads/951d4c209d7867718927dd0e266af04e/HBSD_KernelPanic_ASLR.jpeg)
Version: HardenedBSD 13-STABLE Build 71 64-Bit
Running on: VirtualBox 6.1.20 r143896
RAM: 8192MB
Proc: 6 Core
If **enable_aslr** was disabled in hardening option during HBSD installation, it's booting just fine. Kernel Panic also occurs only on multi-user mode, single-user mode will run just fine without any Kernel Panic (can also confirmed that when in single-user mode, switching to multi-user mode by pressing CTRL+D will create the same Kernel Panic).
TBH, I've been left far far behind in my understanding of C or C++ programming and codes, but digging into the kernel code where the panic message is suggest that there must be something about these codes in sys/kern/imgact_elf.c:
```
if (do_asr) {
**KASSERT((map->flags & MAP_ASLR) != 0,
("ET_DYN_ADDR_RAND but !MAP_ASLR"));**
et_dyn_addr = __CONCAT(rnd_, __elfN(base))(map,
vm_map_min(map) + mapsz + lim_max(td, RLIMIT_DATA),
/* reserve half of the address space to interpreter */
maxv / 2, 1UL << flsl(maxalign));
}
```
With **enable_aslr** mode turned on, it checks and failed the kernel assertion of MAP_ASLR, but I have no idea what are the rest. Can I say that ELF loader failed to conform to ASLR?
For additional note: fresh install, just as finishing the setup. Disk is formatted as MBR UFS. I did not use ZFS because when i tried that on my FreeBSD with ZFS, pkg upgrade messed up everything (can't remember the error code, but when I reinstall FBSD with UFS and perform the same actions, it is ok. Plus I don't need ZFS for now since there is only 1 disk and all running as Guest VM in VBox).
Hopefully someone can help me understand those codes and how to fix it.
Thank you :)Shawn WebbShawn Webbhttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/40Kernel panic with Intel Wireless 4965AGN chip2021-04-28T14:05:48ZRadosław ChmielarzKernel panic with Intel Wireless 4965AGN chipHi,
I hope this issue is directed at the correct project. In case I should contact FreeBSD please tell me so.
The issue was spotted when using OPNSense 21.1.4, which is using FreeBSD 12.1-RELEASE-p15-HBSD.
After attaching Intel Wirele...Hi,
I hope this issue is directed at the correct project. In case I should contact FreeBSD please tell me so.
The issue was spotted when using OPNSense 21.1.4, which is using FreeBSD 12.1-RELEASE-p15-HBSD.
After attaching Intel Wireless WiFi Link 4965AGN I have experienced a kernel panic with stack trace pointing to ieee80211_chan_init() originating from iwn_attach(). Probably the kernel is pointing to a more precise piece of code but I'm using an USB keyboard and the driver is probably not loaded at this point as I can't type anything.
I've made a low-tech picture with my phone.
![IMG_20210422_105743](/uploads/07165b23a091e181825d7cb5b80f2340/IMG_20210422_105743.jpg)
Cheers,
Radekhttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/39Update OpenSSH in base2021-09-15T18:15:34ZShawn WebbUpdate OpenSSH in baseThe version of OpenSSH in base is pathetically outdated with multiple known vulnerabilities. FreeBSD has fallen behind, so we need to do our own due diligence in keeping OpenSSH up-to-date in base. I'm marking this issue as "help wanted"...The version of OpenSSH in base is pathetically outdated with multiple known vulnerabilities. FreeBSD has fallen behind, so we need to do our own due diligence in keeping OpenSSH up-to-date in base. I'm marking this issue as "help wanted" because that's the reality.
This will be a longer task with the potential to be a continuous one.https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/38[HardenedBSD13] Kernel Crash generated by secadm-kmod2021-05-01T13:52:02ZLoic[HardenedBSD13] Kernel Crash generated by secadm-kmodHi,
I get a kernel crash generated by secadm-kmod:
![panic](/uploads/3816634ccc472ad3facb69b298f814b9/panic.png)
**Reproduce** (Not to be done on your work machine)
```
pkg install -fy secadm secadm-kmod
sysrc secadm_enable=yes
echo "...Hi,
I get a kernel crash generated by secadm-kmod:
![panic](/uploads/3816634ccc472ad3facb69b298f814b9/panic.png)
**Reproduce** (Not to be done on your work machine)
```
pkg install -fy secadm secadm-kmod
sysrc secadm_enable=yes
echo " " > /usr/local/etc/secadm.rules
/usr/local/etc/rc.d/secadm start
```
Above and on purpose I show a 2nd problem via the `echo` command I generate an infinite dump loop that will prevent normal startup.
![loop](/uploads/abfed5f3d3827a442e8a2c906f1a092e/loop.png)
I was able to reproduce it easily on HardenedBSD 13, I never had/discovered the problem on version 12.
Thanks.Shawn WebbShawn Webb