Re: Strong Host Model in OpenBSD network stack
On 2019-12-10, Bastian Kanbach wrote: > Good evening all, > > following up on the previous discussions, I noticed that the network > stack changed recently [1] (limited to cases when packet forwarding is > enabled). > > What's the idea behind it, as it seemed to be unlikely that this default > would be changed at all? It helps with https://www.openwall.com/lists/oss-security/2019/12/05/1 for simpler cases. For more complex cases where forwarding is also used, restrictions can be made with PF (urpf-failed; this was possible before, too).
Re: password-less user (without bothering security(8))?
On 2019-12-10, Adam Thompson wrote: > Is there a way to placate security(8) that I'm just not seeing? Or is > my goal fundamentally misguided for some reason I'm not seeing? The Philipp is right, * in master.passwd's crypted password field. > user in this case is semi-trusted (e.g. yes, we'll let you login using > an unprivileged account to run bgpctl in pipelines) but not > organizationally-trusted (i.e. but that's ALL we want you to do on this > system). Just be aware that some bgpctl operations are powerful. Even with the restricted socket, full table dumps can use a lot of cpu.
Re: Can't select files to upload in a browsers
On 2019-12-10, dmitry.sensei wrote: > Can I setup unveil for browsers by usergroups or login classes? Due to the slightly unusual way Firefox deals with the config files (searches in /etc/firefox and then falls back to files in /usr/local/lib) you might be able to partially do what you want by making /etc/firefox mode 750 and setting the group ownership. Untested but I suspect it will work. Otherwise not without code changes to the unveil implementation in the browsers.
Re: Solid-Run's HoneyComb LX2K for OpenBSD
On Tue, Dec 10, 2019 at 10:25:57PM +1100, VanL wrote: > > > How good are the chances of the 'HoneyComb LX2K' running OpenBSD? [1] > > > > Footnotes: > > [1] https://www.solid-run.com/nxp-lx2160a-family/honeycomb-workstation/ > > For future reference, the more specific place to ask is a...@openbsd.org > and the places to see before asking are: > > https://ftp.openbsd.org/pub/OpenBSD/snapshots/arm64/INSTALL.arm64 > https://ftp.openbsd.org/pub/OpenBSD/6.6/arm64/INSTALL.arm64 > https://www.openbsd.org/arm64.html I thought about buying one, but that SoC is from another architecture team at NXP which means that we'd need to another stack of drivers just to support the SoC used there. Though with ACPI some things might get easier. So, as of now, I don't think there's a chance OpenBSD runs on that LX2K hardware, unless someone from us gets such a machine and starts writing support for it. Patrick
Re: reorder_kernel: failed
I was getting the same error in the setting of Dual Booting: More details in this daemonforums thread http://daemonforums.org/showthread.php?t=11200 Dieter Rauschenberger said: I forgot to include the error while make install of a kernel: LD="ld" LDFLAGS="-g" sh makegap.sh 0x gapdummy.o ld -T ld.script -X --warn-common -nopie -o bsd ${SYSTEM_HEAD} vers.o ${OBJS} textdatabss dec hex 0 0 0 0 0 mv bsd bsd.gdb ctfstrip -S -o bsd bsd.gdb strip: bsd.gdb: File format not recognized It looks like ld if totally failing. -Dieter On Sun, Dec 08, 2019 at 07:48:15PM +0100, Dieter Rauschenberger wrote: Hi misc, I have a reorder_kernel: failed -- see /usr/share/relink/kernel/GENERIC/relink.log error in todays snapshot (i386) Build date: 1575786572 - Sun Dec 8 06:29:32 UTC 2019 $ cat /usr/share/relink/kernel/GENERIC/relink.log (SHA256) /bsd: OK LD="ld" LDFLAGS="-g" sh makegap.sh 0x gapdummy.o ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o ${OBJS} size: newbsd: not object file or archive *** Error 1 in /usr/share/relink/kernel/GENERIC (Makefile:1126 'newbsd': @size newbsd ; umask 007; echo mv newbsd newbsd.gdb; rm -f newbsd) I tried to build a GENERIC kernel on this machine, but make install failed at the line: ld -T ld.script -X --warn-common -nopie -o bsd ${SYSTEM_HEAD} vers.o ${OBJS} The dmesg of this machine is: OpenBSD 6.6-current (GENERIC) #418: Sat Dec 7 23:05:40 MST 2019 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC real mem = 266682368 (254MB) avail mem = 246185984 (234MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: date 08/25/00, BIOS32 rev. 0 @ 0xe7300, SMBIOS rev. 2.3 @ 0xf8dc6 (47 entries) bios0: vendor Compaq version "686P2 v2.04" date 08/25/2000 bios0: Compaq Deskpro acpi0 at bios0: ACPI 1.0 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP SSDT SSDT SSDT APIC SSDT SSDT SSDT SSDT SSDT SSDT SSDT acpi0: wakeup devices PCI0(S4) HUB_(S4) COM1(S4) COM2(S4) USB1(S3) USB2(S3) PBTN(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel Pentium III ("GenuineIntel" 686-class) 732 MHz, 06-08-06 cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PSE36,MMX,FXSR,SSE,PERF,MELTDOWN mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 132MHz ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins, remapped acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 2 (HUB_) acpicpu0 at acpi0: C1(@1 halt!) "PNP0A03" at acpi0 not configured acpicmos0 at acpi0 "PNP0003" at acpi0 not configured acpibtn0 at acpi0: PBTN bios0: ROM list: 0xc/0xa000 0xca000/0x800 0xca800/0xd800! 0xe/0x1! pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 "Intel 82815 Host" rev 0x02 vga1 at pci0 dev 2 function 0 "Intel 82815 Video" rev 0x02 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) ppb0 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0x02 pci1 at ppb0 bus 2 xl0 at pci1 dev 4 function 0 "3Com 3c905C" rev 0x78: apic 8 int 16, address 00:04:76:26:b5:0f exphy0 at xl0 phy 24: 3Com internal media interface fxp0 at pci1 dev 8 function 0 "Intel 82562" rev 0x01, i82562: apic 8 int 20, address 00:02:a5:2b:0f:43 inphy0 at fxp0 phy 1: i82562EM 10/100 PHY, rev. 0 ichpcib0 at pci0 dev 31 function 0 "Intel 82801BA LPC" rev 0x02 pciide0 at pci0 dev 31 function 1 "Intel 82801BA IDE" rev 0x02: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: wd0: 16-sector PIO, LBA48, 152627MB, 312581808 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 atapiscsi0 at pciide0 channel 1 drive 0 scsibus1 at atapiscsi0: 2 targets cd0 at scsibus1 targ 0 lun 0: removable cd0(pciide0:1:0): using PIO mode 4, DMA mode 2 uhci0 at pci0 dev 31 function 4 "Intel 82801BA USB" rev 0x02: apic 8 int 23 auich0 at pci0 dev 31 function 5 "Intel 82801BA AC97" rev 0x02: apic 8 int 17, ICH2 ac97: codec id 0x41445360 (Analog Devices AD1885) ac97: codec features headphone, Analog Devices Phat Stereo audio0 at auich0 isa0 at ichpcib0 isadma0 at isa0 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0: console keyboard, using wsdisplay0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 usb0 at uhci0: USB revision 1.0 uhub0 at usb0 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1 vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on wd0a (5463234f8754b441
Re: unbound network optimizations
Replying to my own thread as it was pointed out that I neglected to add some information. OpenBSD 6.5 (GENERIC.MP) #7: Wed Nov 20 23:21:48 MST 2019 Native unbound (latest syspatch) Bge interfaces running on an LACP trunk with IPv4 and IPv6 addresses. NameMtu Network Address Ipkts IfailOpkts Ofail Colls bge0150044:a8:42:37:bb:b8 114258345 0 84203414 0 0 bge1150044:a8:42:37:bb:b8 57304058 0 84467834 0 0 bge2* 150044:a8:42:37:bb:ba0 00 0 0 bge3* 150044:a8:42:37:bb:bb0 00 0 0 enc0* 00 00 0 0 trunk0 150044:a8:42:37:bb:b8 171549799 0 16865964412 0 trunk0 1500 fe80::%trunk0/64 fe80::601b:75c2:6b28:7276%trunk0 171549799 0 16865964412 0 -Steve S. -Original Message- From: Steven Surdock Sent: Monday, December 2, 2019 1:34 PM To: misc@openbsd.org Subject: unbound network optimizations I'm running a pair of unbound resolvers and am attempting to optimize performance on them. This stemmed from noticing a couple of issues in the logs. Dec 2 11:26:52 ns1 unbound: [54230:5] error: recvfrom 26 failed: Host is down Dec 2 11:27:11 ns1 unbound: [54230:5] notice: sendto failed: Resource temporarily unavailable Dec 2 11:27:11 ns1 unbound: [54230:5] notice: remote address is 192.168.2.42 port 5088 I believed the first message is related to a dropped UDP request or subsequent response. 'netstat -p -u udp' shows "dropped due to full socket buffers". This was significantly reduced by increasing, net.inet.udp.recvspace=262144 net.inet.udp.sendspace=262144 Unfortunately, I'm still seeing a few UDP drops. Is there a danger in setting this is high? ns1$ netstat -s -p udp udp: 698584369 datagrams received 0 with incomplete header 0 with bad data length field 2508 with bad checksum 676259 with no checksum 86709458 input packets software-checksummed 706308843 output packets software-checksummed 641800 dropped due to no socket 0 broadcast/multicast datagrams dropped due to no socket 0 dropped due to missing IPsec protection 77324 dropped due to full socket buffers 697862737 delivered 706308952 datagrams output 698578008 missed PCB cache The second log message seems to stem from a dropped TCP request. There seems to be a significant number of these and I'm assuming they stem from "452447 SYN packets dropped due to queue or memory full" as the number of log message is in the same range as the number of dropped SYN packets. ns1$ netstat -s -p tcp tcp: 1856161 packets sent 359575 data packets (73608768 bytes) 27022 data packets (5076843 bytes) retransmitted 0 fast retransmitted packets 928517 ack-only packets (414664 delayed) 0 URG only packets 67 window probe packets 2217 window update packets 538808 control packets 271352 packets software-checksummed 2391157 packets received 739060 acks (for 71221089 bytes) 225691 duplicate acks 506 acks for unsent data 0 acks for old data 473441 packets (101441404 bytes) received in-sequence 111074 completely duplicate packets (75769595 bytes) 21701 old duplicate packets 3 packets with some duplicate data (112 bytes duplicated) 231945 out-of-order packets (88494422 bytes) 21 packets (0 bytes) of data after window 0 window probes 34417 window update packets 6771 packets received after close 52 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded for missing IPsec protection 0 discarded due to memory shortage 231084 packets software-checksummed 0 bad/missing md5 checksums 0 good md5 checksums 213191 connection requests 156110 connection accepts 340472 connections established (including accepts) 369167 connections closed (including 14600 drops) 0 connections drained 14167 embryonic connections dropped 860911 segments updated rtt (of 838375 attempts) 40788 retransmit timeouts 3005 connections dropped by rexmit timeout 69 persist timeouts 6563 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 12445 correct ACK header predictions 222843 correct data packet header predictions 828362 PCB cache