Re: All my Rust programs stop working on OpenBSD 7.3
Thanks. I believe that is the reason. > On Apr 11, 2023, at 02:54, Theo Buehler wrote: > > >> >> Thanks. Actually that’s what I did. Rust package was updated by >> “pkg_add -u rust” and then “cargo build —release” rebuilds the >> projects. However, when I ran it, it crashed because of segment fault. >> It no longer passes the tests as well, “invalid memory reference” was >> returned. > > Without seeing a backtrace it is difficult to tell. > > Another issue could be that you use things depending on the ring crate > whose assembly isn't compatible with the new x-only protection on modern > amd64 machines. > > If so, you will need to > > # pkg_add rust-ring > > and replace lines like this > > ring = "^0.16" > > with something like this in Cargo.toml: > > [dependencies.ring] > version = "^0.16" > path = "/usr/local/share/ring-0.16.20"
OpenBSD 7.3 on Parallels 18 (M1)
To whom it may concern; after writing the arm64 install73.img to a USB stick and booting from this, 7.3 boots and can run (at least in a tty-environment, which I am interested in) on Parallels 18 on a macOS M1 machine. One thing to note, however: boot> set tty fb0 Or it will boot to a black screen (so write this to /etc/boot.conf after install). Kind regards + thanks, Tor Houghton
Re: All my Rust programs stop working on OpenBSD 7.3
> Thanks. Actually that’s what I did. Rust package was updated by > “pkg_add -u rust” and then “cargo build —release” rebuilds the > projects. However, when I ran it, it crashed because of segment fault. > It no longer passes the tests as well, “invalid memory reference” was > returned. Without seeing a backtrace it is difficult to tell. Another issue could be that you use things depending on the ring crate whose assembly isn't compatible with the new x-only protection on modern amd64 machines. If so, you will need to # pkg_add rust-ring and replace lines like this ring = "^0.16" with something like this in Cargo.toml: [dependencies.ring] version = "^0.16" path = "/usr/local/share/ring-0.16.20"
Re: dns priority from different network connections - or disabling?
On 4/10/23 16:24, Daniele B. wrote: Apr 10, 2023 12:52:22 Kaya Saman : how do I override OpenBSD's behavior to explicitly not use the dns servers obtained through ipcp but instead use the ones form the resolv.conf file? My solution both for security reasons (I'm using unbound) for for practical reasons (as per your concerns) is to set immutable resolv.conf by chflags. Not the Solution but a very good workaround. Please investigate also when you can take off the immutable flag too. I take this time to wish you all an Happy Easter and obviously lots of compliments for the 54th release of the ball fish system! Do you mean setting resolv.conf as ReadOnly? My resolv.conf file is fine and has the correct dns servers inside. The issue is that pppoe negotiates the dns servers through ipcp. The dns servers therefor do *not* get loaded into the resolv.conf file but instead show up under: ifconfig pppoe0 This somehow is overriding my resolv.conf file; another words the information is *not* being used from resolv.conf and is instead being used from the ipcp negotiation as part of the pppoe kernel module. The question is how to disable this behavior?
Re: All my Rust programs stop working on OpenBSD 7.3
Thanks. Actually that’s what I did. Rust package was updated by “pkg_add -u rust” and then “cargo build —release” rebuilds the projects. However, when I ran it, it crashed because of segment fault. It no longer passes the tests as well, “invalid memory reference” was returned. > On Apr 11, 2023, at 00:09, Sebastien Marie wrote: > > On Mon, Apr 10, 2023 at 11:49:50PM +0800, Siegfried Levin wrote: >> After I upgraded my OS from 7.2 to 7.3 with sysupgrade like 8 hours ago, all >> my programs written in Rust broke, including cargo installed with pkg_add on >> 7.2. I fixed Cargo by “pkg_add -u rust” and then recompiled some of my >> projects. Now they are having segment faults. Does anyone having the same >> error? > > you need to rebuild your locally built programs with rustc from 7.3. > > first, upgrade rustc/cargo with pkg_add -u, and next rebuild your programs as > usually, that's all. > > for the long story: 7.3 comes with immutable stack, but old rust programs are > modifying it (so the kernel kills your programs). > > the updated package has the required changes in rust std library. but you > will > need to rebuild your programs to make them to use the updated code (the > faulty > code is in rust std which is statically linked in all programs). > > Thanks. > -- > Sebastien Marie
Re: All my Rust programs stop working on OpenBSD 7.3
On Mon, Apr 10, 2023 at 06:21:03PM +0200, Martin Schröder wrote: > Am Mo., 10. Apr. 2023 um 18:10 Uhr schrieb Sebastien Marie > : > > On Mon, Apr 10, 2023 at 11:49:50PM +0800, Siegfried Levin wrote: > > > After I upgraded my OS from 7.2 to 7.3 with sysupgrade like 8 hours ago, > > > all my programs written in Rust broke, including cargo installed with > > > pkg_add on 7.2. I fixed Cargo by “pkg_add -u rust” and then recompiled > > > some of my projects. Now they are having segment faults. Does anyone > > > having the same error? > > > > you need to rebuild your locally built programs with rustc from 7.3. > > Sounds like something the upgrade guide should mention... maybe. but as OpenBSD doesn't promise ABI compatibility between releases, it is also expected to rebuild any local programs to match the new ABI. it isn't specific to Rust programs. -- Sebastien Marie
Re: All my Rust programs stop working on OpenBSD 7.3
Am Mo., 10. Apr. 2023 um 18:10 Uhr schrieb Sebastien Marie : > On Mon, Apr 10, 2023 at 11:49:50PM +0800, Siegfried Levin wrote: > > After I upgraded my OS from 7.2 to 7.3 with sysupgrade like 8 hours ago, > > all my programs written in Rust broke, including cargo installed with > > pkg_add on 7.2. I fixed Cargo by “pkg_add -u rust” and then recompiled some > > of my projects. Now they are having segment faults. Does anyone having the > > same error? > > you need to rebuild your locally built programs with rustc from 7.3. Sounds like something the upgrade guide should mention... Best Martin
Re: All my Rust programs stop working on OpenBSD 7.3
On Mon, Apr 10, 2023 at 11:49:50PM +0800, Siegfried Levin wrote: > After I upgraded my OS from 7.2 to 7.3 with sysupgrade like 8 hours ago, all > my programs written in Rust broke, including cargo installed with pkg_add on > 7.2. I fixed Cargo by “pkg_add -u rust” and then recompiled some of my > projects. Now they are having segment faults. Does anyone having the same > error? you need to rebuild your locally built programs with rustc from 7.3. first, upgrade rustc/cargo with pkg_add -u, and next rebuild your programs as usually, that's all. for the long story: 7.3 comes with immutable stack, but old rust programs are modifying it (so the kernel kills your programs). the updated package has the required changes in rust std library. but you will need to rebuild your programs to make them to use the updated code (the faulty code is in rust std which is statically linked in all programs). Thanks. -- Sebastien Marie
All my Rust programs stop working on OpenBSD 7.3
After I upgraded my OS from 7.2 to 7.3 with sysupgrade like 8 hours ago, all my programs written in Rust broke, including cargo installed with pkg_add on 7.2. I fixed Cargo by “pkg_add -u rust” and then recompiled some of my projects. Now they are having segment faults. Does anyone having the same error? PS: just realized I upgraded to 7.3 before it was officially announced 3 hours ago. Could that cause any issues?
Re: dns priority from different network connections - or disabling?
Apr 10, 2023 12:52:22 Kaya Saman : >>> how do I override OpenBSD's >>> behavior to explicitly not use the dns servers obtained through ipcp but >>> instead use the ones form the resolv.conf file? My solution both for security reasons (I'm using unbound) for for practical reasons (as per your concerns) is to set immutable resolv.conf by chflags. Not the Solution but a very good workaround. Please investigate also when you can take off the immutable flag too. I take this time to wish you all an Happy Easter and obviously lots of compliments for the 54th release of the ball fish system!
PF: Redirect SOCKS connections to another server on a different net
On an OpenBSD 7.2 system, I have access to a SOCKS proxy server through VPN. After the VPN connection is established, any program that supports SOCKS proxy can reach it by setting the relevant local VPN address, 10.64.0.1, and the usual port number 1080. I want to share the access to this proxy server on my OpenBSD machine with other systems in my home network. So basically what I want is to open a 1080 port on the OpenBSD server and redirect it to the local VPN address 10.64.0.1. I have been successful in doing so with the help of the "socat" program: $ socat tcp-listen:1080,bind=192.168.1.10,reuseaddr,fork \ tcp:10.64.0.1:1080 I would very much like to replace the above command with pf rule(s). All the combinations I tried with "rdr-to", "nat-to", "divert-to", "synproxy state", etc. did not work. Could someone kindly point me in the right direction (pun intended)? Below is an illustration of my setup and the desired forwarding. ,--- OpenBSD system . VPN | | / \ ,--+-.,+. .---. | re0|| wg0:| | 10.64.0.1 | | 192.168.1.0/24 || 10.76.150.11/32 |-| | :1080<===>:1080 | `--+-'`+' `---' | | `---' Cheers, Charlie
OpenBSD 7.3 released
- OpenBSD 7.3 RELEASED -
April 10, 2023.
We are pleased to announce the official release of OpenBSD 7.3.
This is our 54th release. We remain proud of OpenBSD's record of more
than twenty years with only two remote holes in the default install.
As in our previous releases, 7.3 provides significant improvements,
including new features, in nearly all areas of the system:
- Various kernel improvements:
o Added waitid(2), wait for process state change.
o Added pinsyscall(2), specify the call stub for a specific system
call.
o Added getthrname(2) and setthrname(2), get or set thread name.
o Added WTRAPPED option for waitid(2) to control whether CLD_TRAPPED
state changes, i.e., ptrace(2) on a process, are reported.
o Introduced clockintr(9), a machine-independent clock interrupt
scheduler. Switched all architectures to use this new kernel
subsystem.
o Added a priority queue to clockintr(9).
o Introduced a new kern.autoconf_serial sysctl(8) that can be used
by userland to monitor state changes of the kernel device tree.
o Fixed pmap(9) bugs involving entering an executable mapping for a
page before synchronizing the data and instruction cache on arm64
and riscv64.
o Removed copystr(9) from public API.
o Add getnsecruntime(9) to the kernel timecounting API. Together
with getbinruntime(), it provides a fast, monotonic clock that
only advances while the system is not suspended.
o Add detection for Spectre-BHB Branch History Injection
vulnerability related CLRBHB, ECBHB and CSV2_3/HCXT feature bits.
o Prevent detaching ("bioctl -d detach") of a boot volume on a RAID
managed by bioctl(8).
o On arm64, avoid using 1GB mappings for the identity map in the
early kernel bootstrap phase and when booting the secondary CPUs.
This avoids accidentally mapping memory regions that should not be
mapped (i.e. secure memory) as all mapped memory can be accessed
speculatively.
o Added arm64 detection of EPAN feature bit. Enhanced Privileged
Access Never (EPAN) allows Privileged Access Never to be used with
Execute-only mappings.
o On arm64, add a machdep.lidaction sysctl(8) for aplsmc(4) Apple
Silicon laptops.
The arm64 default for the machdep.lidaction is 1, making the
system suspend when the lid is closed. aplsmc(4) provides support
for the lid position sensor.
o Changed arm64 suspend idle loop from WFE to WFI, avoiding spurious
wakeups while other CPUs are still active.
o Added new dt(4) tracing ioctl DTIOCARGS to get the type of probe
arguments.
- SMP Improvements
o Unlocked mmap(2), munmap(2), and mprotect(2).
o Unlocked sched_yield(2).
o Added support for per-cpu event counters, to be used for clock and
IPI counters where the event counted occurs across all CPUs in the
system.
o Moved pf(4) purge tasks out from under the kernel lock.
o Unlocked ioctl(2) SIOCGIFCONF, SIOCGIFGMEMB, SIOCGIFGATTR, and
SIOCGIFGLIST.
o Protected interface tables in pf(4) with PF_LOCK(), allowing
removal of NET_LOCK() protection from the ioctl(2) code path in
pf.
o Unlocked getsockopt(2) and setsockopt(2).
o Completed removing kernel lock from IPv6 read ioctls.
o Unlocked minherit(2).
o Made tun(4) and tap(4) event filters MP-safe.
o Unlocked utrace(2).
o Stopped holding the vm_map lock while flushing pages in msync(2)
and madvise(2). Prevents a 3-thread deadlock between msync(2),
page-fault and mmap(2).
o Unlocked select(2), pselect(2), poll(2), and ppoll(2).
- Direct Rendering Manager and graphics drivers
o Updated drm(4) to Linux 6.1.15
o amdgpu(4): Added support for Ryzen 7000 "Raphael", Ryzen 7020
series "Mendocino", Ryzen 7045 series "Dragon Range", Radeon RX
7900 XT/XTX "Navi 31", Radeon RX 7600M (XT), 7700S, and 7600S
"Navi 33."
o Fixed frame buffer corruption and additional bugs after wakeup on
Apple Silicon laptops and the Lenovo x13s.
o Added support for the backlight connector property to amdgpu(4) as
in inteldrm(4), making xbacklight(1) work when using the Xorg
modesetting driver.
- VMM/VMD improvements
o Updated vmm(4) to allow guests to read MSR_HWCR and MSR_PSTATEDEF,
which is necessary to determine the TSC frequency on AMD families
17h and 19h.
o Allocated reference for vm and vcpu SLISTs in vmm(4), keeping vmm
from triggering excessive wakeup calls while iterating through the
list of vms while servicing an ioctl(2).
o Set vmm(4) RAX guest register state based on VMCB.
o Removed locking in vmm(4) vmm_intr_pending, reducing slowdowns due
to requests for a lock held while the VM is running.
o Increased speed
Re: dns priority from different network connections - or disabling?
On 4/10/23 11:40, Jonathan Gray wrote: On Mon, Apr 10, 2023 at 11:26:22AM +0100, Kaya Saman wrote: Hi, I'll ask the second question first as it might be easier to implement... Currently I have found that the dns servers specified in the resolv.conf file are not being used. Instead my machine is prioritizing the ISP obtained servers from the ipcp protocol through the kernel ppp service. Within the hostname.pppoe(x) file is there a way to disable the dns portion of the negotiation? If not, then this leads to my second question of how do I override OpenBSD's behavior to explicitly not use the dns servers obtained through ipcp but instead use the ones form the resolv.conf file? in /etc/rc.conf.local resolvd_flags=NO Ok strange! This is already set and before emailing I checked that the resolvd, unbound, unwind, and even nsd services were not running using 'ps'. Just attempted to stop resolvd using: /etc/rc.d/resolvd stop (incase it was running and I missed something) , it said "OK". nslookup still shows the dns servers from ipcp and not the locally defined ones in resolv.conf I'm not sure when the behavior changed but it is a recent thing either done by an update or by adding my secondary ISP. Right now my system can't send emails because it's using the wrong dns. changed in sys/net/if_spppsubr.c rev 1.188 first release with that was OpenBSD 7.1 No no this odd behavior started recently?? I'm on: 7.3 GENERIC.MP#1125 amd64 Maybe I ran: sh /etc/netstart pppoe0 which decided to override the resolv.conf file, I really am not sure but still...
Re: dns priority from different network connections - or disabling?
On Mon, Apr 10, 2023 at 11:26:22AM +0100, Kaya Saman wrote: > Hi, > > > I'll ask the second question first as it might be easier to implement... > > > Currently I have found that the dns servers specified in the resolv.conf > file are not being used. Instead my machine is prioritizing the ISP obtained > servers from the ipcp protocol through the kernel ppp service. Within the > hostname.pppoe(x) file is there a way to disable the dns portion of the > negotiation? > > > If not, then this leads to my second question of how do I override OpenBSD's > behavior to explicitly not use the dns servers obtained through ipcp but > instead use the ones form the resolv.conf file? > in /etc/rc.conf.local resolvd_flags=NO > > I'm not sure when the behavior changed but it is a recent thing either done > by an update or by adding my secondary ISP. Right now my system can't send > emails because it's using the wrong dns. changed in sys/net/if_spppsubr.c rev 1.188 first release with that was OpenBSD 7.1
dns priority from different network connections - or disabling?
Hi, I'll ask the second question first as it might be easier to implement... Currently I have found that the dns servers specified in the resolv.conf file are not being used. Instead my machine is prioritizing the ISP obtained servers from the ipcp protocol through the kernel ppp service. Within the hostname.pppoe(x) file is there a way to disable the dns portion of the negotiation? If not, then this leads to my second question of how do I override OpenBSD's behavior to explicitly not use the dns servers obtained through ipcp but instead use the ones form the resolv.conf file? I'm not sure when the behavior changed but it is a recent thing either done by an update or by adding my secondary ISP. Right now my system can't send emails because it's using the wrong dns. Thanks for any ideas. Kaya
