HardenedBSD issueshttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues2024-03-18T18:01:52Zhttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/79Add notion of "insecure kernel module"2024-03-18T18:01:52ZShawn WebbAdd notion of "insecure kernel module"We need to mark certain kernel modules with a notion of "this module may cause security issues." We should add a flag to the KLD API to specify whether to load modules marked as insecure, with a default of disabled.
Some good modules to...We need to mark certain kernel modules with a notion of "this module may cause security issues." We should add a flag to the KLD API to specify whether to load modules marked as insecure, with a default of disabled.
Some good modules to start with:
1. linux.ko
1. linux32.ko
1. smbfs.ko
1. accf_http.koShawn WebbShawn Webbhttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/14KP on tmpfs after removing extended attributes2024-02-09T01:01:02ZShawn WebbKP on tmpfs after removing extended attributes*Created by: dmilith*
Steps to reproduce:
- /tmp has to be mounted as tmpfs.
- `pkg install openjdk8; cd /usr/local; tar cJf /tmp/tarball.tar.xz openjdk8; cd /tmp; tar xf tarball.tar.xz; hbsdcontrol pax reset mprotect openjdk8/bin/jav...*Created by: dmilith*
Steps to reproduce:
- /tmp has to be mounted as tmpfs.
- `pkg install openjdk8; cd /usr/local; tar cJf /tmp/tarball.tar.xz openjdk8; cd /tmp; tar xf tarball.tar.xz; hbsdcontrol pax reset mprotect openjdk8/bin/java`
First issue is tar xf reporting failures setting ext attrs.
Second is after hbsdcontrol pax reset - which causes KP: https://gist.github.com/lattera/9b94053d2abfd94038c28053689e8e73
Affects 12-stable and up.Shawn WebbShawn Webbhttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/2Remove LibreSSL in Base2024-01-05T19:01:26ZShawn WebbRemove LibreSSL in BaseThe version of LibreSSL in HardenedBSD is horribly out-of-date. As there is no real maintainer of LibreSSL in HardenedBSD, remove it from HardenedBSD base. This will help with diff reduction as well.The version of LibreSSL in HardenedBSD is horribly out-of-date. As there is no real maintainer of LibreSSL in HardenedBSD, remove it from HardenedBSD base. This will help with diff reduction as well.Shawn WebbShawn Webbhttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/1Migrate bsdinstall to new infrastructure2024-01-05T19:01:26ZShawn WebbMigrate bsdinstall to new infrastructureThe `bsdinstall` script needs to know from where to download optional distsets. The old URLs from before the infrastructure rebuild are still referenced in `bsdinstall`. Switch out the old URLs for the new.The `bsdinstall` script needs to know from where to download optional distsets. The old URLs from before the infrastructure rebuild are still referenced in `bsdinstall`. Switch out the old URLs for the new.Shawn WebbShawn Webbhttps://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/30Investigate bhyve vCPU > 162023-12-01T15:36:50ZShawn WebbInvestigate bhyve vCPU > 16FreeBSD keeps talking about supporting vCPU > 16 with bhyve, yet they never do anything about it. One of our new build servers has 36 CPU cores across two CPU sockets, enabling us to be able to use more than 16 vCPUs for a single VM.
Le...FreeBSD keeps talking about supporting vCPU > 16 with bhyve, yet they never do anything about it. One of our new build servers has 36 CPU cores across two CPU sockets, enabling us to be able to use more than 16 vCPUs for a single VM.
Let's see if we can do this on our end.Shawn WebbShawn Webbhttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/6Port paxtest to kyua tests2023-12-01T15:36:37ZShawn WebbPort paxtest to kyua testsNow that FreeBSD imported kyua into base, porting `paxtest` from the tools repo to Kyua would be great. We could more easily track potential regressions. Additionally, we can get rid of the `paxtest` source tarball in the tools repo.
`p...Now that FreeBSD imported kyua into base, porting `paxtest` from the tools repo to Kyua would be great. We could more easily track potential regressions. Additionally, we can get rid of the `paxtest` source tarball in the tools repo.
`paxtest` lives here: https://git-01.md.hardenedbsd.org/HardenedBSD/tools/src/branch/master/tests/paxtest-freebsd/paxtest-0.9.14-freebsd.tgzhttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/75dbopen(3): Develop mechanism for cfi-icall-safe function pointer calls2023-11-30T22:43:41ZShawn Webbdbopen(3): Develop mechanism for cfi-icall-safe function pointer callsThe `dbopen(3)` API (and ABI) present issues with the cfi-icall scheme. Function pointers are stuffed into a structure whereby the function pointers usually point to functions in libc. This presents a problem since we don't support Cross...The `dbopen(3)` API (and ABI) present issues with the cfi-icall scheme. Function pointers are stuffed into a structure whereby the function pointers usually point to functions in libc. This presents a problem since we don't support Cross-DSO CFI, causing the CFI checks to fail on an uninstrumented function pointer address.
```
typedef struct {
DBTYPE type;
int (*close)(DB *db);
int (*del)(const DB *db, const DBT *key, u_int flags);
int (*fd)(const DB *db);
int (*get)(const DB *db, const DBT *key, DBT *data, u_int flags);
int (*put)(const DB *db, DBT *key, const DBT *data,
u_int flags);
int (*sync)(const DB *db, u_int flags);
int (*seq)(const DB *db, DBT *key, DBT *data, u_int flags);
} DB;
```
The `dbopen(3)` function sets these function pointers to functions within libc. Applications are expected to call these function pointers directly.
We can solve this in one of two ways:
1. Provide wrapper functions in libc that calls the function pointers.
1. Provide wrapper functions in `sa(8)` that calls the function pointers. These wrapper functions would need to have cfi-icall disabled.
Option 1 is likely the best route to go. Ideally, applications wouldn't want to access this ABI at all since changes to it (which are unlikely) could cause ripples downstream.Shawn WebbShawn Webbhttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/24USB wireless mice are dead and frozen2023-09-19T00:01:40ZShawn WebbUSB wireless mice are dead and frozen*Created by: hd_scania*
Told to you on Telegram, with everyting, even **including** wireless networks, are still ok by having run XFCE by `startx`, but the USB **wireless** mice are still being dead, USB **wired** mice are **neither** w...*Created by: hd_scania*
Told to you on Telegram, with everyting, even **including** wireless networks, are still ok by having run XFCE by `startx`, but the USB **wireless** mice are still being dead, USB **wired** mice are **neither** working ...
My `rc.conf` has `moused_enable=YES` and `moused_type=auto`, but my USB wireless mice aren’t working yet ...
Plus by this turn backing to HBSD, SDDM is crashed, and Plasma is also still being turbulent ...
```
HardenedBSD 13-CURRENT
Host: Sony VPCCB17FG
Cores: Intel i7-2620M
RAM: 7.45GiB
Graphics: AMD Radeon
HardenedBSD root: 37.5GiB
SSD: 953GiB
```https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/22debugging using dtrace doesn’t appear to be working on HBSD 12.x2023-09-19T00:01:39ZShawn Webbdebugging using dtrace doesn’t appear to be working on HBSD 12.x*Created by: tuto2*
**Describe the bug**
When trying to use dtrace to monitor the kernel call stack, none of the kernel function names can be resolved by dtrace (and possibly other tools as well). Trying the same procedure on a stock Fr...*Created by: tuto2*
**Describe the bug**
When trying to use dtrace to monitor the kernel call stack, none of the kernel function names can be resolved by dtrace (and possibly other tools as well). Trying the same procedure on a stock FreeBSD machine does seem to function without issues.
When debugging the kernel source, we ran into this commit https://github.com/HardenedBSD/hardenedBSD/commit/37a8b2de291f4cb84b5cac86aab8e5edcaa75176 which describes the addition of a new privilege named `PRIV_KLD_STAT`, which, in the context of dynamically loaded kernel modules, is meant to prevent non-root users from being able to see kernel modules. This is indeed the case, except the root user get shielded from gaining insights into the machine as well due to masking the addresses in the same function (https://github.com/HardenedBSD/hardenedBSD/commit/37a8b2de291f4cb84b5cac86aab8e5edcaa75176#diff-c3d5aa900131c65102c23e944303538392a83cc73492e590a65b65f1b1505da1R1259-R1263).
One of the fastest pointers to tell something is off seems to be to to run `kldstat` as root and witness all kernel addresses are zeroed out (0x0). This becomes problematic when tracing kernel performance using Dtrace or any other facility, as C type data (ctf(5)) does not get resolved properly, and instead gets resolved to non-descriptive kernel addresses.
**To Reproduce**
The following steps assume the following options in GENERIC:
```
makeoptions DEBUG=-g
makeoptions WITH_CTF=1
options KDTRACE_FRAME
options KDTRACE_HOOKS
```
1. Build a DEBUG SMP kernel with `nooptions PAX_HARDENING` and run the following (arbitrary) command:
`dtrace -n uiomove:entry’{@[stack] = count(); }’`
Run this for some time and press CTRL-C. The result will show an aggregate of unique kernel stack traces, e.g.:
```
kernel`m_uiotombuf+0x10c
kernel`sosend_generic+0x40d
kernel`sosend+0x50
kernel`kern_sendit+0x237
kernel`sendit+0x19e
kernel`sys_sendto+0x4d
kernel`amd64_syscall+0x364
kernel`0xffffffff811e38d0
4
kernel`ttydisc_write+0xcc
kernel`ttydev_write+0x155
kernel`devfs_write_f+0xda
kernel`dofilewrite+0xb0
kernel`sys_write+0xc1
kernel`amd64_syscall+0x364
kernel`0xffffffff811e38d0
5
```
2. Do the same as step 1, but build the kernel with `options PAX_HARDENING`. The results are as follows:
```
0xffffffff80da98bc
0xffffffff80db29dd
0xffffffff80db2ed0
0xffffffff80db9d47
0xffffffff80dba0be
0xffffffff80db9f0d
0xffffffff8120b064
0xffffffff811e3b00
4
0xffffffff80da20fc
0xffffffff80d9c8b5
0xffffffff80ba777a
0xffffffff80d82b70
0xffffffff80d826d1
0xffffffff8120b064
0xffffffff811e3b00
5
```
**Expected behavior**
The question probably is if we really want to mask these addresses for the root user, there might be a use case for it, but if there is, it should be properly documented and perhaps being a separate build option so you don’t have to disable the PAX_HARDENING in full to stop masking addresses. If we assume that the root user itself was already properly safeguarded, question is why addresses are being masked since regular users seem not to be able to reach this point at all.
**Additional context**
The documentation at https://git-01.md.hardenedbsd.org/HardenedBSD/HardenedBSD/wiki#user-content-generic-system-hardening specifies that the PAX_HARDENING kernel option restricts what NON-root users are permitted to do. However, this option also affects the root user.
**Environment**
OPNsense 21.1.a (amd64, OpenSSL).https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/17hbsd-update: Add option for getting machine-readable output2023-09-19T00:01:39ZShawn Webbhbsd-update: Add option for getting machine-readable output*Created by: Follpvosten*
While writing shell scripts and other tools using hbsd-update, I noticed that it is sometimes either hard to impossible to actually parse its output, or it works, but looks weird and as if my scripts around it ...*Created by: Follpvosten*
While writing shell scripts and other tools using hbsd-update, I noticed that it is sometimes either hard to impossible to actually parse its output, or it works, but looks weird and as if my scripts around it could break with any update.
It would be nice to have a command which produces more machine-readable output; for example, a `--json` flag (as json is often used in tooling around FreeBSD - well, it was mostly around TrueOS. But it's also a stable and reliable format, tho not too well-suited to be written by humans), but any format would be okay, really, it just has to be well-supported and the API should be stable.
For example, on running `hbsd-update -C --json`, the output to stdout might look something like:
```json
{
"local_version": "hbsd-v1200060-a5c1250e0e66e2606b30fe4bc94265fee1038b34",
"remote_version": "hbsd-v1200060-a5c1250e0e66e2606b30fe4bc94265fee1038b34"
}
```
Additionally, and I don't know if this would be a good idea, but maybe there could also be a flag like `--fail-if-no-updates` for `-C`, which would make hbsd-update return an error status code if there are no updates available (maybe a specific code like the HTTP status code 304 - Not Modified, but that's just an idea). This could be a problem if it errors for a different reason, but either way you likely don't want to update if this command fails.Shawn WebbShawn Webbhttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/15Randomize per-thread userland stacks2023-09-19T00:01:39ZShawn WebbRandomize per-thread userland stacksPer-thread userland stacks aren't randomized. Each thread's stack should begin at a randomized location. Attention should be paid to rlimit.Per-thread userland stacks aren't randomized. Each thread's stack should begin at a randomized location. Attention should be paid to rlimit.https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/13Do not enforce use of -O22023-09-19T00:01:36ZShawn WebbDo not enforce use of -O2Allow developers to specify their own optimization flag with a new `OPTIMIZATION_CFLAG` variable.Allow developers to specify their own optimization flag with a new `OPTIMIZATION_CFLAG` variable.Shawn WebbShawn Webbhttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/11Merge issue between freebsd/12-stable and hardened/12-stable/master2023-09-19T00:01:33ZShawn WebbMerge issue between freebsd/12-stable and hardened/12-stable/master*Created by: dmilith*
affects 12-stable/master and 12.1-releng/master
```
--- sys/vm/vm_map.h.orig 2020-08-14 12:10:43.380509000 +0200
+++ sys/vm/vm_map.h 2020-08-14 11:44:16.398386000 +0200
@@ -206,6 +206,7 @@
vm_flags_t flags...*Created by: dmilith*
affects 12-stable/master and 12.1-releng/master
```
--- sys/vm/vm_map.h.orig 2020-08-14 12:10:43.380509000 +0200
+++ sys/vm/vm_map.h 2020-08-14 11:44:16.398386000 +0200
@@ -206,6 +206,7 @@
vm_flags_t flags; /* flags for this vm_map */
vm_map_entry_t root; /* Root of a binary search tree */
pmap_t pmap; /* (c) Physical map */
+ vm_offset_t anon_loc;
int busy;
};
@@ -214,6 +215,9 @@
*/
#define MAP_WIREFUTURE 0x01 /* wire all future pages */
#define MAP_BUSY_WAKEUP 0x02
+#define MAP_IS_SUB_MAP 0x04 /* has parent */
+#define MAP_ASLR 0x08 /* enabled ASLR */
+#define MAP_ASLR_IGNSTART 0x10
#ifdef _KERNEL
#if defined(KLD_MODULE) && !defined(KLD_TIED)
```https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/10Options for sshd aren't applied2023-09-19T00:01:33ZShawn WebbOptions for sshd aren't applied*Created by: h3artbl33d*
#### Description
Options set in the `sshd` configuration don't seem to applu or have any effect.
#### Expected behaviour
Changing the `sshd_config` and restarting the `sshd` daemon should apply the changed confi...*Created by: h3artbl33d*
#### Description
Options set in the `sshd` configuration don't seem to applu or have any effect.
#### Expected behaviour
Changing the `sshd_config` and restarting the `sshd` daemon should apply the changed configuration.
#### Actual behaviour
Changing the `sshd_config` and restarting the `sshd` daemon doesn't apply the changed configuration.
#### Test setup
This issue applies to (at least) HardenedBSD v12.1-stable (`FreeBSD 12.1-STABLE-HBSD (HARDENEDBSD) #0 : Sat Jun 20 17:09:01 UTC 2020`) and originates at least to `HardenedBSD-12-STABLE-v1200059.3` (didn't test with older builds).
Furthermore, this issue seems specific for HardenedBSD and was confirmed to be absent in `FreeBSD $host 12.1-RELEASE-p1 FreeBSD 12.1-RELEASE-p1 GENERIC amd64`
#### Reproduce
1. Set the following options, as an example, in `/etc/ssh/sshd_config`:
```
PasswordAuthentication=no
MaxAuthTries=2
```
2. Restart `sshd`
3. Connect with:
```
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no [system]
```Shawn WebbShawn Webbhttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/9Support filesystem extended attributes in tmpfs2023-09-19T00:01:32ZShawn WebbSupport filesystem extended attributes in tmpfsWe use filesystem extended attributes to toggle exploit mitigations. Poudriere uses tmpfs when building packages. In order to support the integration of HardenedBSD's exploit mitigation toggling with the ports tree, extended attribute su...We use filesystem extended attributes to toggle exploit mitigations. Poudriere uses tmpfs when building packages. In order to support the integration of HardenedBSD's exploit mitigation toggling with the ports tree, extended attribute support needs to be added to tmpfs.Shawn WebbShawn Webbhttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/8[CURRENT] SDDM and Plasma are crashed somewhy2023-09-19T00:01:32ZShawn Webb[CURRENT] SDDM and Plasma are crashed somewhy*Created by: hd_scania*
Hardware info
```
ABI: 12.1
KDE Plasma: Latest 5.18.4
ASUS K43SJ
NVidia GT520M with 390 driver working
Intel i3-2330 4 cores
15.6GiB RAM’s
931GiB Samsung SATA SSD’s
```
`sysctl.conf`
```
security.bsd.see_othe...*Created by: hd_scania*
Hardware info
```
ABI: 12.1
KDE Plasma: Latest 5.18.4
ASUS K43SJ
NVidia GT520M with 390 driver working
Intel i3-2330 4 cores
15.6GiB RAM’s
931GiB Samsung SATA SSD’s
```
`sysctl.conf`
```
security.bsd.see_other_uids=0
kern.geom.debugflags=16
hardening.pax.aslr.status=3
hardening.pax.pageexec.status=3
hardening.pax.mprotect.status=1
vfs.usermount=1
net.inet.ip.random_id=1
net.inet6.ip6.use_deprecated=0
net.inet6.ip6.use_tempaddr=1
net.inet6.ip6.prefer_tempaddr=1
security.bsd.see_other_gids=0
security.bsd.hardlink_check_gid=1
security.bsd.hardlink_check_uid=1
security.bsd.stack_guard_page=1
security.bsd.unprivileged_proc_debug=0
security.bsd.unprivileged_read_msgbuf=0
net.local.stream.recvspace=65536
net.local.stream.sendspace=65536
kern.msgbuf_show_timestamp=1
```
`dmesg` excerpts
```
[118] pid 51783 (falkon), jid 0, uid 1000: exited on signal 6 (core dumped)
[238] coretemp0: critical temperature detected, suggest system shutdown
[250] pid 96897 (efreetd), jid 0, uid 1000: exited on signal 6 (core dumped)
[254] pid 24323 (efreetd), jid 0, uid 1000: exited on signal 6 (core dumped)
[259] pid 89963 (efreetd), jid 0, uid 1000: exited on signal 6 (core dumped)
[265] pid 87346 (efreetd), jid 0, uid 1000: exited on signal 6 (core dumped)
[270] pid 33252 (efreetd), jid 0, uid 1000: exited on signal 6 (core dumped)
[276] pid 57555 (efreetd), jid 0, uid 1000: exited on signal 6 (core dumped)
[281] pid 48515 (efreetd), jid 0, uid 1000: exited on signal 6 (core dumped)
[3608] pid 59414 (vlc), jid 0, uid 1000: exited on signal 11 (core dumped)
[3921] pid 60165 (falkon), jid 0, uid 1000: exited on signal 6 (core dumped)
[5343] [HBSD INTERNAL] the process started with non-default hardening settings
[5343] -> fname: /bin/kenv
[5343] -> pid: 37081 ppid: 39 p_pax: 0x559<PAGEEXEC,NOMPROTECT,SEGVGUARD,ASLR,SHLIBRANDOM,DISALLOWMAP32BIT>
[5343] [HBSD INTERNAL] the process started with non-default hardening settings
[5343] -> fname: /bin/kenv
[5343] -> pid: 39 ppid: 91775 p_pax: 0x559<PAGEEXEC,NOMPROTECT,SEGVGUARD,ASLR,SHLIBRANDOM,DISALLOWMAP32BIT>
[5343] [HBSD INTERNAL] the process started with non-default hardening settings
[5343] -> fname: /bin/kenv
[5343] -> pid: 53676 ppid: 91775 p_pax: 0x559<PAGEEXEC,NOMPROTECT,SEGVGUARD,ASLR,SHLIBRANDOM,DISALLOWMAP32BIT>
[5741] pid 14137 (falkon), jid 0, uid 1000: exited on signal 6 (core dumped)
[6104] ugen1.4: <SAMSUNG SAMSUNGAndroid> at usbus1 (disconnected)
[27] pid 19508 (sddm-greeter), jid 0, uid 219: exited on signal 11 (core dumped)
[63] pid 85823 (python3.7), jid 0, uid 1000: exited on signal 11 (core dumped)
[63] pid 43912 (plasmashell), jid 0, uid 1000: exited on signal 11 (core dumped)
[64] pid 37 (klauncher), jid 0, uid 1000: exited on signal 6 (core dumped)
[65] pid 39156 (kwin_x11), jid 0, uid 1000: exited on signal 10 (core dumped)
[93] sonewconn: pcb 0xfffff80007b94b00 (local:/tmp/xdg-X3cm5n/.ecore/efreetd/0): Listen queue overflow: 1 already in queue awaiting acceptance (1 occurrences)
[94] sonewconn: pcb 0xfffff80007b36000 (local:/tmp/xdg-X3cm5n/.ecore/efreetd/0): Listen queue overflow: 1 already in queue awaiting acceptance (1 occurrences)
[95] sonewconn: pcb 0xfffff800078fd200 (local:/tmp/xdg-X3cm5n/.ecore/efreetd/0): Listen queue overflow: 1 already in queue awaiting acceptance (1 occurrences)
[96] sonewconn: pcb 0xfffff80007bad500 (local:/tmp/xdg-X3cm5n/.ecore/efreetd/0): Listen queue overflow: 1 already in queue awaiting acceptance (1 occurrences)
[97] sonewconn: pcb 0xfffff80007bc6600 (local:/tmp/xdg-X3cm5n/.ecore/efreetd/0): Listen queue overflow: 1 already in queue awaiting acceptance (1 occurrences)
[97] sonewconn: pcb 0xfffff80007b61700 (local:/tmp/xdg-X3cm5n/.ecore/efreetd/0): Listen queue overflow: 1 already in queue awaiting acceptance (1 occurrences)
[118] pid 51783 (falkon), jid 0, uid 1000: exited on signal 6 (core dumped)
[238] coretemp0: critical temperature detected, suggest system shutdown
[250] pid 96897 (efreetd), jid 0, uid 1000: exited on signal 6 (core dumped)
[254] pid 24323 (efreetd), jid 0, uid 1000: exited on signal 6 (core dumped)
[259] pid 89963 (efreetd), jid 0, uid 1000: exited on signal 6 (core dumped)
[265] pid 87346 (efreetd), jid 0, uid 1000: exited on signal 6 (core dumped)
[270] pid 33252 (efreetd), jid 0, uid 1000: exited on signal 6 (core dumped)
[276] pid 57555 (efreetd), jid 0, uid 1000: exited on signal 6 (core dumped)
[281] pid 48515 (efreetd), jid 0, uid 1000: exited on signal 6 (core dumped)
[1213] ath0: bb hang detected (0x4), resetting
[1953] ath0: bb hang detected (0x4), resetting
[1964] ath0: bb hang detected (0x4), resetting
[2054] ath0: bb hang detected (0x4), resetting
[3608] pid 59414 (vlc), jid 0, uid 1000: exited on signal 11 (core dumped)
[3921] pid 60165 (falkon), jid 0, uid 1000: exited on signal 6 (core dumped)[21165] [HBSD INTERNAL] the process started with non-default hardening settings
[21165] -> fname: /bin/kenv
[21165] -> pid: 51820 ppid: 60987 p_pax: 0x559<PAGEEXEC,NOMPROTECT,SEGVGUARD,ASLR,SHLIBRANDOM,DISALLOWMAP32BIT>
[21169] pid 7881 (plasmashell), jid 0, uid 1000: exited on signal 11 (core dumped)
[21170] Failed to fully fault in a core file segment at VA 0x47d22a00000 with size 0x4000000000 to be written at offset 0x33ee000 for process baloo_file
[21171] pid 12700 (python3.7), jid 0, uid 1000: exited on signal 11 (core dumped)
[21171] pid 71107 (baloo_file), jid 0, uid 1000: exited on signal 6 (core dumped)
[21173] pid 81657 (kwin_x11), jid 0, uid 1000: exited on signal 10 (core dumped)
[21174] pid 59054 (klauncher), jid 0, uid 1000: exited on signal 6 (core dumped)
[21188] sonewconn: pcb 0xfffff800078fd600 (local:/tmp/xdg-vdgqI0/.ecore/efreetd/0): Listen queue overflow: 1 already in queue awaiting acceptance (1 occurrences)
[21189] sonewconn: pcb 0xfffff803c47b2b00 (local:/tmp/xdg-vdgqI0/.ecore/efreetd/0): Listen queue overflow: 1 already in queue awaiting acceptance (1 occurrences)
[21189] sonewconn: pcb 0xfffff80155ba5d00 (local:/tmp/xdg-vdgqI0/.ecore/efreetd/0): Listen queue overflow: 1 already in queue awaiting acceptance (1 occurrences)
[21190] sonewconn: pcb 0xfffff803c47b2c00 (local:/tmp/xdg-vdgqI0/.ecore/efreetd/0): Listen queue overflow: 1 already in queue awaiting acceptance (1 occurrences)
[21191] sonewconn: pcb 0xfffff80007bb8c00 (local:/tmp/xdg-vdgqI0/.ecore/efreetd/0): Listen queue overflow: 1 already in queue awaiting acceptance (1 occurrences)
[21192] sonewconn: pcb 0xfffff803c480c800 (local:/tmp/xdg-vdgqI0/.ecore/efreetd/0): Listen queue overflow: 1 already in queue awaiting acceptance (1 occurrences)
```Shawn WebbShawn Webbhttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/7Remove support for building i3862023-09-19T00:01:32ZShawn WebbRemove support for building i386HardenedBSD is disinterested in supporting 32-bit architectures, especially i386. Since we don't actively provide support for i386, remove the ability to build for that architecture.HardenedBSD is disinterested in supporting 32-bit architectures, especially i386. Since we don't actively provide support for i386, remove the ability to build for that architecture.Shawn WebbShawn Webbhttps://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/5[Syncing from CURRENT] Making installworld is always dead on ld-elf somewhy2023-07-28T12:01:28ZShawn Webb[Syncing from CURRENT] Making installworld is always dead on ld-elf somewhy*Created by: hd_scania*
My scripts are on: https://sf.net/p/hbsd-current-desktop/projects
Please look at `make.world.sh` OR `make.world.from.FreeBSD.sh` OR `installworld.sh` then tell me wtf WERE going wrong from my those scripts😄
*Created by: hd_scania*
My scripts are on: https://sf.net/p/hbsd-current-desktop/projects
Please look at `make.world.sh` OR `make.world.from.FreeBSD.sh` OR `installworld.sh` then tell me wtf WERE going wrong from my those scripts😄
https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/issues/4[Coreboot] memstick.img not booting2023-07-28T12:01:28ZShawn Webb[Coreboot] memstick.img not booting*Created by: bob12*
Hi,
I tried to install HardenedBSD on a Corebooted machine (using SeaBIOS payload) and it seems that the installer just won't boot at all. With the 12.x version of the installer hangs just after '/boot/entropy size=...*Created by: bob12*
Hi,
I tried to install HardenedBSD on a Corebooted machine (using SeaBIOS payload) and it seems that the installer just won't boot at all. With the 12.x version of the installer hangs just after '/boot/entropy size=0x1000', and with the 11.x version it hangs after 'Booting...'.
I tried to disable ACPI and enable Verbose in boot options, with similar result.
Windows, Linux, and OpenBSD boot just fine on this machine.
Does someone have an idea on how to fix this ?
Thank youShawn WebbShawn Webb