em(4) vlan tagging support for 82576

[Yury Shefer]

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

[Jonathan Gray]

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(, "%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

[Scott Cheloha]

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, , 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_vmspace->vm_map,
-   baseva, PAGE_SIZE, , UVM_EXTRACT_FIXPROT)))
+   KERNEL_LOCK();
+   error = uvm_map_extract(>p_vmspace->vm_map,
+   baseva, PAGE_SIZE, , UVM_EXTRACT_FIXPROT);
+   KERNEL_UNLOCK();
+   if (error)
break;
last_baseva = baseva;
}

Re: sppp(4)/pppoe(4) - avoid endless loop in remote ip negotiation

[Stuart Henderson]

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

[Krzysztof Kanas]

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

[Matthieu Herrb]

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(, "%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

[trondd]

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=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: 

Re: close net80211 hardware crypto set_key races

[Stefan Sperling]

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)

[Jan Stary]

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 (>vmobjlock)
Dec  5 17:00:34 t410 /bsd:  2nd 0x80bcf700 objmm (>mm.lock)
Dec  5 17:00:34 t410 /bsd: lock order ">mm.lock"(rwlock) -> 
">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 ">vmobjlock"(rwlock) -> 
">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 (>vmobjlock)
Dec  5 17:00:34 t410 /bsd:  2nd 0x80bd0e48 vmapg (>pages_mutex)
Dec  5 17:00:34 t410 /bsd: lock order data w2 -> w1 missing
Dec  5 17:00:34 t410 /bsd: lock order ">vmobjlock"(rwlock) -> 
">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 (>vmobjlock)
Dec  5 17:00:34 t410 /bsd:  2nd 0x80111070 vmlk (>mutex)
Dec  5 17:00:34 t410 /bsd: lock order data w2 -> w1 missing
Dec  5 17:00:34 t410 /bsd: lock order ">vmobjlock"(rwlock) -> 
">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_externalize+0x10c
Dec  5 18:46:36 t410 /bsd: 

Re: close net80211 hardware crypto set_key races

[Mikolaj Kucharski]

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(>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, , 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)));
>   

Re: OpenBSD Errata: November 9, 2021 (rpki-client)

[Rogier Krieger]

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