em(4) vlan tagging support for 82576
Hi all, I have quad-port Intel ET2 NIC based on 82576[1] controller. The manual says that hardware VLAN tagging should be supported but ifconfig output shows VLAN_MTU only in hwfeatures on OpenBSD 7.0. How do I check if 802.1Q tagging is offloaded or not? And if it's not - does it matter at 1Gbps speeds on 3 Ghz CPU? $ dmesg | grep em0 em0 at pci11 dev 0 function 0 "Intel 82576" rev 0x01: msi, address 90:e2:ba:84:64:14 $ ifconfig em0 hwfeatures em0: flags=808843 mtu 1500 hwfeatures=10 hardmtu 9216 lladdr 90:e2:ba:84:64:14 index 1 priority 0 llprio 3 media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause) status: active inet 192.168.0.143 netmask 0xff00 broadcast 192.168.0.255 [1] https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/gigabit-et-et2-ef-multi-port-server-adapters-brief.pdf Thanks, Yury.
Re: Xserver 21.1 mode selection fixes
On Sun, Dec 05, 2021 at 10:28:53PM +0100, Matthieu Herrb wrote: > Hi, > > steven@ reported that, using xf68-video-nv X server 21.1 is dumping > core on startup. > > The following patch fixes it. While here I also fixed another bug on > drivers that don't intialize a private structure. > > If you're using one older graphics card (ie not inteldrm or radeondrm > based), please test. > > These are also: > https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/807 > and https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/808 > > ok ? > > Index: hw/xfree86/modes/xf86Crtc.h > === > RCS file: /cvs/OpenBSD/xenocara/xserver/hw/xfree86/modes/xf86Crtc.h,v > retrieving revision 1.15 > diff -u -p -u -r1.15 xf86Crtc.h > --- hw/xfree86/modes/xf86Crtc.h 11 Nov 2021 09:10:04 - 1.15 > +++ hw/xfree86/modes/xf86Crtc.h 4 Dec 2021 17:50:33 - > @@ -837,11 +837,11 @@ extern _X_EXPORT int xf86CrtcConfigPriva > static _X_INLINE xf86OutputPtr > xf86CompatOutput(ScrnInfoPtr pScrn) > { > -xf86CrtcConfigPtr config = XF86_CRTC_CONFIG_PTR(pScrn); > +xf86CrtcConfigPtr config; > > if (xf86CrtcConfigPrivateIndex == -1) > -return NULL; > - > +return NULL; this introduces whitespace at eol with that fixed ok jsg@ for both changes > +config = XF86_CRTC_CONFIG_PTR(pScrn); > if (config->compat_output < 0) > return NULL; > return config->output[config->compat_output]; > Index: hw/xfree86/modes/xf86Modes.c > === > RCS file: /cvs/OpenBSD/xenocara/xserver/hw/xfree86/modes/xf86Modes.c,v > retrieving revision 1.12 > diff -u -p -u -r1.12 xf86Modes.c > --- hw/xfree86/modes/xf86Modes.c 11 Nov 2021 09:03:08 - 1.12 > +++ hw/xfree86/modes/xf86Modes.c 5 Dec 2021 18:20:52 - > @@ -803,10 +803,14 @@ xf86CVTMode(int HDisplay, int VDisplay, > { > struct libxcvt_mode_info *libxcvt_mode_info; > DisplayModeRec *Mode = xnfcalloc(1, sizeof(DisplayModeRec)); > +char *tmp; > > libxcvt_mode_info = > libxcvt_gen_mode_info(HDisplay, VDisplay, VRefresh, Reduced, > Interlaced); > > +XNFasprintf(&tmp, "%dx%d", HDisplay, VDisplay); > +Mode->name = tmp; > + > Mode->VDisplay = libxcvt_mode_info->vdisplay; > Mode->HDisplay = libxcvt_mode_info->hdisplay; > Mode->Clock = libxcvt_mode_info->dot_clock; > > -- > Matthieu Herrb > >
kbind(2): push kernel lock down as needed
Two things in sys_kbind() need an explicit kernel lock. First, sigexit(). Second, uvm_map_extract(), because the following call chain panics without it: panic assert uvn_reference uvm_mapent_clone uum_map_extract sys_kbind syscall Xsyscall uvn_reference() does KERNEL_ASSERT_LOCKED(). These are the other routines called from sys_kbind(): copyin kcopy trunc_page vm_map_lock vm_map_unlock uvm_unmap_detach uvm_unmap_remove copyin/kcopy are safe, trunc_page is safe, vm_map_lock/vm_map_unlock are safe, uvm_unmap_detach takes the kernel lock as needed, and uvm_unmap_remove has callees that take the kernel lock as needed. With this committed we can unlock kbind(2). Thoughts? ok? Index: uvm_mmap.c === RCS file: /cvs/src/sys/uvm/uvm_mmap.c,v retrieving revision 1.165 diff -u -p -r1.165 uvm_mmap.c --- uvm_mmap.c 5 Dec 2021 22:00:42 - 1.165 +++ uvm_mmap.c 5 Dec 2021 23:57:28 - @@ -1112,10 +1112,12 @@ sys_kbind(struct proc *p, void *v, regis if (pr->ps_kbind_addr == 0) { pr->ps_kbind_addr = pc; pr->ps_kbind_cookie = SCARG(uap, proc_cookie); - } else if (pc != pr->ps_kbind_addr || pc == BOGO_PC) - sigexit(p, SIGILL); - else if (pr->ps_kbind_cookie != SCARG(uap, proc_cookie)) + } else if (pc != pr->ps_kbind_addr || pc == BOGO_PC || + pr->ps_kbind_cookie != SCARG(uap, proc_cookie)) { + KERNEL_LOCK(); sigexit(p, SIGILL); + } + if (psize < sizeof(struct __kbind) || psize > sizeof(param)) return EINVAL; if ((error = copyin(paramp, ¶m, psize))) @@ -1169,8 +1171,11 @@ sys_kbind(struct proc *p, void *v, regis vm_map_unlock(kernel_map); kva = 0; } - if ((error = uvm_map_extract(&p->p_vmspace->vm_map, - baseva, PAGE_SIZE, &kva, UVM_EXTRACT_FIXPROT))) + KERNEL_LOCK(); + error = uvm_map_extract(&p->p_vmspace->vm_map, + baseva, PAGE_SIZE, &kva, UVM_EXTRACT_FIXPROT); + KERNEL_UNLOCK(); + if (error) break; last_baseva = baseva; }
Re: sppp(4)/pppoe(4) - avoid endless loop in remote ip negotiation
On 2021/12/04 15:32, Krzysztof Kanas wrote: > I tried the settings: > > inet 0.0.0.0 255.255.255.255 0.0.0.1 \ > pppoedev em0 authproto chap \ > authname 'testcaller' authkey 'secret' up > !/sbin/route add default -ifp pppoe0 0.0.0.1 > > But that didn't fixed my ICPC negotiation problem. > > If I changed first line to (use bougs remote IP) > inet 0.0.0.0 255.255.255.255 10.64.64.33 \ > ... > > Then it works around IPCP problem, but now routing becomes problem as > !/sbin/route add default -ifp pppoe0 0.0.0.1 > > So > > inet 0.0.0.0 255.255.255.255 10.64.64.33 \ > pppoedev em0 authproto chap \ > authname 'testcaller' authkey 'secret' up > !/sbin/route add default -ifp pppoe0 10.64.64.33 > > Seems to be working. > > I will test it more, but does this sound correct ? > And if so then is it worth while to add this to man page to bugs section > ? This is expected, with the current routing table code, even with -ifp set to a point-to-point interface, the route can only be added if the route destination matches the remote address on the interface at the time. "0.0.0.1" can only be added as a route while the remote address is set to the 0.0.0.1 'magic' value. So, there's another race condition here, if the interface comes up quickly and IPCP completes before the route command is executed, the route won't be added. In practice I haven't hit this when the whole thing is run from netstart, but when commands are entered by hand you usually need to check and use the actual address. And of course if you configure a value other than 0.0.0.1, you need to use that value in the route instead. So, while it's a bit annoying, and worse than the older route table code, I do think it's working as expected i.e. not a bug.
Re: sppp(4)/pppoe(4) - avoid endless loop in remote ip negotiation
On 2021-12-02 13:17, Mikolaj Kucharski wrote: > On Fri, Nov 26, 2021 at 01:35:14PM +0100, Krzysztof Kanas wrote: > > Hi. When remote side in sppp doesn't reply for to PPP IPCP IP-Address > > sppp will try to negotiate remote IP in endless loop. Instead use > > 10.64.64.1 + if_index as remote IP. > > > > Okay, but why it doesn't reply? I don't use anymore PPPoE, as none > of the machines connected to the internet use that mechanism, but > from my very old backups I see I used in the past: I don't know. This is ISP controlled device. To make insult worse it used to work with OpenBSD pppoe (no custom kernel), until it stopped (maybe ISP didn't want to present device IP to the client ?). I had to learn why it stopped and then I found out about Bug in sppp regarding remote IPCP negotiation endless loop. > > # /etc/hostname.pppoe0 > inet 0.0.0.0 255.255.255.255 NONE pppoedev vr0 authproto chap \ > authname 'some-customer-id-here' authkey 'secret-key' \ > description "pppoe uplink" up > dest 0.0.0.1 > !route -nq add default -ifp \$if 0.0.0.1 So with in another reply I found out that I can set remote IP to pppoe and it seems to be working. Here is my working for now config for /etc/hostname.pppoe0 inet 0.0.0.0 255.255.255.255 10.64.64.33 \ pppoedev em0 authproto chap \ authname 'testcaller' authkey 'secret' up !/sbin/route add default -ifp pppoe0 10.64.64.33 This allows me to assign bogus IP for ISP pppoe device (10.64.64.33) and default routing rule so I can forward packets. Although the remote IP is bogus so packets with IP dest 10.64.64.33 won't be replied by ISP pppoe device, but I don't have need for that. I just need to forward my packets to the internet. > > I don't remember any issues with above setup and that OpenBSD > machine was running -current and was rebooted many times during > its 6+ years of service. Also machine faced many power outages > and on a fresh bootup I don't remember it not able to connect, > that I needed to run a custom kernel or do some extensive > troubleshooting. I had good run like 2 years without any issue. Then all of the sudden I had to debug this issue. > > Looking again at pppoe(4) manual page I copied above config > directly from there. > > What problem are you trying to solve here is not clear to me. Hope it makes more sense now. Thanks for the help. -- -- Best Regards Krzysztof Kanas
Xserver 21.1 mode selection fixes
Hi, steven@ reported that, using xf68-video-nv X server 21.1 is dumping core on startup. The following patch fixes it. While here I also fixed another bug on drivers that don't intialize a private structure. If you're using one older graphics card (ie not inteldrm or radeondrm based), please test. These are also: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/807 and https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/808 ok ? Index: hw/xfree86/modes/xf86Crtc.h === RCS file: /cvs/OpenBSD/xenocara/xserver/hw/xfree86/modes/xf86Crtc.h,v retrieving revision 1.15 diff -u -p -u -r1.15 xf86Crtc.h --- hw/xfree86/modes/xf86Crtc.h 11 Nov 2021 09:10:04 - 1.15 +++ hw/xfree86/modes/xf86Crtc.h 4 Dec 2021 17:50:33 - @@ -837,11 +837,11 @@ extern _X_EXPORT int xf86CrtcConfigPriva static _X_INLINE xf86OutputPtr xf86CompatOutput(ScrnInfoPtr pScrn) { -xf86CrtcConfigPtr config = XF86_CRTC_CONFIG_PTR(pScrn); +xf86CrtcConfigPtr config; if (xf86CrtcConfigPrivateIndex == -1) -return NULL; - +return NULL; +config = XF86_CRTC_CONFIG_PTR(pScrn); if (config->compat_output < 0) return NULL; return config->output[config->compat_output]; Index: hw/xfree86/modes/xf86Modes.c === RCS file: /cvs/OpenBSD/xenocara/xserver/hw/xfree86/modes/xf86Modes.c,v retrieving revision 1.12 diff -u -p -u -r1.12 xf86Modes.c --- hw/xfree86/modes/xf86Modes.c11 Nov 2021 09:03:08 - 1.12 +++ hw/xfree86/modes/xf86Modes.c5 Dec 2021 18:20:52 - @@ -803,10 +803,14 @@ xf86CVTMode(int HDisplay, int VDisplay, { struct libxcvt_mode_info *libxcvt_mode_info; DisplayModeRec *Mode = xnfcalloc(1, sizeof(DisplayModeRec)); +char *tmp; libxcvt_mode_info = libxcvt_gen_mode_info(HDisplay, VDisplay, VRefresh, Reduced, Interlaced); +XNFasprintf(&tmp, "%dx%d", HDisplay, VDisplay); +Mode->name = tmp; + Mode->VDisplay = libxcvt_mode_info->vdisplay; Mode->HDisplay = libxcvt_mode_info->hdisplay; Mode->Clock = libxcvt_mode_info->dot_clock; -- Matthieu Herrb
Re: Fix vi(1) recovery - new method
Any other dev interested in fixing this? Feedback, suggestions, review? Tim. Andrew Hewus Fresh wrote: > In my quick test, this works a lot better than what we have now. At > least I get back more of the file I was working on. I also haven't been > able to reproduce the annoying segfault and half the original file > disappearing, although that was infrequent before so could just be luck. > > User experience with this patch is improved in my opinion, I'd like to > see it go in, so OK afresh1@ > > On Sat, Oct 09, 2021 at 08:26:13PM -0400, trondd wrote: > > This is a new attempt at fixing vi(1) recovery by actually writing > > to the recovery file. Previously I restored the SIGALRM method that > > was deleted in the 90's but wondered if that was still the best way > > to handle this. Checking and syncing to the recovery every 2 minutes > > seems arbitrary and overly cautious. > > > > This attempt takes it to the other direction. I'm writing each > > change to the recovery file immediately after the in-memory database > > is modified. Though, I can see that this might have a noticeable > > impact on slower file systems. > > > > VIM takes a sort of hybrid approach and writes to the backup every > > 200 characters or after 4 seconds of idle time. Perhaps this is the > > best method to not get too far behind while also not hammering the > > filesystem with quick edits. > > > > For now, I'm sticking to the naive approach for review. The diff is > > smaller than using SIGALRM and more straight forward and I'd like to > > hear what method might make sense to improve the process. This code > > would probably be the basis for other improvements. > > > > Below is my original explanation of the problem with vi(1)'s > > recovery. > > > > This is a reference to the older SIGALRM diff (I have a version > > updated to use the atomic signal flags if we want to look at the > > SIGALRM process instead). > > https://marc.info/?l=openbsd-tech&m=162940011614049 > > > > Tim. > > > > - > > > > While investigating an occasional crash when recovering a file with 'vi -r' > > after a power failure, I noticed that the recovery files are actually never > > updated during an editing session. The recovery files are created upon > > initial modification of the file which saves the state of the file at the > > time of the edit. You can work on a file for as long as you want and even > > write it to disk but the recovery file is never updated. If the session is > > then lost due to power failure or a SIGKILL and you attempt to recover with > > -r, you'll be presented with the contents of the file from that first edit. > > It won't contain unsaved changes nor even any changes manually written to > > disk to the original file. Accepting the recovered version would lose all > > of your work. > > > > Reading the vi docs, man page, and source comments in the OpenBSD tree, they > > all mention the use of SIGALRM to periodically save changes to the recovery > > file. However, the code never sets up a handler or captures SIGALRM. It > > only ever updates the recovery file on a SIGTERM but then also exits, I > > guess to cover the case of an inadvertent clean system shutdown. > > > > I dug through an nvi source repository[0] that seemed to cover it's entire > > history and it seems this functionality was lost somewhere around 1994 and I > > don't see it having been replaced by anything else. Our version seems to be > > from 1996 and editors/nvi in ports still lacks code to update the recovery > > file, as well. > > > > What I've done is re-implement periodic updates to the recovery file using > > SIGALRM and a timer like the original implementation but rewritten a bit to > > fit the newer source file layout and event handling. That keeps the > > recovery > > updated every 2 minutes. Then it seemed silly to be able to write changes > > to > > the original file and if a crash happens before the next SIGALRM, recovery > > would try to roll you back to before those saved changes. So I've also > > added > > a call to sync the recovery file if you explicitly write changes to disk. I > > don't think the recovery system should try to punish you for actively saving > > your work even if it is only at most 2 minutes worth. > > > > Comments or feedback? I'm unsure I've covered all caveats with this code or > > if there are vi/ex usecases where it won't work correctly. For testing, > > I've > > covered my usage and several scenarios I could contrive but I don't > > regularly > > use ex, for example, or change many options from the default. I've been > > running with this code for a week. And I suppose there must be a reason no > > one has noticed or cared about this for over 20 years. Everyone else uses > > vim, I guess? > > > > Tim. > > > > [0] https://repo.or.cz/nvi.git > > > > - > > Index: common/exf.h === RCS file: /cvs/src/usr.bin/vi
Re: close net80211 hardware crypto set_key races
On Sun, Dec 05, 2021 at 02:03:29PM +, Mikolaj Kucharski wrote: > Hi Stefan, > > I'm not yet ready to test new diffs, but I was going through old > wireless stack related emails and was wondering did below patch got > committed? Per my git / cvs search I don't think so. Is below diff > still relevant or can below change be ignored? > I would put this aside for now. The patch does not apply anymore and never received sufficient testing.
Re: Please test: UVM fault unlocking (aka vmobjlock)
On Dec 04 14:28:23, h...@stare.cz wrote: > On Dec 04 12:23:42, h...@stare.cz wrote: > > On Dec 01 09:07:43, h...@stare.cz wrote: > > > > > > On 24/11/21(Wed) 11:16, Martin Pieuchot wrote: > > > > > > > Diff below unlock the bottom part of the UVM fault handler. I'm > > > > > > > interested in squashing the remaining bugs. Please test with > > > > > > > your usual > > > > > > > setup & report back. > > > > > > > > > > > > Thanks to all the testers, here's a new version that includes a bug > > > > > > fix. > > > > > > Tests on !x86 architectures are much appreciated! current/amd64 on a Thinkpad T410 (dmesg below) having this patch just panicked with the following message: uvm_fault(0xfd8135c51178, 0x48, 0, 1) -> e I don't know if it's related to the patch, but given that the panic is uvm_faiult() ... Upon boot, the kernel said Dec 5 17:00:34 t410 /bsd: witness: lock order reversal: Dec 5 17:00:34 t410 /bsd: 1st 0xfd8115667438 uobjlk (&uobj->vmobjlock) Dec 5 17:00:34 t410 /bsd: 2nd 0x80bcf700 objmm (&obj->mm.lock) Dec 5 17:00:34 t410 /bsd: lock order "&obj->mm.lock"(rwlock) -> "&uobj->vmobjlock"(rwlock) first seen at: Dec 5 17:00:34 t410 /bsd: #0 rw_enter+0x65 Dec 5 17:00:34 t410 /bsd: #1 uvm_obj_wire+0x46 Dec 5 17:00:34 t410 /bsd: #2 shmem_get_pages+0xaf Dec 5 17:00:34 t410 /bsd: #3 __i915_gem_object_get_pages+0x9d Dec 5 17:00:34 t410 /bsd: #4 i915_vma_pin_ww+0x49b Dec 5 17:00:34 t410 /bsd: #5 i915_ggtt_pin+0x61 Dec 5 17:00:34 t410 /bsd: #6 __intel_context_do_pin_ww+0x2d1 Dec 5 17:00:34 t410 /bsd: #7 __intel_context_do_pin+0x4b Dec 5 17:00:34 t410 /bsd: #8 intel_engines_init+0x4a1 Dec 5 17:00:34 t410 /bsd: #9 intel_gt_init+0x133 Dec 5 17:00:34 t410 /bsd: #10 i915_gem_init+0xa3 Dec 5 17:00:34 t410 /bsd: #11 i915_driver_probe+0x75a Dec 5 17:00:34 t410 /bsd: #12 inteldrm_attachhook+0x45 Dec 5 17:00:34 t410 /bsd: #13 config_process_deferred_mountroot+0x6b Dec 5 17:00:34 t410 /bsd: #14 main+0x743 Dec 5 17:00:34 t410 /bsd: lock order "&uobj->vmobjlock"(rwlock) -> "&obj->mm.lock"(rwlock) first seen at: Dec 5 17:00:34 t410 /bsd: #0 rw_enter+0x65 Dec 5 17:00:34 t410 /bsd: #1 __i915_gem_object_get_pages+0x30 Dec 5 17:00:34 t410 /bsd: #2 i915_gem_fault+0x408 Dec 5 17:00:34 t410 /bsd: #3 drm_fault+0x156 Dec 5 17:00:34 t410 /bsd: #4 uvm_fault+0x179 Dec 5 17:00:34 t410 /bsd: #5 upageflttrap+0x62 Dec 5 17:00:34 t410 /bsd: #6 usertrap+0x18b Dec 5 17:00:34 t410 /bsd: #7 recall_trap+0x8 Dec 5 17:00:34 t410 /bsd: witness: lock order reversal: Dec 5 17:00:34 t410 /bsd: 1st 0xfd8115667438 uobjlk (&uobj->vmobjlock) Dec 5 17:00:34 t410 /bsd: 2nd 0x80bd0e48 vmapg (&vma->pages_mutex) Dec 5 17:00:34 t410 /bsd: lock order data w2 -> w1 missing Dec 5 17:00:34 t410 /bsd: lock order "&uobj->vmobjlock"(rwlock) -> "&vma->pages_mutex"(rwlock) first seen at: Dec 5 17:00:34 t410 /bsd: #0 rw_enter+0x65 Dec 5 17:00:34 t410 /bsd: #1 i915_vma_pin_ww+0x1c7 Dec 5 17:00:34 t410 /bsd: #2 i915_gem_object_ggtt_pin_ww+0x222 Dec 5 17:00:34 t410 /bsd: #3 i915_gem_fault+0x450 Dec 5 17:00:34 t410 /bsd: #4 drm_fault+0x156 Dec 5 17:00:34 t410 /bsd: #5 uvm_fault+0x179 Dec 5 17:00:34 t410 /bsd: #6 upageflttrap+0x62 Dec 5 17:00:34 t410 /bsd: #7 usertrap+0x18b Dec 5 17:00:34 t410 /bsd: #8 recall_trap+0x8 Dec 5 17:00:34 t410 /bsd: witness: lock order reversal: Dec 5 17:00:34 t410 /bsd: 1st 0xfd8115667438 uobjlk (&uobj->vmobjlock) Dec 5 17:00:34 t410 /bsd: 2nd 0x80111070 vmlk (&vm->mutex) Dec 5 17:00:34 t410 /bsd: lock order data w2 -> w1 missing Dec 5 17:00:34 t410 /bsd: lock order "&uobj->vmobjlock"(rwlock) -> "&vm->mutex"(rwlock) first seen at: Dec 5 17:00:34 t410 /bsd: #0 rw_enter+0x65 Dec 5 17:00:34 t410 /bsd: #1 i915_vma_pin_ww+0x2f2 Dec 5 17:00:34 t410 /bsd: #2 i915_gem_object_ggtt_pin_ww+0x222 Dec 5 17:00:34 t410 /bsd: #3 i915_gem_fault+0x450 Dec 5 17:00:34 t410 /bsd: #4 drm_fault+0x156 Dec 5 17:00:34 t410 /bsd: #5 uvm_fault+0x179 Dec 5 17:00:34 t410 /bsd: #6 upageflttrap+0x62 Dec 5 17:00:34 t410 /bsd: #7 usertrap+0x18b Dec 5 17:00:34 t410 /bsd: #8 recall_trap+0x8 but the machine was running as usual, with about three chrome tabs, and mplayer playing some audio files. Then, after about two hours: Dec 5 18:46:36 t410 /bsd: uvm_fault(0xfd8135c51178, 0x48, 0, 1) -> e Dec 5 18:46:36 t410 /bsd: kernel: page fault trap, code=0 Dec 5 18:46:36 t410 /bsd: Stopped at pledge_recvfd+0x59: movl 0x48(%rsi),%eax Dec 5 18:46:36 t410 /bsd: TIDPIDUID PRFLAGS PFLAGS CPU COMMAND Dec 5 18:46:36 t410 /bsd: * 13684 98899 10000x33 0x4000K chrome Dec 5 18:46:36 t410 /bsd: 137636 44471 990x100010 02 sndiod Dec 5 18:46:36 t410 /bsd: pledge_recvfd(8000334e4a90,0) at pledge_recvfd+0x59 Dec 5 18:46:36 t410 /bsd: unp_externalize(fd8063543600,210,80) at unp_e
Re: close net80211 hardware crypto set_key races
Hi Stefan, I'm not yet ready to test new diffs, but I was going through old wireless stack related emails and was wondering did below patch got committed? Per my git / cvs search I don't think so. Is below diff still relevant or can below change be ignored? On Thu, Jul 01, 2021 at 12:23:33PM +0200, Stefan Sperling wrote: > Some wifi drivers defer installation of keys into a process context. > There was a noticable race in the past which was fixed thanks to krw@ > where link state was set to UP before key installation had completed in > hardware. This race could result in dhclient failing to get a lease. > > Other races remain. These concern state which controls encryption of > frames in the output path of net80211 (TXRXPROT flag), and marks the > pairwise key as installed (PTKDONE state) which in turn affects our > acceptance of group key updates sent by the AP. While either of these > flags is set and hardware is not configured for encryption we are running > in an inconsistent state. I don't know if this causes problems in practice > but we should be avoiding such races. The fix is fairly mechanical and > essentially defers modification of relevant flags from net80211 into the > affected drivers. > > Affected drivers are: iwx, bfwm, athn (USB only!), urtwn, run, rsu, otus. > I have tested on iwx, athn, urtwn, and run. More tests are welcome. > > ok? > > diff 86b3b873864f7e98e688c12d8e455803ff30eadb > 27f93922f2b250b31e9534b457665df3dcf58794 > blob - ea245574f624ada1b8d0c9e8e8a0653fb2c3adc4 > blob + 0bac2cda2290c4a44de8f5b8110a4399f75de88d > --- sys/dev/ic/bwfm.c > +++ sys/dev/ic/bwfm.c > @@ -2714,7 +2714,13 @@ bwfm_set_key_cb(struct bwfm_softc *sc, void *arg) > wsec |= wsec_enable; > bwfm_fwvar_var_set_int(sc, "wsec", wsec); > > + if ((k->k_flags & IEEE80211_KEY_GROUP) == 0 && > + ni->ni_rsn_supp_state == RSNA_SUPP_PTKNEGOTIATING) > + ni->ni_rsn_supp_state = RSNA_SUPP_PTKDONE; > + > if (sc->sc_key_tasks == 0) { > + if (k->k_flags & IEEE80211_KEY_SECURE) > + ni->ni_flags |= IEEE80211_NODE_TXRXPROT; > DPRINTF(("%s: marking port %s valid\n", DEVNAME(sc), > ether_sprintf(cmd->ni->ni_macaddr))); > cmd->ni->ni_port_valid = 1; > blob - bdf8ce3e1afa332f698e3dc56af77e6acb4f8689 > blob + 5be1d92ee862f584df5901fe54ebe30e0c937d36 > --- sys/dev/pci/if_iwx.c > +++ sys/dev/pci/if_iwx.c > @@ -6747,12 +6747,17 @@ iwx_add_sta_key(struct iwx_softc *sc, int sta_id, stru > return err; > } > > - if (k->k_flags & IEEE80211_KEY_GROUP) > + if (k->k_flags & IEEE80211_KEY_GROUP) { > in->in_flags |= IWX_NODE_FLAG_HAVE_GROUP_KEY; > - else > + } else { > in->in_flags |= IWX_NODE_FLAG_HAVE_PAIRWISE_KEY; > + if (ni->ni_rsn_supp_state == RSNA_SUPP_PTKNEGOTIATING) > + ni->ni_rsn_supp_state = RSNA_SUPP_PTKDONE; > + } > > if ((in->in_flags & want_keymask) == want_keymask) { > + if (k->k_flags & IEEE80211_KEY_SECURE) > + ni->ni_flags |= IEEE80211_NODE_TXRXPROT; > DPRINTF(("marking port %s valid\n", > ether_sprintf(ni->ni_macaddr))); > ni->ni_port_valid = 1; > blob - 08ffda8c9aaede9c901d97a43bf2873591e8df19 > blob + 0c141fc5df7ba1a774af98a59a2b718bdcc721bb > --- sys/dev/usb/if_athn_usb.c > +++ sys/dev/usb/if_athn_usb.c > @@ -1662,7 +1662,12 @@ athn_usb_set_key_cb(struct athn_usb_softc *usc, void * > s = splnet(); > athn_usb_write_barrier(&usc->sc_sc); > athn_set_key(ic, cmd->ni, cmd->key); > + if ((cmd->key->k_flags & IEEE80211_KEY_GROUP) == 0 && > + cmd->ni->ni_rsn_supp_state == RSNA_SUPP_PTKNEGOTIATING) > + cmd->ni->ni_rsn_supp_state = RSNA_SUPP_PTKDONE; > if (usc->sc_key_tasks == 0) { > + if (cmd->key->k_flags & IEEE80211_KEY_SECURE) > + cmd->ni->ni_flags |= IEEE80211_NODE_TXRXPROT; > DPRINTF(("marking port %s valid\n", > ether_sprintf(cmd->ni->ni_macaddr))); > cmd->ni->ni_port_valid = 1; > blob - bb220831ffc852347afdcda18c9bca0589d6d939 > blob + 8e426e9cab0b389f2e1260139ad451b30e10287e > --- sys/dev/usb/if_otus.c > +++ sys/dev/usb/if_otus.c > @@ -2116,7 +2116,12 @@ otus_set_key_cb(struct otus_softc *sc, void *arg) > memcpy(key.key, k->k_key + 16, 16); > (void)otus_cmd(sc, AR_CMD_EKEY, &key, sizeof key, NULL); > > + if ((k->k_flags & IEEE80211_KEY_GROUP) == 0 && > + cmd->ni->ni_rsn_supp_state == RSNA_SUPP_PTKNEGOTIATING) > + cmd->ni->ni_rsn_supp_state = RSNA_SUPP_PTKDONE; > if (sc->sc_key_tasks == 0) { > + if (k->k_flags & IEEE80211_KEY_SECURE) > + cmd->ni->ni_flags |= IEEE80211_NODE_TXRXPROT; > DPRINTF(("marking port %s valid\n", > ether_sprintf(cmd->ni->ni_macaddr))); > cmd->ni->ni
Re: OpenBSD Errata: November 9, 2021 (rpki-client)
On Tue, Nov 9, 2021 at 3:05 PM Sebastian Benoit wrote: > An errata patch for rpki-client has been released for OpenBSD 6.9 [...] It turns out that the 6.9 version of the patch (021_rpki) causes rpki-client to provide OpenBGPd output that bgpd does not accept. Specifically: bgpd on 6.9 does not accept the 'expires' property in the ROA, in line with what bgpd.conf(5) states. # bgpd -n /var/db/rpki-client/openbgpd:13: syntax error # head -n 13 /var/db/rpki-client/openbgpd | tail -n2 roa-set { 1.0.0.0/24 source-as 13335 expires 1638843500 Noticed this by accident on an older host that I was about to upgrade. Following diff changes the rpki-client output to restore bgpd's former happiness. Of course, it only makes sense to apply this on 6.9-stable (r1.20.2.1). Index: output-bgpd.c === RCS file: /cvs/src/usr.sbin/rpki-client/output-bgpd.c,v retrieving revision 1.20.2.1 diff -u -p -u -r1.20.2.1 output-bgpd.c --- output-bgpd.c 9 Nov 2021 13:41:19 - 1.20.2.1 +++ output-bgpd.c 5 Dec 2021 13:06:27 - @@ -42,8 +42,8 @@ output_bgpd(FILE *out, struct vrp_tree * return -1; } else maxlenbuf[0] = '\0'; - if (fprintf(out, "\t%s %ssource-as %u expires %lld\n", - ipbuf, maxlenbuf, v->asid, (long long)v->expires) < 0) + if (fprintf(out, "\t%s %ssource-as %u\n", + ipbuf, maxlenbuf, v->asid) < 0) return -1; } Best regards, Rogier