Re: Libressl verify failure with 3.9.0
Thanks for the suggestion. The workaround does work, and creates (essentially) the same certificate, but one that does not fail verification with the new libressl. I did notice the option of not have the leading "20" for dates before 2050, but I did not know enough to try doing that. Ted > -Original Message- > > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On > Behalf > > Of Theo Buehler > > Sent: Monday, April 08, 2024 6:45 AM > > To: Ted Wynnychenko > > Cc: 'OpenBSD misc'; b...@openbsd.org; js...@openbsd.org > > Subject: Re: Libressl verify failure with 3.9.0 > > > > On Sun, Apr 07, 2024 at 04:57:24PM -0500, Ted Wynnychenko wrote: > > > Hello, > > > > > > I recently updated to -current (about a week ago). > > > > > > I see that Libressl is at 3.9.1 just now, but I hope that won't be > an > > issue > > > (I did not see anything in the release notes that would impact my > > question). > > > --- > > > $ openssl version > > > LibreSSL 3.9.0 > > > --- > > > > > > Over the years, I have made certificates for personal > > servers/resources on > > > my home network. This is just for me, so I do some things that > would > > be > > > frowned on (although, technically, there is nothing "wrong" with > > them). > > > > > > In this case, since I have Apple iOS devices that I want to connect > > to > > > https, I backdate any certificates I create to 1/2/2019. Apple has > > imposed > > > a 300 or 800 day time limit on the validity for certificates > created > > after > > > (about) 7/1/2019. Since I don't want to constantly make new > > certificates > > > for my personal/home network, I have just been setting the > > certificates' > > > "not before" date to early 2019. > > > > > > Anyway, this had worked fine. > > > In fact, earlier this year (Jan 2024), I created a new certificate, > > and all > > > is good. > > > > > > A few weeks ago, I added a new thing to the network - a raspberry > pi > > (I got > > > as a gift about 2013 and installed a linux image from 2019 on it) > > that is > > > connected to the home alarm system. > > > > > > Since I was annoyed that my browser was constantly giving me self- > > signed > > > certificate warnings, I decided to make a certificate for the nginx > > running > > > on this appliance. > > > > > > I created a key, made a csr, and then signed it with: > > > openssl ca -startdate 2019010200Z -in pi.csr -out pi.pem - > config > > > /etc/ssl/openssl.cnf > > > > As a workaround, try using '-startdate 19010200Z' instead. I > think > > this is fallout from this commit: > > > > > https://github.com/openbsd/src/commit/3feee4c53fbd67a4a480080d8ef5ae835 > > d3fbf82 > > > > ASN1_TIME_set_string_X509() is documented as > > > > In LibreSSL, ASN1_TIME_set_string() and > > ASN1_TIME_set_string_X509() > > behave identically and always set the time object to a valid > value > > to use > > in an X.509 certificate. > > > > It seems to me that this is just wrong (it is true that both behave > > identically because RFC5280 is defined to 0), but they do not set the > > time object to "a valid value to use in an X.509 certificate". > > > > Confusingly, ASN1_TIME_adj_internal() actually honours its RFC5280 > > parameter by behaving the expected way whereas its meaning in > > ASN1_TIME_set_string_internal() is different. > > > > I am unsure if the bug is in my commit above or in our version of > > ASN1_TIME_set_string_X509() (or both). > > > > > > > > This all works fine, and a certificate is created > > > > > > When I check with: > > > openssl x509 -text -noout -in pi.pem > > > > > > everything seems as expected, including the not before/after dates: > > > > > > Validity > > > Not Before: Jan 2 00:00:00 2019 GMT > > > Not After : Apr 7 15:39:59 2054 GMT > > > > > > (yes, it is valid for 35 years - as I said before, if someone > breaks > > into my > > > house to secretly do things, I have way bigger problems) > > > > > > But, if I try to verify this on the openbsd system, I get: > > > > > > # openssl verify pi.pem > > > C = US, ST = Illinois, L = ***, O =
Libressl verify failure with 3.9.0
Hello, I recently updated to -current (about a week ago). I see that Libressl is at 3.9.1 just now, but I hope that won't be an issue (I did not see anything in the release notes that would impact my question). --- $ openssl version LibreSSL 3.9.0 --- Over the years, I have made certificates for personal servers/resources on my home network. This is just for me, so I do some things that would be frowned on (although, technically, there is nothing "wrong" with them). In this case, since I have Apple iOS devices that I want to connect to https, I backdate any certificates I create to 1/2/2019. Apple has imposed a 300 or 800 day time limit on the validity for certificates created after (about) 7/1/2019. Since I don't want to constantly make new certificates for my personal/home network, I have just been setting the certificates' "not before" date to early 2019. Anyway, this had worked fine. In fact, earlier this year (Jan 2024), I created a new certificate, and all is good. A few weeks ago, I added a new thing to the network - a raspberry pi (I got as a gift about 2013 and installed a linux image from 2019 on it) that is connected to the home alarm system. Since I was annoyed that my browser was constantly giving me self-signed certificate warnings, I decided to make a certificate for the nginx running on this appliance. I created a key, made a csr, and then signed it with: openssl ca -startdate 2019010200Z -in pi.csr -out pi.pem -config /etc/ssl/openssl.cnf This all works fine, and a certificate is created When I check with: openssl x509 -text -noout -in pi.pem everything seems as expected, including the not before/after dates: Validity Not Before: Jan 2 00:00:00 2019 GMT Not After : Apr 7 15:39:59 2054 GMT (yes, it is valid for 35 years - as I said before, if someone breaks into my house to secretly do things, I have way bigger problems) But, if I try to verify this on the openbsd system, I get: # openssl verify pi.pem C = US, ST = Illinois, L = ***, O = ***, OU = ***, CN = *** error 20 at 0 depth lookup:unable to get local issuer certificate pi.pem: verification failed: 20 (unable to get local issuer certificate) --- But, if I install this on the raspberry pi, which has a much older version of openssl on it: $ openssl version OpenSSL 1.1.1c 28 May 2019 The certificate verifies without an issue: $ openssl verify pi.pem pi.pem: OK The last time I created a certificate was in January of this year (1/22/2024). I am thinking the openbsd system was using Libressl 3.8.2 at that point. I created that certificate in the exact same way, backdating the start date: openssl ca -startdate 2019010200Z -in 54.csr -out 54.pem -config /etc/ssl/openssl.cnf This previously created certificate also has them same backdated and very long valid period: Validity Not Before: Jan 2 00:00:00 2019 GMT Not After : Jan 21 23:49:22 2054 GMT (Notice the not after date is a little different) Today, with the new libressl, this certificate verifies OK. $ openssl verify 54.pem 54.pem: OK Finally, if I create the new certificate WITHOUT backdating it e.g.: openssl ca -in pi.csr -out pi.pem -config /etc/ssl/openssl.cnf The certificate is created and verifies OK. So, it seems, there is some sort of issue with backdating the certificate, but not an issue with the crazy long validity window, that was not present in January of this year. However, as I said, if I don't backdate, then in about a year the ipad will refuse to connect because of the restrictions apple has imposed, unless I update the certificate. I know this is not "best practice," but it should still work, right? Is there something I am missing? Otherwise, it appears something has changed in Libressl 3.9.0 but is not documented. Thanks in advance for any suggestions. Ted
Re: Compulab's Fitlet3: Intel's Elkhart Atom X6425E with MARVELL PHY 88E1512 Ethernet
Stefan's efforts on this are appreciated. Our Fitlet3 units may have slight differences, but in case it is helpful, I've included the following: Intel Elkhart Lake Ethernet on Compulab Fitlet3 with PCI Product ID: 4ba1 and 4bb1 not recognized. Regards, Ted Output of pcidump; pcidump -vv 0:29:1; pcidump -vv 0:29:2; dmesg Domain /dev/pci0: 0:0:0: Intel Elkhart Lake Host 0:2:0: Intel UHD Graphics 0:8:0: Intel Elkhart Lake GNA 0:20:0: Intel Elkhart Lake xHCI 0:20:2: Intel Elkhart Lake SRAM 0:21:0: Intel Elkhart Lake I2C 0:21:2: Intel Elkhart Lake I2C 0:21:3: Intel Elkhart Lake I2C 0:22:0: Intel Elkhart Lake HECI 0:23:0: Intel Elkhart Lake AHCI 0:25:0: Intel Elkhart Lake I2C 0:25:2: Intel Elkhart Lake UART 0:28:0: Intel Elkhart Lake PCIE 0:28:4: Intel Elkhart Lake PCIE 0:28:6: Intel Elkhart Lake PCIE 0:29:0: Intel Elkhart Lake LH2OSE 0:29:1: Intel Elkhart Lake Ethernet 0:29:2: Intel Elkhart Lake Ethernet 0:30:0: Intel Elkhart Lake UART 0:30:1: Intel Elkhart Lake UART 0:31:0: Intel Elkhart Lake eSPI 0:31:3: Intel Elkhart Lake HD Audio 0:31:4: Intel Elkhart Lake SMBus 0:31:5: Intel Elkhart Lake SPI 1:0:0: unknown unknown 3:0:0: Intel Wi-Fi 6 AX210 0:29:1: Intel Elkhart Lake Ethernet 0x: Vendor ID: 8086, Product ID: 4ba1 0x0004: Command: , Status: 0010 0x0008: Class: 02 Network, Subclass: 00 Ethernet, Interface: 18, Revision: 11 0x000c: BIST: 00, Header Type: 80, Latency Timer: 00, Cache Line Size: 00 0x0010: BAR mem 64bit addr: 0x00600134/0x0004 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 8086 Product ID: 7270 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 01 Line: ff Min Gnt: 00 Max Lat: 00 0x0080: Capability 0x01: Power Management State: D0 0x0090: Capability 0x09: Vendor Specific 0x00d0: Capability 0x05: Message Signalled Interrupts (MSI) Enabled: no 0:29:2: Intel Elkhart Lake Ethernet 0x: Vendor ID: 8086, Product ID: 4bb1 0x0004: Command: , Status: 0010 0x0008: Class: 02 Network, Subclass: 00 Ethernet, Interface: 19, Revision: 11 0x000c: BIST: 00, Header Type: 80, Latency Timer: 00, Cache Line Size: 00 0x0010: BAR mem 64bit addr: 0x00600130/0x0004 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 8086 Product ID: 7270 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 01 Line: ff Min Gnt: 00 Max Lat: 00 0x0080: Capability 0x01: Power Management State: D0 0x0090: Capability 0x09: Vendor Specific 0x00d0: Capability 0x05: Message Signalled Interrupts (MSI) Enabled: no OpenBSD 7.4-current (RAMDISK_CD) #1331: Sun Oct 15 10:39:10 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 8378597376 (7990MB) avail mem = 8120643584 (7744MB) random: good seed from bootblocks mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x76a31000 (81 entries) bios0: vendor American Megatrends International, LLC. version "5.19" date 01/24/2023 bios0: Default string Default string acpi0 at bios0: ACPI 6.2 acpi0: tables DSDT FACP MCFG SSDT SSDT SSDT FIDT OEM1 HPET APIC PRAM RSCI SSDT SSDT SSDT NHLT SSDT SSDT PSDS LPIT SSDT DMAR SSDT TPM2 WSMT FPDT acpihpet0 at acpi0: 1920 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Celeron(R) J6413 @ 1.80GHz, 1796.11 MHz, 06-96-01, patch 0014 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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SMEP,ERMS,RDSEED,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,WAITPKG,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,MISC_PKG_CT,ENERGY_FILT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 12-way L2 cache, 4MB 64b/line 16-way L3 cache cpu0: apic clock running at 38MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.2.2.1.1.1, IBE cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins acpiprt0 at acpi0: bus 0 (PC00) acpiprt1 at acpi0: bus -1 (PEG0) acpiprt2 at acpi0: bus -1 (PEG1) acpiprt3 at acpi0: bus -1 (PEG2) acpiprt4 at acpi0: bus -1 (PEG3) acpiprt5 at acpi0: bus 1 (RP01) acpiprt6 at acpi0: bus -1 (RP02) acpiprt7 at acpi0: bus -1 (RP03) acpiprt8 at acpi0: bus -1 (RP04) acpiprt9 at acpi0: bus 2 (RP05) acpiprt10 at acpi0: bus -1 (RP06) acpiprt11 at acpi0: bus 3 (RP07) acpipci0 at acpi0 PC00: 0x 0x0011 0x0001 "INTC1027" at
kshcolor - a script for decorating ksh shell programs and terminals
Hiya folks,
As a learning project to teach myself how to use the ksh shell I wrote a
helper script to set ansi colors and decorations that I'm calling
*kshcolor*.
The script is available here for anyone who is intrigued:
https://github.com/tbullock/kshcolor
The project includes a makefile to build the script, this was necessary
since manually typing ANSI escape sequences is annoying so I chose to
generate those rather than fail at typing them.
To install run `make install`
To run the included test run `make test`
The makefile will install the file kshcolor.sh in $(HOME)/bin
The script includes the following functions:
bk # Sets Black
rd # Sets Red
gr # Sets Green
ye # Sets Yellow
bl # Sets Blue
mg # Sets Magenta
cy # Sets Cyan
wh # Sets White
bg_bk # Sets background Black
bg_rd # Sets background Red
bg_gr # Sets background Green
bg_ye # Sets background Yellow
bg_bl # Sets background Blue
bg_mg # Sets background Magenta
bg_cy # Sets background Cyan
bg_wh # Sets background White
bold# Bold
dim # Dim
underline # Underline
blink # Blink (this may not be implemented by your terminal)
invert # Invert
hidden # Hidden
reset_decorations # clear inherited decorations
These functions do not directly make any visible changes to the
terminal, rather that is left to the function:
decorate# applies configured decorations to the first argument
The decorate function looks at the currently configured decorations
(colours and attributes) and applies the necessary ANSI escape sequences
to tell the terminal how it's argument is to be rendered. If the
terminal doesn't support at least the standard 8 ANSI colours this
become a no-op and leaves the variable undecorated.
The result can then be sent to echo or print or wherever your heart
desires them to go (maybe Narnia!?).
Example:
# Apply foreground and background colours separately
rd
bg_ye
text1=$(decorate "this text is red ")
# Change the background colour
bg_mg
text2=$(decorate "but the background changes")
# Display the decorated text
echo "${text1}${text2}"
reset_decorations
This project was largely an educational evening for me in how ksh
scripting works, if people find it useful, cute or want to use it to
splash the rainbow all over their terminal, then please let me know what
you come up with.
Re: No login prompt on console ttyC0 after boot when using "set tty com0"
> -Original Message- > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf > Of Andrew Daugherity > > > > Hello > > I was wondering if there is anything I could do to help figure this > out. > > I do not have the requisite knowledge to even begin to understand why > the > > kernel does not configure the vga output when boot.conf redirects to > com0. > > Look for a "redirection after boot" setting in your BIOS and try > disabling that. The behavior you've described of both physical and > serial consoles working at the boot prompt _without_ 'set tty com0' > seems to indicate the BIOS is still handling redirection from > keyboard/video to serial, and my guess is that when OpenBSD > initializes the port for a serial console, it causes something in the > BIOS-linked local keyboard/vga to go wonky (wsdisplay at vga1 not > configured). Thanks for suggestion. The BIOS does, in fact, redirect output to both the local console and a serial console at startup. This makes the BIOS configuration available on the serial console and the local monitor. After the BIOS screen, if "set tty com0" is _not_ included, then the boot dmesg is displayed on the local monitor, the serial goes silent, and at the end of openBSD boot, a login prompt is available on both serial console and local monitor. If "set tty com0" is _set_, then, after the BIOS page shows on both the serial console and local monitor, the boot dmesg scrolls on the serial console, and then login prompt is available on the serial console. The local monitor shows the openBSD boot "redirecting" message, and then nothing more. At the end of boot, there is _no_ login prompt on the local monitor. If I _disable_ the BIOS serial redirection feature, but keep "set tty com0" _set_, I see the following: - the local monitor shows: BIOS screen, openBSD start text ending with "redirecting to...", and that is all. No login prompt at the end of boot - the serial console shows: _no_ BIOS screen, then the openBSD boot and dmesg information, and ends with a login prompt The only change which, apparently, disables the configuration of ttyC0 during/after boot is setting "set tty com0" in boot.conf. However, the local monitor is alive, since it gets the BIOS information and the initial openBSD boot message, which suggests that the BIOS is correctly recognizing the monitor/output early in the boot, but then openBSD is unable to configure it later. Again, the only change that seems to make a difference is setting "set tty com0" or not. The console redirection option in the BIOS for the pre-boot/BIOS information does not affect this. > > Note that in UEFI mode, "wsdisplay at vga1 not configured" would be > expected, as efifb takes over: > > $ dmesg|egrep 'wsdisplay|fb|vga|com[0-9]' > vga1 at pci7 dev 0 function 0 "Matrox MGA G200eR" rev 0x01 > wsdisplay at vga1 not configured > com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo > com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo > com1: console > efifb0 at mainbus0: 1280x1024, 32bpp > wsdisplay0 at efifb0 mux 1 > wsdisplay0: screen 0-5 added (std, vt100 emulation) > > You might give UEFI mode a try, to see if efifb works better than the > vga console. Redirection after boot is probably the more important > setting though. > The system is installed on one full disk openBSD partition. I believe (not 100% sure) that changing to UEFI would require a small EFI partition (which would mean changing the fdisk partition and disklabel without destroying the software RAID), which is not a challenge I can take on right now. But, I will keep it in mind. > Note that the login prompt appearing on a console (spawning a getty as > configured in /etc/ttys) and the bootloader/kernel console device are > independent settings. > Yes, which is my confusion. Both the serial console (tty00) and the local terminal (ttyC0) are set in ttys: head -n 20 /etc/ttys # # $OpenBSD: ttys,v 1.2 2008/01/09 17:39:42 miod Exp $ # # name getty typestatus comments # console "/usr/libexec/getty std.9600" vt220 off secure ttyC0 "/usr/libexec/getty std.9600" vt220 on secure ttyC1 "/usr/libexec/getty std.9600" vt220 on secure ... ttyCb "/usr/libexec/getty std.9600" vt220 off secure tty00 "/usr/libexec/getty autologin" vt220on secure tty01 "/usr/libexec/getty std.9600" unknown off (Note, the "autologin" type for getty is an addition in my gettytab which allows getty to spawn a login prompt that does not require the long, complex password to login when at the serial console.) > -Andrew Thanks Ted
Re: No login prompt on console ttyC0 after boot when using "set tty com0"
Hello I was wondering if there is anything I could do to help figure this out. I do not have the requisite knowledge to even begin to understand why the kernel does not configure the vga output when boot.conf redirects to com0. Not trying to be a bother. Thanks Ted > -Original Message- > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf > Of Ted Wynnychenko > Sent: Monday, June 27, 2022 8:55 AM > To: 'Stuart Henderson'; misc@openbsd.org > Subject: Re: No login prompt on console ttyC0 after boot when using > "set tty com0" > > > > > -Original Message- > > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On > Behalf > > Of Stuart Henderson > > Sent: Saturday, June 25, 2022 6:21 AM > > > On 2022-06-24, Ted Wynnychenko wrote: > > > Hello > > > > When there is a boot.conf file present in /etc with only the > > following: > > >> stty com0 115200 > > > > > > > So in this case the serial output during boot is only coming from a > > serial-port redirector in the bios, the "stty com0 115200" probably > > doesn't change anything, and the serial output in multiuser is via > > init / /etc/ttys > > > > > Now, if I change boot.conf to direct output to the serial terminal > > with: > > >> stty com0 115200 > > >> set tty com0 > > > > > So far that is expected, OpenBSD doesn't support dual serial+glass > > console > > > > > Then, the three wsconsctl error messages appear, and it ends with a > > login > > > prompt on the serial console (tty0) ONLY. > > > > > > The screen and keyboard for ttyC0 are dead. There is no login > > prompt, and > > > the keyboard is not functional. > > > > Assuming ttys is setup to run a login on ttyC0 that is not expected > > > > > > Can you try kernels between known-good and known-bad (or maybe you > have > > something in /var/log/messages*gz) and look for when this started > > appearing? > > > > Unfortunately, I have not checked the ttyC0 display in a long time. > When I was updating to current, I also did not specifically check for a > login prompt on ttyC0 BEFORE the update to current. > However, I think that I did notice that there was no login prompt when > I > plugged in the display, just before it switched to the bios pages. > My last update was in July 2021. > > > A diff of dmesg between serial and non-serial boots might give some > > clues > > > > This maybe implicated: > > > > >> vga1 at pci3 dev 3 function 0 "Matrox MGA G200eW" rev 0x0a > > >> wsdisplay at vga1 not configured > > > > I booted in three configurations. > With the boot.conf NOT including "set tty com0" AND a monitor and > keyboard > attached, dmesg shows: > 109,110c110 > < wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) > < wsdisplay0: screen 1-5 added (80x25, vt100 emulation) > 136c136 > < wskbd0 at pckbd0: console keyboard, using wsdisplay0 > 148d147 > < wskbd1: connecting to wsdisplay0 > 153d151 > < wskbd2: connecting to wsdisplay0 > > With boot.conf including "set tty com0" AND a monitor and keyboard > attached, > dmesg shows: > 62a63 > > com0: console > 109,110c110 > > wsdisplay at vga1 not configured > 136c136 > > wskbd0 at pckbd0 mux 1 > > When boot.conf including "set tty com0" and without a monitor or > keyboard, > the dmesg is the same as the "serial" dmesg with them connected, except > for > missing information about the keyboard: > 144,152d143 > < uhidev0 at uhub3 port 1 configuration 1 interface 0 "Primax > Electronics > USB Keyboard" rev 2.00/1.00 addr 3 > < uhidev0: iclass 3/1 > < ukbd0 at uhidev0: 8 variable keys, 6 key codes > < wskbd1 at ukbd0 mux 1 > < uhidev1 at uhub3 port 1 configuration 1 interface 1 "Primax > Electronics > USB Keyboard" rev 2.00/1.00 addr 3 > < uhidev1: iclass 3/0, 2 report ids > < ucc0 at uhidev1 reportid 1: 24 usages, 13 keys, enum > < wskbd2 at ucc0 mux 1 > < uhid0 at uhidev1 reportid 2: input=1, output=0, feature=0 > > > I don't know what this means. It seems that when boot.conf redirects > to the > com0 console, the vga connection does not get configured by OpenBSD on > boot. > That would explain why no login prompt is presented there later by > init, > even though the terminal is defined in ttys. > > Although it has been a few years, I feel certain that a login prompt > was > displayed on b
Re: No login prompt on console ttyC0 after boot when using "set tty com0"
> -Original Message- > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf > Of Stuart Henderson > Sent: Saturday, June 25, 2022 6:21 AM > On 2022-06-24, Ted Wynnychenko wrote: > > Hello > > When there is a boot.conf file present in /etc with only the > following: > >> stty com0 115200 > > > > So in this case the serial output during boot is only coming from a > serial-port redirector in the bios, the "stty com0 115200" probably > doesn't change anything, and the serial output in multiuser is via > init / /etc/ttys > > > Now, if I change boot.conf to direct output to the serial terminal > with: > >> stty com0 115200 > >> set tty com0 > > > So far that is expected, OpenBSD doesn't support dual serial+glass > console > > > Then, the three wsconsctl error messages appear, and it ends with a > login > > prompt on the serial console (tty0) ONLY. > > > > The screen and keyboard for ttyC0 are dead. There is no login > prompt, and > > the keyboard is not functional. > > Assuming ttys is setup to run a login on ttyC0 that is not expected > > > Can you try kernels between known-good and known-bad (or maybe you have > something in /var/log/messages*gz) and look for when this started > appearing? > Unfortunately, I have not checked the ttyC0 display in a long time. When I was updating to current, I also did not specifically check for a login prompt on ttyC0 BEFORE the update to current. However, I think that I did notice that there was no login prompt when I plugged in the display, just before it switched to the bios pages. My last update was in July 2021. > A diff of dmesg between serial and non-serial boots might give some > clues > > This maybe implicated: > > >> vga1 at pci3 dev 3 function 0 "Matrox MGA G200eW" rev 0x0a > >> wsdisplay at vga1 not configured > I booted in three configurations. With the boot.conf NOT including "set tty com0" AND a monitor and keyboard attached, dmesg shows: 109,110c110 < wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) < wsdisplay0: screen 1-5 added (80x25, vt100 emulation) 136c136 < wskbd0 at pckbd0: console keyboard, using wsdisplay0 148d147 < wskbd1: connecting to wsdisplay0 153d151 < wskbd2: connecting to wsdisplay0 With boot.conf including "set tty com0" AND a monitor and keyboard attached, dmesg shows: 62a63 > com0: console 109,110c110 > wsdisplay at vga1 not configured 136c136 > wskbd0 at pckbd0 mux 1 When boot.conf including "set tty com0" and without a monitor or keyboard, the dmesg is the same as the "serial" dmesg with them connected, except for missing information about the keyboard: 144,152d143 < uhidev0 at uhub3 port 1 configuration 1 interface 0 "Primax Electronics USB Keyboard" rev 2.00/1.00 addr 3 < uhidev0: iclass 3/1 < ukbd0 at uhidev0: 8 variable keys, 6 key codes < wskbd1 at ukbd0 mux 1 < uhidev1 at uhub3 port 1 configuration 1 interface 1 "Primax Electronics USB Keyboard" rev 2.00/1.00 addr 3 < uhidev1: iclass 3/0, 2 report ids < ucc0 at uhidev1 reportid 1: 24 usages, 13 keys, enum < wskbd2 at ucc0 mux 1 < uhid0 at uhidev1 reportid 2: input=1, output=0, feature=0 I don't know what this means. It seems that when boot.conf redirects to the com0 console, the vga connection does not get configured by OpenBSD on boot. That would explain why no login prompt is presented there later by init, even though the terminal is defined in ttys. Although it has been a few years, I feel certain that a login prompt was displayed on both the serial line and ttyC0 when I originally redirected output with "set tty com0" in boot.conf. I am pretty sure my detail orientated personality would have immediately flagged the discrepancy from what was documented if it had not, and I would have brought up the issue way back then. Thanks Ted > > > >> -Original Message- > >> From: Ted Wynnychenko > >> Sent: Thursday, June 23, 2022 5:19 PM > >> To: misc@openbsd.org > >> Subject: No login prompt on console ttyC0 after boot > >> > >> Hello > >> > >> I have been following current since 5.6, and had been pretty good > about > >> updates until this last year (issues not related). > >> > >> Anyway, I asked about updating, found some suggestions that it would > >> work, > >> and decided to blaze ahead. And, it basically worked. > >> I have a few things to clean up, but overall the update to current > from > >> my > >> last update in July 2021 went well. > >> > >> However, in planning for this, I decided to
Re: No login prompt on console ttyC0 after boot when using "set tty com0"
Hello I am leaving the original message intact below. I did some experimenting, and have found the following. When there is a boot.conf file present in /etc with only the following: > stty com0 115200 Then, the system will boot. At the INTIAL boot prompt, EITHER tty0 or ttyC0 will accept input (for example, a simple "enter" to skip the timeout), and will start the boot process. At that point, the serial terminal goes quiet, and boot messages are displayed on the ttyC0 monitor. At the end, a login prompt appears on BOTH the serial terminal, and on the ttyC0 display, and either can be used to login and access the system. Also, there are no wsconsctl errors generated, and the ttyC0 screen blanks after the appropriate time. Now, if I change boot.conf to direct output to the serial terminal with: > stty com0 115200 > set tty com0 Now, when the system boots, at the INITIAL boot prompt, ONLY the serial console (tty0) keyboard input works. The ttyC0 screen shows a final message "switching to com0," but it does not accept any keyboard input. The serial console still works, and the boot messages appear on it. Then, the three wsconsctl error messages appear, and it ends with a login prompt on the serial console (tty0) ONLY. The screen and keyboard for ttyC0 are dead. There is no login prompt, and the keyboard is not functional. I can see nothing in the man pages (boot/boot.conf, ttys, termcap, gettytab) that would explain this. In addition, when I first installed (at 5.6) both the local terminal (ttyC0) and the serial terminal (tty0) would present a login prompt. If there are any ideas about why this is happening, please let me know. Thanks Ted > -----Original Message- > From: Ted Wynnychenko > Sent: Thursday, June 23, 2022 5:19 PM > To: misc@openbsd.org > Subject: No login prompt on console ttyC0 after boot > > Hello > > I have been following current since 5.6, and had been pretty good about > updates until this last year (issues not related). > > Anyway, I asked about updating, found some suggestions that it would > work, > and decided to blaze ahead. And, it basically worked. > I have a few things to clean up, but overall the update to current from > my > last update in July 2021 went well. > > However, in planning for this, I decided to hook up a monitor and > keyboard > directly, as I have basically just used a serial console ever since I > first installed the systems at 5.6. > > Unfortunately, I did not look at the monitor before updating to current > (OpenBSD 7.1-current (GENERIC.MP) #587: Fri Jun 17 08:49:40 MDT 2022 - > full DMESG below), but after the update I found that there is no login > prompt on the monitor (ttyC0), and the keyboard does not do anything (I > cannot ALT-CTRL-F2 to change to another virtual console. > > I don't know when this happened, since I haven't attached a > monitor/keyboard in a very long time. > But, now that I know, I am trying to fix it, but can't seem to > understand > why/how to do so. > > When the machine boots, the monitor and keyboard work, and I can access > the bios pages and make changes. > > Then, if I allow the boot to start, I get the "switching to com0" > message, > and that's it. > > When the boot is complete, I can access the system using a serial > console > (tty00) or ssh, but the direct monitor shows nothing after "switching > to > com0," and the keyboard does nothing. > > The /etc/boot.conf file correctly routes things to the serial console: > stty com0 115200 > set tty com0 > > I have not changed /etc/ttys in a long time: > # > # $OpenBSD: ttys,v 1.2 2008/01/09 17:39:42 miod Exp $ > # > # name getty typestatus > comments > # > console "/usr/libexec/getty std.9600" vt220 off secure > ttyC0 "/usr/libexec/getty std.9600" vt220 on secure > ttyC1 "/usr/libexec/getty std.9600" vt220 on secure > ttyC2 "/usr/libexec/getty std.9600" vt220 on secure > ttyC3 "/usr/libexec/getty std.9600" vt220 on secure > ttyC4 "/usr/libexec/getty std.9600" vt220 off secure > ttyC5 "/usr/libexec/getty std.9600" vt220 on secure > ttyC6 "/usr/libexec/getty std.9600" vt220 off secure > ttyC7 "/usr/libexec/getty std.9600" vt220 off secure > ttyC8 "/usr/libexec/getty std.9600" vt220 off secure > ttyC9 "/usr/libexec/getty std.9600" vt220 off secure > ttyCa "/usr/libexec/getty std.9600" vt220 off secure > ttyCb "/usr/libexec/getty std.9600" vt220 off secure > tty00 "/usr/libexec/getty autologin" vt220on secure > tty01 "/usr
No login prompt on console ttyC0 after boot
Hello I have been following current since 5.6, and had been pretty good about updates until this last year (issues not related). Anyway, I asked about updating, found some suggestions that it would work, and decided to blaze ahead. And, it basically worked. I have a few things to clean up, but overall the update to current from my last update in July 2021 went well. However, in planning for this, I decided to hook up a monitor and keyboard directly, as I have basically just used a serial console ever since I first installed the systems at 5.6. Unfortunately, I did not look at the monitor before updating to current (OpenBSD 7.1-current (GENERIC.MP) #587: Fri Jun 17 08:49:40 MDT 2022 - full DMESG below), but after the update I found that there is no login prompt on the monitor (ttyC0), and the keyboard does not do anything (I cannot ALT-CTRL-F2 to change to another virtual console. I don't know when this happened, since I haven't attached a monitor/keyboard in a very long time. But, now that I know, I am trying to fix it, but can't seem to understand why/how to do so. When the machine boots, the monitor and keyboard work, and I can access the bios pages and make changes. Then, if I allow the boot to start, I get the "switching to com0" message, and that's it. When the boot is complete, I can access the system using a serial console (tty00) or ssh, but the direct monitor shows nothing after "switching to com0," and the keyboard does nothing. The /etc/boot.conf file correctly routes things to the serial console: stty com0 115200 set tty com0 I have not changed /etc/ttys in a long time: # # $OpenBSD: ttys,v 1.2 2008/01/09 17:39:42 miod Exp $ # # name getty typestatus comments # console "/usr/libexec/getty std.9600" vt220 off secure ttyC0 "/usr/libexec/getty std.9600" vt220 on secure ttyC1 "/usr/libexec/getty std.9600" vt220 on secure ttyC2 "/usr/libexec/getty std.9600" vt220 on secure ttyC3 "/usr/libexec/getty std.9600" vt220 on secure ttyC4 "/usr/libexec/getty std.9600" vt220 off secure ttyC5 "/usr/libexec/getty std.9600" vt220 on secure ttyC6 "/usr/libexec/getty std.9600" vt220 off secure ttyC7 "/usr/libexec/getty std.9600" vt220 off secure ttyC8 "/usr/libexec/getty std.9600" vt220 off secure ttyC9 "/usr/libexec/getty std.9600" vt220 off secure ttyCa "/usr/libexec/getty std.9600" vt220 off secure ttyCb "/usr/libexec/getty std.9600" vt220 off secure tty00 "/usr/libexec/getty autologin" vt220on secure tty01 "/usr/libexec/getty std.9600" unknown off tty02 "/usr/libexec/getty std.9600" unknown off tty03 "/usr/libexec/getty std.9600" unknown off tty04 "/usr/libexec/getty std.9600" unknown off tty05 "/usr/libexec/getty std.9600" unknown off tty06 "/usr/libexec/getty std.9600" unknown off tty07 "/usr/libexec/getty std.9600" unknown off I also noticed these errors in DMESG-S: ... /dev/sd2g (be3bcca0ef32a6bd.g): file system is clean; not checking wsconsctl: /dev/ttyC0: Device not configured wsconsctl: /dev/ttyC0: Device not configured wsconsctl: /dev/ttyC0: Device not configured pf enabled ... The wsconsctl.conf file has also not been changed in a long time, and only had three things enabled: display.vblank=on # enable vertical sync blank for screen burner display.screen_off=6# set screen burner timeout to 60 seconds display.kbdact=on # restore on keyboard input If I comment out the three parameters above, then "Device not configured" messages disappear, but there is still no login prompt on the ttyC0 monitor, and the keyboard still does not appear to function (I still cannot change virtual consoles). As far as I can tell, there should be a login prompt on ttyC0, but there is not. What am I missing? (Or, what did I miss when following current since 5.6 that may have changed?) Thanks Ted DMESG: OpenBSD 7.1-current (GENERIC.MP) #587: Fri Jun 17 08:49:40 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4249260032 (4052MB) avail mem = 4103114752 (3913MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb5a0 (55 entries) bios0: vendor American Megatrends Inc. version "2.3a" date 01/06/2021 bios0: Supermicro X9SCL/X9SCM acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT SSDT SPCR EINJ ERST HEST BERT acpi0: wakeup devices UAR1(S4) UAR2(S4) P0P1(S4) USB1(S4) USB2(S4) USB3(S4) USB4(S4) USB5(S4) USB6(S4) USB7(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4
Re: OpenBSD ftp and libtls: how to use session resumption with -S
On 2022-05-05, Ted Unangst wrote: > On 2022-05-05, Theo Buehler wrote: > > On Thu, May 05, 2022 at 10:59:45AM +0200, Hiltjo Posthuma wrote: > > > Is this option currently enabled and working? I haven't been able to see > > > session resumption being used when testing uses OpenBSD ftp. > > > > Yes, it works, but only with TLSv1.2. For TLSv1.3 this needs support for > > PSK, which is not currently implemented. > > Should we default to TLS 1.2 if the user requests session resumption and > doesn't otherwise specify version? Okay, I was a little confused. libtls already does this. If you request session support, it drops to tls 1.2. Everything seems fine.
Re: OpenBSD ftp and libtls: how to use session resumption with -S
On 2022-05-05, Theo Buehler wrote: > On Thu, May 05, 2022 at 10:59:45AM +0200, Hiltjo Posthuma wrote: > > Is this option currently enabled and working? I haven't been able to see > > session resumption being used when testing uses OpenBSD ftp. > > Yes, it works, but only with TLSv1.2. For TLSv1.3 this needs support for > PSK, which is not currently implemented. Should we default to TLS 1.2 if the user requests session resumption and doesn't otherwise specify version? I think that would make the option more immediately useful, and won't leave people stuck with an old version when support for 1.3 is added if they workaround.
Re: login.conf daemon datasize limit effects on VMs with 4GB+ RAM
On 2022-02-25, Robert Nagy wrote:
> Maybe we need a default vmd class? What do you guys think?
Regardless of what the limit is, this seems like a daemon where people
will bump into the limit. Perhaps a reminder is in order too?
Index: vm.c
===
RCS file: /cvs/src/usr.sbin/vmd/vm.c,v
retrieving revision 1.67
diff -u -p -r1.67 vm.c
--- vm.c30 Dec 2021 08:12:23 - 1.67
+++ vm.c25 Feb 2022 18:42:39 -
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -292,8 +293,12 @@ start_vm(struct vmd_vm *vm, int fd)
ret = alloc_guest_mem(vcp);
if (ret) {
+ struct rlimit lim;
+ const char *msg = "could not allocate guest memory - exiting";
+ if (getrlimit(RLIMIT_DATA, ) == 0)
+ msg = "could not allocate guest memory (data limit is
%llu) - exiting";
errno = ret;
- fatal("could not allocate guest memory - exiting");
+ fatal(msg, lim.rlim_cur);
}
ret = vmm_create_vm(vcp);
Re: Documentation error in pci_mapreg_probe(9)
On 2022-01-10 3:53 a.m., Jonathan Gray wrote: > On Mon, Jan 10, 2022 at 09:17:25PM +1100, Jonathan Gray wrote: >> On Mon, Jan 10, 2022 at 02:24:05AM -0700, Ted Bullock wrote: >>> >>> On 2022-01-10 2:18 a.m., Jonathan Gray wrote: >>>> On Sat, Jan 08, 2022 at 01:43:32PM -0700, Ted Bullock wrote: >>>>> The manpage incorrectly describes the behaviour and usage of >>>>> pci_mapreg_probe(9). This function does not return 0 for success and !0 >>>>> for failure as described in the manual, see the diff below for a >>>>> possible re-wording and corrected description. >>>> >>>> I agree the return value is wrong but your description introduces an >>>> error in that type bits can contain PCI_MAPREG_MEM_TYPE_64BIT for example. >>>> Which is something that the pci_mapreg_type text also gets wrong. >>>> >>>> How about this to start with? >>> >>> It certainly corrects the mechanical issue with the returns, it doesn't help >>> though with understanding how to use the function correctly though. Under >>> what circumstances will the type bits get set as you indicate? I wasn't at >>> all clear about that from peering through the call tree. >> >> as the define would suggest, when it is a 64-bit mem bar > > expanding on this some more Here is what I have written so far. I added what I found to be necessary to actually use the API not having used it in OpenBSD before. More experienced devs might just *know* this but as someone who had to try and understand what it was doing using just the manual and the source code this is what was missing for me. Index: share/man/man9/pci_mapreg_map.9 === RCS file: /cvs/src/share/man/man9/pci_mapreg_map.9,v retrieving revision 1.1 diff -u -p -r1.1 pci_mapreg_map.9 --- share/man/man9/pci_mapreg_map.9 23 Feb 2019 04:54:25 -0000 1.1 +++ share/man/man9/pci_mapreg_map.9 11 Jan 2022 04:12:32 - @@ -1,6 +1,7 @@ .\"$OpenBSD: pci_mapreg_map.9,v 1.1 2019/02/23 04:54:25 dlg Exp $ .\" .\" Copyright (c) 2019 David Gwynne +.\" Copyright (c) 2022 Ted Bullock .\" All rights reserved. .\" .\" Permission to use, copy, modify, and distribute this software for any @@ -15,7 +16,7 @@ .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF .\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. .\" -.Dd $Mdocdate: February 23 2019 $ +.Dd $Mdocdate: January 10 2022 $ .Dt PCI_MAPREG_MAP 9 .Os .Sh NAME @@ -50,19 +51,21 @@ .Fa "bus_size_t *sizep" .Fa "int *flagsp" .Fc -.Ft int -.Fo pci_mapreg_probe +.Ft pcireg_t +.Fo pci_mapreg_type .Fa "pci_chipset_tag_t pc" .Fa "pcitag_t tag" .Fa "int reg" -.Fa "pcireg_t *typep" .Fc -.Ft pcireg_t -.Fo pci_mapreg_type +.Ft int +.Fo pci_mapreg_probe .Fa "pci_chipset_tag_t pc" .Fa "pcitag_t tag" .Fa "int reg" +.Fa "pcireg_t *typep" .Fc +.Fd #define PCI_MAPREG_TYPE(type) +.Fd #define PCI_MAPREG_MEM_TYPE(type) .\" .Ft int .\" .Fo pci_mem_find .\" .Fa "pci_chipset_tag_t pc" @@ -85,7 +88,43 @@ These functions provide wrappers and helpers around .Xr bus_space 9 mappings for device registers described by the Base Address Registers -(BARs) in a PCI devices configuration space. +(BARs) in a PCI devices configuration space. There are 6 BARs located in the +pci address space at 0x10, 0x14, 0x18, 0x1C, 0x20 and 0x24. The addresses +stored in the PCI BARS are used to map IO and Memory Mapped device registers. +.Pp +BARS have a complex bitmap described a follows: +.TS +center,allbox; +cb s s +cb cb cb +cb s s +c r l +c r l +cb s s +c r l +^ r l +^ r l +c r l +^ r l +c r l +cb s s +c r l. +PCI BAR Bitmap +Bits Description Values +All PCI BARs +0 Type0 Memory +\^ \^ 1 I/O +Memory BARs +1-2Location00 Any 32-bit +\^ \^ 10 < 1MB +\^ \^ 11 Any 64-bit +3 Prefetchable0 No +\^ \^ 1 Yes +4-31 Base Address16-byte aligned +I/O BARs +1 Reserved\_ +2-31 Base Address4-byte aligned +.TE .Pp .Nm pci_mapreg_map wraps a call to @@ -124,29 +163,70 @@ and .Fa flagsp pointers. .Pp +.Nm pci_mapreg_type +returns the type of register access for the registers at the BAR +referenced by +.Fa reg . +.Pp .Nm pci_mapreg_probe attempts to determine if the BAR referenced by .Fa reg -describes a valid register mapping. +describes a valid register mapping. If it does, the register type will be +updated via the pointer +.Fa typep +matching those described for the return value of +.Nm pci_mapreg_type . +If the mapping is invalid the register type should not be used. +.Fa
Re: Documentation error in pci_mapreg_probe(9)
On 2022-01-10 3:53 a.m., Jonathan Gray wrote: > On Mon, Jan 10, 2022 at 09:17:25PM +1100, Jonathan Gray wrote: >> On Mon, Jan 10, 2022 at 02:24:05AM -0700, Ted Bullock wrote: >>> >>> On 2022-01-10 2:18 a.m., Jonathan Gray wrote: >>>> On Sat, Jan 08, 2022 at 01:43:32PM -0700, Ted Bullock wrote: >>>>> The manpage incorrectly describes the behaviour and usage of >>>>> pci_mapreg_probe(9). This function does not return 0 for success and !0 >>>>> for failure as described in the manual, see the diff below for a >>>>> possible re-wording and corrected description. >>>> >>>> I agree the return value is wrong but your description introduces an >>>> error in that type bits can contain PCI_MAPREG_MEM_TYPE_64BIT for example. >>>> Which is something that the pci_mapreg_type text also gets wrong. >>>> >>>> How about this to start with? >>> >>> It certainly corrects the mechanical issue with the returns, it doesn't help >>> though with understanding how to use the function correctly though. Under >>> what circumstances will the type bits get set as you indicate? I wasn't at >>> all clear about that from peering through the call tree. >> >> as the define would suggest, when it is a 64-bit mem bar Ok, then still missing from the document is the semantic distinctions between the return types and the correct usage for those types with pci_mapreg_info and pci_mapreg_map. There is also the undocumented PCI_MAPREG_TYPE and PCI_MAPREG_MEM_TYPE macros too: This usage should be incorrect? if (type == PCI_MAPREG_TYPE_MEM) I think correct form should be then if (PCI_MAPREG_TYPE(type) == PCI_MAPREG_TYPE_MEM) switch (PCI_MAPREG_MEM_TYPE(type)) PCI_MAPREG_MEM_TYPE_32BIT_1M: PCI_MAPREG_MEM_TYPE_32BIT: pci_mapreg_map for 32 bit bar PCI_MAPREG_MEM_TYPE_64BIT: pci_mapreg_map for 64 bit bar This pci stack doesn't also seem to handle pci devices with a 16 bit bar, but I also don't know if such devices actually exist so maybe this doesn't matter > expanding on this some more > > Index: pci_mapreg_map.9 > === > RCS file: /cvs/src/share/man/man9/pci_mapreg_map.9,v > retrieving revision 1.1 > diff -u -p -r1.1 pci_mapreg_map.9 > --- pci_mapreg_map.9 23 Feb 2019 04:54:25 - 1.1 > +++ pci_mapreg_map.9 10 Jan 2022 10:51:36 - > @@ -128,6 +128,11 @@ pointers. > attempts to determine if the BAR referenced by > .Fa reg > describes a valid register mapping. > +If it does > +.Fa typep > +will point to a value with flags matching those described for the return > value > +of > +.Nm pci_mapreg_type . > .Pp > .Nm pci_mapreg_type > returns the type of register access for the registers at the BAR > @@ -135,18 +140,22 @@ referenced by > .Fa reg . > .Sh RETURN VALUES > .Nm pci_mapreg_map , > -.Nm pci_mapreg_info , > and > -.Nm pci_mapreg_probe > +.Nm pci_mapreg_info > return 0 on success, or an > .Xr errno 2 > style value on failure. > .Pp > +.Nm pci_mapreg_probe > +returns 1 if if the BAR describes a valid mapping, 0 if not. > +.Pp > .Nm pci_mapreg_type > -returns either > -.Dv PCI_MAPREG_TYPE_IO > -or > -.Dv PCI_MAPREG_TYPE_MEM . > +returns a value with flags for type information. > +.Dv PCI_MAPREG_TYPE_IO , > +.Dv PCI_MAPREG_TYPE_MEM , > +.Dv PCI_MAPREG_MEM_TYPE_32BIT , > +.Dv PCI_MAPREG_MEM_TYPE_32BIT_1M and > +.Dv PCI_MAPREG_MEM_TYPE_64BIT . > .Sh SEE ALSO > .Xr pci 4 , > .Xr bus_space 9 , -- Ted Bullock
Re: Documentation error in pci_mapreg_probe(9)
On 2022-01-10 2:18 a.m., Jonathan Gray wrote: On Sat, Jan 08, 2022 at 01:43:32PM -0700, Ted Bullock wrote: The manpage incorrectly describes the behaviour and usage of pci_mapreg_probe(9). This function does not return 0 for success and !0 for failure as described in the manual, see the diff below for a possible re-wording and corrected description. I agree the return value is wrong but your description introduces an error in that type bits can contain PCI_MAPREG_MEM_TYPE_64BIT for example. Which is something that the pci_mapreg_type text also gets wrong. How about this to start with? It certainly corrects the mechanical issue with the returns, it doesn't help though with understanding how to use the function correctly though. Under what circumstances will the type bits get set as you indicate? I wasn't at all clear about that from peering through the call tree. Anyway it's certainly a weakness of the document. This at least stops the error from the return values. Index: pci_mapreg_map.9 === RCS file: /cvs/src/share/man/man9/pci_mapreg_map.9,v retrieving revision 1.1 diff -u -p -r1.1 pci_mapreg_map.9 --- pci_mapreg_map.923 Feb 2019 04:54:25 - 1.1 +++ pci_mapreg_map.910 Jan 2022 09:13:30 - @@ -135,12 +135,14 @@ referenced by .Fa reg . .Sh RETURN VALUES .Nm pci_mapreg_map , -.Nm pci_mapreg_info , and -.Nm pci_mapreg_probe +.Nm pci_mapreg_info return 0 on success, or an .Xr errno 2 style value on failure. +.Pp +.Nm pci_mapreg_probe +returns 1 if if the BAR is implemented, 0 if not. .Pp .Nm pci_mapreg_type returns either -- Ted Bullock
Documentation error in pci_mapreg_probe(9)
The manpage incorrectly describes the behaviour and usage of pci_mapreg_probe(9). This function does not return 0 for success and !0 for failure as described in the manual, see the diff below for a possible re-wording and corrected description. Index: share/man/man9/pci_mapreg_map.9 === RCS file: /cvs/src/share/man/man9/pci_mapreg_map.9,v retrieving revision 1.1 diff -u -p -r1.1 pci_mapreg_map.9 --- share/man/man9/pci_mapreg_map.9 23 Feb 2019 04:54:25 - 1.1 +++ share/man/man9/pci_mapreg_map.9 8 Jan 2022 20:36:07 - @@ -127,20 +127,34 @@ pointers. .Nm pci_mapreg_probe attempts to determine if the BAR referenced by .Fa reg -describes a valid register mapping. +describes a valid register mapping. If the mapping is valid the register type +will be updated via the pointer +.Fa *typep +to either +.Dv PCI_MAPREG_TYPE_IO +or +.Dv PCI_MAPREG_TYPE_MEM . +If the mapping is invalid the register type should not be used. +.Fa *typep +can be +.Dv NULL +if determining the register type is not desired. .Pp .Nm pci_mapreg_type returns the type of register access for the registers at the BAR referenced by .Fa reg . .Sh RETURN VALUES -.Nm pci_mapreg_map , -.Nm pci_mapreg_info , -and -.Nm pci_mapreg_probe -return 0 on success, or an +.Nm pci_mapreg_map and +.Nm pci_mapreg_info +return zero on success, or an .Xr errno 2 style value on failure. +.Pp +.Nm pci_mapreg_probe +returns zero when no register is found or one if it finds a +register at the BAR referenced by +.Fa reg . .Pp .Nm pci_mapreg_type returns either -- Ted Bullock
PCI configuration space documentation question
I'm reading pci_mapreg_type(9) and I'm wondering about the returns of this function. The documentation says it can return either PCI_MAPREG_TYPE_IO or PCI_MAPREG_TYPE_MEM. But I also see at least one driver checking the type for PCI_MAPREG_MEM_TYPE_64BIT Looking at the definitions of these in sys/dev/pci/pcireg.h I see the two defines listed above but also some others that seem specific to memory mapped registers. #define PCI_MAPREG_TYPE(mr) \ ((mr) & PCI_MAPREG_TYPE_MASK) #define PCI_MAPREG_TYPE_MASK0x0001 #define PCI_MAPREG_TYPE_MEM 0x #define PCI_MAPREG_TYPE_IO 0x0001 #define PCI_MAPREG_MEM_TYPE(mr) \ ((mr) & PCI_MAPREG_MEM_TYPE_MASK) #define PCI_MAPREG_MEM_TYPE_MASK0x0006 #define PCI_MAPREG_MEM_TYPE_32BIT 0x #define PCI_MAPREG_MEM_TYPE_32BIT_1M0x0002 #define PCI_MAPREG_MEM_TYPE_64BIT 0x0004 So, I am curious about the correct way to be using these, pci_mapreg_type(9) doesn't seem to light the way very far here. Please send help I'm in a maze of twisty little passages, all alike. -- Ted Bullock
Re: power of 2 revisited
On 2021-12-29 10:18 p.m., Jonathan Gray wrote:
> On Wed, Dec 29, 2021 at 09:27:34PM -0700, Ted Bullock wrote:
>> This is around documenting peculiar behaviour around power of 2 math in
>> the kernel.
>>
>> I'm wondering if it's worth documenting the peculiarities here, and
>> possibly putting an actually mathematically correct check somewhere in
>> the kernel or maybe userland? Perhaps hypothetical PEER REVIEWED
>> functions with prototypes like isnpotu(uint64_t n) or isnpot(int64_t n).
>>
>> Is this at all worthwhile? Maybe this would help stop people from
>> incorrectly reinventing the wheel?
>>
>> For instance in the kernel right now there is :
>> radeon_check_pot_argument
>> IS_POWER_OF_2
>> is_power_of_2
>> is_power_of_2_u64
>> powerof2
>> probably others too.
>
> IS_POWER_OF_2 and is_power_of_2_u64 are inteldrm specific
> is_power_of_2 is a linux interface.
>
> radeon_check_pot_argument should be replaced in linux by
> is_power_of_2.
> https://lists.freedesktop.org/archives/amd-gfx/2021-December/073108.html
>
> No code outside of drm should be using the linux interfaces and
> I don't think we should be documenting them.
I've taken some time to write what I believe is correct implementations
of the power of two tests for both signed and unsigned cases and written
a manual for both the original powerof2() macro and my functions. Unlike
the macro these actually give the correct response for 0 and INT_MIN. I
also performed a fairly extensive namespace collision search and didn't
find any function name collisions but this was not exhaustive.
The goal here is to provide a mathematically correct power of two test
and associated documentation. I put the new tests in sys/params.h
because the old (inaccurate) test from bsd 4.3 tahoe has the macro
there.
I deliberately did not correct the logic of the macro as per the thread
years ago here : https://marc.info/?t=14432152764=1=2
I used int for the return type though in the c99 era it could be bool I
suppose; maybe 23 years since that standard was published is too soon to
use bool. :P
I hope that people can use this. Please review.
I wrote a short test program to verify I'm not crazy as well. Here are
the results:
Calculating powers of two:
powerof2(INT_MIN): true
powerof2(-2): false
powerof2(0): true
powerof2(2): true
powerof2(4): true
powerof2(8): true
powerof2(16): true
powerof2(INT_MAX): false
isupow2(0): false
isupow2(2): true
isupow2(4): true
isupow2(8): true
isupow2(16): true
isupow2(77): false
isupow2(UINT_MAX): false
isnpow2(INT_MIN): false
isnpow2(-2): false
isnpow2(0): false
isnpow2(2): true
isnpow2(4): true
isnpow2(8): true
isnpow2(16): true
isnpow2(INT_MAX): false
Index: sys/sys/param.h
===
RCS file: /cvs/src/sys/sys/param.h,v
retrieving revision 1.135
diff -u -p -u -p -r1.135 param.h
--- sys/sys/param.h 19 Sep 2021 16:55:01 - 1.135
+++ sys/sys/param.h 31 Dec 2021 00:33:45 -
@@ -186,7 +186,17 @@
#definehowmany(x, y) (((x)+((y)-1))/(y))
#endif
#defineroundup(x, y) x)+((y)-1))/(y))*(y))
-#define powerof2(x)x)-1)&(x))==0)
+#definepowerof2(x) x)-1)&(x))==0)
+static inline int
+isupow2(uint64_t u)
+{
+ return ((u & (u - 1)) == 0) && (u != 0);
+}
+static inline int
+isnpow2(int64_t n)
+{
+ return ((n & (n - 1)) == 0) && (n > 0);
+}
/* Macros for min/max. */
#defineMIN(a,b) (((a)<(b))?(a):(b))
Also inline here is the complete text of the manual I wrote:
.\" Copyright (c) 2021 Ted Bullock
.\"
.\" Permission to use, copy, modify, and distribute this software for any
.\" purpose with or without fee is hereby granted, provided that the above
.\" copyright notice and this permission notice appear in all copies.
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
.\"
.Dd $\Mdocdate$
.Dt powerof2 3
.Os
.Sh NAME
.Nm powerof2
.Nm isupow2
.Nm is2pow2
.Nd tests integer for power of two
.Sh SYNOPSIS
.In sys/params.h
.Fd #define powerof2(x) x)-1)&(x))==0)
.Ft int
.Fo isupow2
.Fa "uint64_t"
.Fc
.Ft int
.Fo isnpow2
.Fa "int64_t"
.Fc
.Sh DESCRIPTION
These tests check if an integer value is a power of two.
.Pp
The
.Fn powerof2
macro expands to a l
power of 2 revisited
This started out as a direct question to Ingo, but I have readdressed it to misc@ This is around documenting peculiar behaviour around power of 2 math in the kernel. I noticed that in sys/dev/pci/drm/radeon/radeon_device.c:1137 there is a call to radeon_check_pot_argument, this function isn't correct in that it returns true for a value of zero (as you know, 0 is not a power of two). I sent a diff to Jonathan to correct the behaviour which he rejected because he doesn't want to add local changes to change behaviour which isn't hitting a bug here. Fair Enough. Then reading through old mail archives I came across this discussion from a few years back: https://marc.info/?t=14432152764=1=2 I'm wondering if it's worth documenting the peculiarities here, and possibly putting an actually mathematically correct check somewhere in the kernel or maybe userland? Perhaps hypothetical PEER REVIEWED functions with prototypes like isnpotu(uint64_t n) or isnpot(int64_t n). Is this at all worthwhile? Maybe this would help stop people from incorrectly reinventing the wheel? For instance in the kernel right now there is : radeon_check_pot_argument IS_POWER_OF_2 is_power_of_2 is_power_of_2_u64 powerof2 probably others too. And manual checks like sys/arch/amd64/amd64/identcpu.c:804 powerof2 = ((x - 1) & x) == 0; -- Ted Bullock
MariaDB in current - fatal error with clients "utf8 is not supported by MySQL"
value of the old_mode system variable." I tried running mysqld/mariadb with "--old-mode UTF8_IS_UTF8MB3" but the error is the same (not surprising). According the MariaDB website, there should be a "utf8" character set available as an alias. But, it is not listed as on option on the mariadb version running on openbsd. I would have no idea how to update php scripts to change the character set they are specifying when the try to interact with mysqld, so I am wondering if there is a way to add back an "utf8" character set (as an alias for utf8mb3) into MariaDB? I hope this makes some sense. Any advice would be great. Thanks Ted
DDclient in curent seems to work but ends with "FAILED" and errors
Hello I updated to the current -current a few days ago. Since then, I noticed that ddclient (installed from packages - version 3.9.1) started complaining with the message: WARNING: found neither ipv4 nor ipv6 address When I tried running ddclient directly, it seems to work but end with some error messages, and a final "FAILED" notice: # /usr/local/sbin/ddclient -force -verbose CONNECT: checkip.dyndns.org CONNECTED: using HTTP SENDING: GET / HTTP/1.0 SENDING: Host: checkip.dyndns.org SENDING: User-Agent: ddclient/3.9.1 SENDING: Connection: close SENDING: SENDING: RECEIVE: HTTP/1.1 200 OK RECEIVE: Date: Wed, 21 Jul 2021 15:41:49 GMT RECEIVE: Content-Type: text/html RECEIVE: Content-Length: 103 RECEIVE: Connection: close RECEIVE: Cache-Control: no-cache RECEIVE: Pragma: no-cache RECEIVE: RECEIVE: Current IP CheckCurrent IP Address: xx.xx.xx.xx INFO: forcing update of host.tld.com. Use of uninitialized value in concatenation (.) or string at /usr/local/sbin/ddclient line 2353. INFO: setting IP address to xx.xx.xx.xx for host.tld.com UPDATE: updating host.tld.com CONNECT: dynamic.zoneedit.com CONNECTED: using SSL SENDING: GET /auth/dynamic.html?host=host.tld.com = xx.xx.xx.xx HTTP/1.0 SENDING: Host: dynamic.zoneedit.com SENDING: Authorization: Basic [key] SENDING: User-Agent: ddclient/3.9.1 SENDING: Connection: close SENDING: SENDING: RECEIVE: HTTP/1.1 200 OK RECEIVE: Date: Wed, 21 Jul 2021 15:41:49 GMT RECEIVE: Server: Apache RECEIVE: Set-Cookie: PHPSESSID=cookie; path=/ RECEIVE: Expires: Thu, 19 Nov 1981 08:52:00 GMT RECEIVE: Cache-Control: no-store, no-cache, must-revalidate RECEIVE: Pragma: no-cache RECEIVE: Vary: Accept-Encoding RECEIVE: Content-Length: 209 RECEIVE: Connection: close RECEIVE: Content-Type: text/html; charset=UTF-8 RECEIVE: RECEIVE: RECEIVE: SUCCESS: updating host.tld.com: IP address set to xx.xx.xx.xx (201: no update required for host.tld.com to xx.xx.xx.xx) Use of uninitialized value $h in hash element at /usr/local/sbin/ddclient line 3319. Use of uninitialized value $h in hash element at /usr/local/sbin/ddclient line 3320. Use of uninitialized value $h in hash element at /usr/local/sbin/ddclient line 3321. Use of uninitialized value $_[0] in sprintf at /usr/local/sbin/ddclient line 1771. SUCCESS: updating : IP address set to xx.xx.xx.xx (200: host.tld.com updated to xx.xx.xx.xx) FAILED:was not updated because protocol is not supported. If I take a copy of the ddclient (version 3.8.3) script from 6.6 stable and put it in place of the -current version, it works without a problem. I don't know how to investigate this further, but am happy to help with direction. At this point, I am just leaving the older script in place. Thanks Ted
openbsd 6.9 release and current radeondrm boot fail
I have an inconsistent issue where MOST times I cannot fully boot with radeondrm enabled. When the booting kernel switches to a driver supported display with higher resolution I lose the display. I have a Radeon HD 5770 installed, and the dmesg seems to say CYPRESS. This doesn't seem correct. When boot fails the last line I see before losing display is: radeondrm0: CYPRESS Snapshot dmesg from successful boot with radeondrm enabled: OpenBSD 6.9-current (GENERIC.MP) #29: Fri May 21 13:20:08 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4276682752 (4078MB) avail mem = 4131631104 (3940MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xf06e0 (74 entries) bios0: vendor American Megatrends Inc. version "2402" date 01/06/2010 bios0: ASUSTeK Computer INC. M4A79T Deluxe acpi0 at bios0: ACPI 3.0 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG OEMB HPET SSDT acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4) PCE7(S4) PCE9(S4) PCEA(S4) PCEB(S4) PCEC(S4) SBAZ(S4) UAR1(S4) P0PC(S4) UHC1(S4) UHC2(S4) UHC3(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Phenom(tm) II X4 965 Processor, 3412.06 MHz, 10-04-03 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,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu0: AMD erratum 721 detected and fixed cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 200MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Phenom(tm) II X4 965 Processor, 3411.64 MHz, 10-04-03 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,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu1: AMD erratum 721 detected and fixed cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD Phenom(tm) II X4 965 Processor, 3411.64 MHz, 10-04-03 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,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC cpu2: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu2: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu2: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu2: AMD erratum 721 detected and fixed cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD Phenom(tm) II X4 965 Processor, 3411.64 MHz, 10-04-03 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE 3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MA SSE,3DNOWP,OSVW,IBS,SKINIT,ITSC cpu3: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu3: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu3: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu3: AMD erratum 721 detected and fixed cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318180 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 4 (PCE2) acpiprt2 at acpi0: bus -1 (PCE3) acpiprt3 at acpi0: bus -1 (PCE4) acpiprt4 at acpi0: bus -1 (PCE5) acpiprt5 at acpi0: bus 3 (PCE6) acpiprt6 at acpi0: bus 2 (PCE7) acpiprt7 at acpi0: bus -1 (PCE9) acpiprt8 at acpi0: bus -1 (PCEA) acpiprt9 at acpi0: bus -1 (PCEB) acpiprt10 at acpi0: bus -1 (PCEC) acpiprt11 at acpi0: bus 1 (P0PC) acpipci0 at acpi0 PCI0 acpicmos0 at acpi0 aibs0 at acpi0 RTMP RVLT RFAN GGRP GITM SITM aibs0: TSIF: 0: not a nameref: 257 type aibs0: TSIF: 1: not a nameref: 257 type aibs0: FSIF: 0: not a nameref: 257 type aibs0: FSIF: 1: not a nameref: 257 type aibs0: FSIF: 2: not a nameref: 257 type
Re: TOFU/cert pinning in libtls
On 2020-05-09, Bob Beck wrote: > > oolong$ man -k Xr=tls_peer_cert_hash > > nc(1) - arbitrary TCP and UDP connections and listens > > > > That's far from ideal IMO, but I don't know where, of the many tls_* > > manpages, would I reference it. > > man tls_peer_cert_hash > > happily brings up the man page on my machines. For reference, the relevant quote from tls_init: The properties of established TLS connections can be inspected with the functions described in tls_conn_version(3) and tls_ocsp_process_response(3). It's just one line and may be easy to pass over, but it is there.
Re: mounting ext3 using doas
dmthomp...@gmx.com wrote: > So I tried doas with this "permit nopass me as root cmd mount_ext2fs" > but still no luck. > > So I was hoping for a hand from you kind souls. > > Oh and when I try to mount at command line using doas I get 'syntax error at > line > 7' there's nothing wrong with that line, suggesting the error is on line 7 instead.
Re: DNS lookups on a different port for testing?
Claus Assmann wrote: > The functional tests for sendmail use ldns-testns as DNS server > which provides specific test data and error behaviours. > It runs on a port > 1024 to avoid requiring root access. you can use a combination of pf.conf rdr-to and 127.0.0.2 etc. i.e., bind to port 5353, have pf rdr 127.0.0.2:53 to 5353. this requires root to setup, but not afterwards.
Re: How do I change the birth time of a file?
Duncan Patton a Campbell wrote: > > The change time (c_time in struct stat) cannot be explicitly set by > > any API and is maintained by the kernel. > > man touch ? does not set ctime except as a side effect.
Re: sysupgrade woes on beaglebone black
Jan Stary wrote: > Installing base66.tgz 100% |**| 99116 MB - 07:12edT- > Installing comp66.tgz 83% |* | 45312 KB - > stalledT-syncing disks... done > rebooting... > > Why does it reboot here? The SD card is slow, and is being both read > and written at this point, but even if it stalled the installer horribly, > it would not reboot, right? there's a watchdog timeout that reboots. I believe there was a bug fixed after 6.6 to reset it if progress is being made.
Re: httpd redirect
Thomas wrote: > Hi, > > I need to do this redirect with httpd: > > from: > http://my.old.site/#info > to: > https://my.new.site/products/product.html browsers don't send #fragments to the server. so short answer: impossible.
Re: urtwn(4) gets wedged periodically
Brennan Vincent wrote: > > On 11/13/19 1:56 AM, Ted Unangst wrote: > > Brennan Vincent wrote: > >> Hello, > >> > >> I have a Wi-Fi USB adapter. urtwn(4) normally works fine, but it's a bit > >> flaky... > >> I don't think this is a hardware issue because the device is > >> working fine on Ubuntu. > > I think this is and isn't a hardware issue? I had the same problem with an > > edimax a few years ago. I lost it and recently replaced it with a TP Link > > model and it works a little better? > > > > There doesn't seem to be much variation in hardware designs, but I noticed > > the old one was frequently very hot, and the new one is not. > Ah, I think I am in a similar boat. Mine is an Edimax also, and it does > frequently get hot. > > Can you give me the exact model of the one you bought recently? I have > half a mind to just write > off mine as a loss and buy something else. I am using this one: (the TL-WN725N N150 single band one) https://www.amazon.com/TP-Link-wireless-network-Adapter-SoftAP/dp/B008IFXQFU/
Re: urtwn(4) gets wedged periodically
Brennan Vincent wrote: > Hello, > > I have a Wi-Fi USB adapter. urtwn(4) normally works fine, but it's a bit > flaky... > I don't think this is a hardware issue because the device is > working fine on Ubuntu. I think this is and isn't a hardware issue? I had the same problem with an edimax a few years ago. I lost it and recently replaced it with a TP Link model and it works a little better? There doesn't seem to be much variation in hardware designs, but I noticed the old one was frequently very hot, and the new one is not.
Re: inteldrm changes cause high temperature / fan speeds (was: Downgrade 6.6 to 6.5)
Tero Koskinen wrote: > Eventually I pinned the problem down to April 14/15: > > FAULTY 091f8f6587f dlg Mon Apr 15 02:59:41 2019 + the myx_cmd > FAULTY 1bbcb699ab8 dlg Mon Apr 15 00:28:29 2019 + there's a bunch > PROBLEM! 7f4dd37977d jsg Sun Apr 14 10:14:50 2019 + Update shared > drm code > OK 505701c75b3 visa Sun Apr 14 08:51:31 2019 + Add lock > > I must admit that I don't have yet any idea how to fix > the problematic commit (or what is actually wrong there). This is not too surprising. It's still a bit of a mystery what's different between machines that behave fine and those that don't. I have the same machine, and it's never been problematic. I note I'm at the same old bios I had when I first purchased it. bios0: vendor LENOVO version "N23ET61W (1.36 )" date 01/17/2019 And there are some other bios options, regarding bios/efi and thunderbolt and suspend that can be set one way or the other. I have everything turned down to whatever the "oldest" settings are. CMS boot, etc.
Re: this assembly example works in linux, netbsd - but not in openbsd, why?
Guild Navigator wrote: > But what would be the OpenBSD correct way to > write such simple print-from-the-array-of-strings program? printf
Re: question about man starttls and linking to cert.pem
freda_bundc...@nym.hush.com wrote: > Description: > man starttls says one can link a new certificate to cert.pem with > ln -s /etc/ssl/mail.example.com.crt /etc/ssl/cert.pem if one does not > intend That entire section seems dumb and outdated. I would prefer we simply not give any advice here. Users can figure out what they need to do. Installing the public cert needs to be done on many other machines, not just the one where it's generated. Index: starttls.8 === RCS file: /home/cvs/src/share/man/man8/starttls.8,v retrieving revision 1.26 diff -u -p -r1.26 starttls.8 --- starttls.8 27 Jun 2018 05:39:02 - 1.26 +++ starttls.8 11 Aug 2019 02:20:01 - @@ -102,18 +102,6 @@ with the following command: .Pp .Dl # openssl x509 -in /etc/ssl/mail.example.com.crt -text .Pp -If you don't intend to use TLS for authentication (and if you are using -self-signed certificates you probably don't) you can simply link -your new certificate to -.Pa cert.pem : -.Pp -.Dl # ln -s /etc/ssl/mail.example.com.crt /etc/ssl/cert.pem -.Pp -If, on the other hand, you intend to use TLS for authentication -you should add your certificate authority bundle to -.Pa /etc/ssl/cert.pem -(or whatever your software expects). -.Pp Because the private key files are unencrypted, MTAs can be picky about using tight permissions on those files. The certificate directory and the files therein should be
Re: Filesystem corruption on OpenBSD routers after power outage?
Theo de Raadt wrote: > How does sync() fix this? Please explain this. Look at the source > code. > > sync() is an asyncronous call requesting syncronization, and once > it has marked the blocks that should be pushed, it returns before > the work has been done. Ah, indeed. > > 2. cp could do an fsync call. There was a thread about this a while ago? > > How does fsync fix this? What if it returns an error. What do you do next. > Should cp spin until fsync returns non-error, or what should it do. Exit with an error? Same as if it got EIO or ENOSPC from a write? Then the command chain will stop before the mv.
Re: Filesystem corruption on OpenBSD routers after power outage?
Mogens Jensen wrote: > Even after many tries, I have not yet been able to corrupt the > filesystem so fsck cannot repair it without manual intervention. > However, if power is removed while the 'reorder_kernel' script runs, > the system will become completely unbootable. I could do this multiple > times. The new kernel is installed like this: umask 077 && cp bsd /nbsd && mv /nbsd /bsd So a crash during compilation or linking shouldn't affect reboot. However, there's a window between cp and mv where some of the new kernel may reside in unwritten dirty buffers. Then mv will rewrite the directory entry. A crash at this point will leave you with a broken kernel. A few possible fixes. 1. Insert a sync call in there. Kinda heavyweight, but works. 2. cp could do an fsync call. There was a thread about this a while ago? 3. mv could do the fsync instead, to make sure it doesn't move incomplete files.
Re: Debug Tool for golang
Kevin Chadwick wrote: > Does anyone debug golang on OpenBSD and can advise on llvm/gcc or provide any > other insight? I just use log.
Re: Criteria for errata
Jeremy O'Brien wrote: > I've snagged the 6.5 xenocara.tar.gz, patched it with just that above fix, > and installed it on my system which has made X rock-stable for me. This is > totally fine for me personally, but I was curious if other people have run > into this issue on their 6.5 installs, and if so, is this something worth > pushing a reliability errata out for? I'm unfamiliar with how the process > traditionally works so please excuse me if the question is outlandish. security issues and major reliability issues. but we try not to spend all our time making errata. that fix may be a contender. depends on how widely reported it is.
Re: `man 2 sysctl` issue
Kent Watsen wrote: > But when using sysctl(8) or /etc/sysctl.conf, a couple variables need an > extra 'm': > > semni --> semmni > semnu --> semmnu > > Is this intentional? The extra letters are intentional. I've fixed the man page. Thanks.
Re: signify(1) signatures with a YubiHSM
Jason A. Donenfeld wrote: > I'm using signify(1) for update signatures in the upcoming WireGuard for > Windows (there'll be OpenBSD news soon in that department, I hope!). Not > wanting to store keys on my laptop or something, I managed to get a YubiHSM > to produce valid signify(1) signatures. I thought I should document that > somewhere, so here goes. Excuse the bashisms, coreutilsisms, and assume > we're working inside a tmpfs. oh nice. I'm glad this is at least possible with some effort.
Re: User who invoke doas
Nick Holland wrote: > > In a shell script invoked by doas, is it possible to find which user > > invoke the script? my search a the moment has come up empty. > > most likely place would be an environment variable, right? > > # echo "I started out as $LOGNAME" > I started out as nick Note that LOGNAME and other variables can be set by the user to indicate a different user name. $ env LOGNAME=somebody doas sh -c 'echo $LOGNAME' somebody
Re: authentication methods: how do they work?
Boris Epstein wrote: > Thanks. It makes sense to be able to select login methods under some > circumstances - but do I have an option of forcing the user to log in using > a predetermined set of methods (for instance, password and then a secure > key, or password and Yubkey, or password and SSL key)? If you want to require two methods, you have to specify a combined method, with an appropriate utility in /usr/libexec/auth. This is tricky because the API only allows for one challenge/response, not a series of them. (Unless I'm mistaken.)
Re: Is there a fix for stock vi's bug-for-bug compatible ESC-equals-return feature?
ropers wrote: > I personally agree with Sijmen. OpenBSD has always prioritised > correctness over legacy compatibility and standards compliance. > Instinctively, leaving a slightly "buggy" thing in base on the theory > that anyone who doesn't like it should just install larger and less > scrutinised code from ports feels wrong. That you do not like it does not make it incorrect. As you have discovered, all of the existing documentation for vi says this is what it does. Changing behavior would make us incorrect.
Re: Is there a fix for stock vi's bug-for-bug compatible ESC-equals-return feature?
I think the answer is, you want traditional vi, you get traditional vi. If you want something else, try ports.
Re: emmc support on Ubiquiti Networks UniFi Security Gateway PRO-4
Diana Eichert wrote: > If so, is there a good way to dump existing factory firmware from emmc > before I install OpenBSD? At some point I may have to restore to > factory. Assuming you netboot bsd.rd, there's dd on the ramdisk. Alas, no netcat, but it does have the nfs client, so you can save the disk image that way.
Re: gdb: DW_TAG_ (abbrev = 85, offset = 20161909)
Claus Assmann wrote: > Any suggestion how I can debug that program? (it's huge and written > in C++ with which I am not familiar anyway :-( You want egdb from ports, especially for anything c++. (pkg_add gdb)
Re: easy todo: timespeccmp.3
Ingo Schwarze wrote: > Hi Ted, > > Ted Unangst wrote on Wed, Feb 06, 2019 at 02:25:40PM -0500: > > > We are missing a man page for timespeccmp (and related macro functions). > > should be pretty easy to grab a page from freesd, adapt it a bit, and > > make a patch if anybody is looking for something to do. > > Cheloha@ already took care of that and sent a patch on Jan 31, > and he got an OK from jmc@; probably, i should have replied, too, > but somehow it slipped. He should probably just put it in, which > will make it easier to fix the remaining quirks in tree, if any. oh, indeed. see how easy that was? :) ok from me too please.
easy todo: timespeccmp.3
We are missing a man page for timespeccmp (and related macro functions). It should be pretty easy to grab a page from freesd, adapt it a bit, and make a patch if anybody is looking for something to do.
Re: Use xenodm like startx?
John Ankarström wrote: > Hi, > > I just got OpenBSD installed on my new laptop, and so far, it works great. > But since I applied the latest X11 patch, I can no longer use startx to > launch X11, unless I do it as root, which probably isn’t a good idea. Seems > like I have to use xenodm. > > The thing is, xenodm is so complicated in comparison to a simple .xinitrc + > startx. There are so many files I need to set up that I hardly know where to > begin. > > I don’t want a login screen, I don’t want X11 to launch at startup. I just > want to start X manually from a simple .xinitrc. Surely I can’t be alone. You can look for the "running Xorg without root" thread on tech from a few weeks ago.
Re: doas called multiple times hangs
Ted Unangst wrote: > Dariusz Sendkowski wrote: > > Yes, it does. > > > > I extracted 'unveilcommands' function from doas.c and put it into a > > standalone program to run it. > > It turned out the result was the same as in doas command. When I disable > > unveil, then it works fine. > > This diff should fix the problem. Actually, miscalculation. This is a better diff. Sorry for the trouble. Against current, but should be adaptable to stable. Index: vfs_syscalls.c === RCS file: /cvs/src/sys/kern/vfs_syscalls.c,v retrieving revision 1.310 diff -u -p -r1.310 vfs_syscalls.c --- vfs_syscalls.c 3 Jan 2019 21:52:31 - 1.310 +++ vfs_syscalls.c 21 Jan 2019 04:57:17 - @@ -92,6 +92,7 @@ int dofutimens(struct proc *, int, struc int dounmount_leaf(struct mount *, int, struct proc *); int unveil_add(struct proc *, struct nameidata *, const char *); void unveil_removevnode(struct vnode *vp); +void unveil_free_traversed_vnodes(struct nameidata *); ssize_t unveil_find_cover(struct vnode *, struct proc *); struct unveil *unveil_lookup(struct vnode *, struct proc *, ssize_t *); @@ -911,7 +912,7 @@ sys_unveil(struct proc *p, void *v, regi nd.ni_pledge = PLEDGE_UNVEIL; if ((error = namei()) != 0) - return (error); + goto end; /* * XXX Any access to the file or directory will allow us to @@ -948,6 +949,10 @@ sys_unveil(struct proc *p, void *v, regi vrele(nd.ni_vp); if (nd.ni_dvp && nd.ni_dvp != nd.ni_vp) vrele(nd.ni_dvp); + + pool_put(_pool, nd.ni_cnd.cn_pnbuf); +end: + unveil_free_traversed_vnodes(); return (error); } Index: kern_unveil.c === RCS file: /cvs/src/sys/kern/kern_unveil.c,v retrieving revision 1.22 diff -u -p -r1.22 kern_unveil.c --- kern_unveil.c 17 Jan 2019 03:26:19 - 1.22 +++ kern_unveil.c 21 Jan 2019 05:01:26 - @@ -630,8 +630,6 @@ unveil_add(struct proc *p, struct nameid done: if (ret == 0) unveil_add_traversed_vnodes(p, ndp); - unveil_free_traversed_vnodes(ndp); - pool_put(_pool, ndp->ni_cnd.cn_pnbuf); return ret; }
Re: doas called multiple times hangs
Dariusz Sendkowski wrote: > Yes, it does. > > I extracted 'unveilcommands' function from doas.c and put it into a > standalone program to run it. > It turned out the result was the same as in doas command. When I disable > unveil, then it works fine. This diff should fix the problem. Index: kern_unveil.c === RCS file: /cvs/src/sys/kern/kern_unveil.c,v retrieving revision 1.22 diff -u -p -r1.22 kern_unveil.c --- kern_unveil.c 17 Jan 2019 03:26:19 - 1.22 +++ kern_unveil.c 21 Jan 2019 01:31:23 - @@ -630,8 +630,6 @@ unveil_add(struct proc *p, struct nameid done: if (ret == 0) unveil_add_traversed_vnodes(p, ndp); - unveil_free_traversed_vnodes(ndp); - pool_put(_pool, ndp->ni_cnd.cn_pnbuf); return ret; } Index: vfs_syscalls.c === RCS file: /cvs/src/sys/kern/vfs_syscalls.c,v retrieving revision 1.310 diff -u -p -r1.310 vfs_syscalls.c --- vfs_syscalls.c 3 Jan 2019 21:52:31 - 1.310 +++ vfs_syscalls.c 21 Jan 2019 01:29:38 - @@ -92,6 +92,7 @@ int dofutimens(struct proc *, int, struc int dounmount_leaf(struct mount *, int, struct proc *); int unveil_add(struct proc *, struct nameidata *, const char *); void unveil_removevnode(struct vnode *vp); +void unveil_free_traversed_vnodes(struct nameidata *); ssize_t unveil_find_cover(struct vnode *, struct proc *); struct unveil *unveil_lookup(struct vnode *, struct proc *, ssize_t *); @@ -948,6 +949,8 @@ sys_unveil(struct proc *p, void *v, regi vrele(nd.ni_vp); if (nd.ni_dvp && nd.ni_dvp != nd.ni_vp) vrele(nd.ni_dvp); + unveil_free_traversed_vnodes(); + pool_put(_pool, nd.ni_cnd.cn_pnbuf); return (error); }
Re: doas called multiple times hangs
Dariusz Sendkowski wrote:
> I investigated the problem a little more and found, that when there is a
> non-existent directory entry in my PATH, the problem occurs. If all of the
> directories from my PATH exist, then it works fine.
To help isolate the problem, if you disable unveil, does it work?
Index: doas.c
===
RCS file: /cvs/src/usr.bin/doas/doas.c,v
retrieving revision 1.74
diff -u -p -r1.74 doas.c
--- doas.c 17 Jan 2019 05:35:35 - 1.74
+++ doas.c 20 Jan 2019 21:30:55 -
@@ -409,8 +409,6 @@ main(int argc, char **argv)
if (setenv("PATH", safepath, 1) == -1)
err(1, "failed to set PATH '%s'", safepath);
}
- if (unveilcommands(getenv("PATH"), cmd) == 0)
- goto fail;
if (pledge("stdio rpath getpw exec id", NULL) == -1)
err(1, "pledge");
Re: Backlight on Dell Laptop not adjusting brightness
Paul Swanson wrote: > $ wsconsctl display.brightness=5 > display.brightness -> 5.00% > > This laptop is essentially all Intel Skylake under the hood some I'm wondering > why it's not playing nice like on the Lenovo / ThinkPads. > > Below is my dmesg and also Xorg.0.log. > "DELLABC6" at acpi0 not configured > "DELLABCE" at acpi0 not configured > "INT3400" at acpi0 not configured > acpivideo0 at acpi0: GFX0 > acpivout0 at acpivideo0: LCD_ I went back and reread this. In theory, acpivout should support backlight control. That's another place to look and see what's really happening.
Re: Backlight on Dell Laptop not adjusting brightness
Paul Swanson wrote: > I'd like to chase this up a bit further and see if there's anything I can do > to > improve support on this model; Ubuntu has great support so I can perhaps look > for there for ideas and inspiration. > > Ted, do you have any suggestions for what parts of OpenBSD I should be > looking at > to improve support for these keys and functions? If you look in src/sys/dev/acpi you will see acpithinkpad.c which has functions for a bunch of getters and setters and buttons, etc. If you look in linux, there's going to be a similar file somewhere, and next to it will be an acpidell.c file which will have some magic numbers in it... This is all pretty hands on stuff.
Re: Backlight on Dell Laptop not adjusting brightness
Paul Swanson wrote: > This laptop is essentially all Intel Skylake under the hood some I'm wondering > why it's not playing nice like on the Lenovo / ThinkPads. There's no guarantee that the screen backlight is actually wired to the graphics chip and not just some acpi buttons. :( > I'd really appreciate any advice on what I can try next, it's my first time > running OpenBSD as my main system and I'm really enjoying it so far. Does it work at the bootloader, before the kernel runs?
Re: Porting some software to OpenBSD
Adam Steen wrote:
> 'log(DEBUG, "Solo5: clock_init(): freq=%lu\n", freq);'
>
> but am getting the following error
>
> '
> error: format specifies type 'unsigned long' but the argument has type
> 'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat]
> freq);
> ^~~~
> 1 error generated.
> '
>
> The easy fix is to change the format to '%llu', but this brakes FreeBSD and
> Linux. Am i missing something or should i be investigating the log
> implementation?
The easy fix is log("%llu", (long long)freq) which should work everywhere.
Re: netstat *:* udp sockets
Sebastian Benoit wrote: > > > or what should it show? Only sockets that are bound > > > but not connected (local port != 0 but remote addr/port = 0)? > > > > see my other mail for that diff. > > here. Ok for one or the other? as a non expert, this matches my expectation of what "listening" would map onto for udp. ok fwiw.
Re: netstat *:* udp sockets
Claudio Jeker wrote: > On Fri, Dec 14, 2018 at 01:26:25PM -0500, Ted Unangst wrote: > > Philip Guenther wrote: > > > And, perhaps more directly, how would I block this in pf.conf? > > > > > > > > > > Excellent choice, blocking dhclient from receiving the leases that it > > > requests. > > > "What problem are you trying to solve?" > > > > Well, this may be something of a lost cause, but I would prefer that chrome > > not listen for stuff I don't understand. It listens on port 5353 as well, > > for > > mDNS, and I can block that easily enough. It's the socket without a port > > that's giving me trouble. > > But a socket without a port is not listening on anything. It will not get > any packets. It does not need to be filtered. This is how UDP works, it is > a connectionless protocol. ok, thank you, I was confused because they show up in netstat -ln too. I guess that's just historic how it is behavior.
Re: netstat *:* udp sockets
Ted Unangst wrote: > Philip Guenther wrote: > > And, perhaps more directly, how would I block this in pf.conf? > > > > > > > Excellent choice, blocking dhclient from receiving the leases that it > > requests. > > "What problem are you trying to solve?" > > Well, this may be something of a lost cause, but I would prefer that chrome > not listen for stuff I don't understand. It listens on port 5353 as well, for > mDNS, and I can block that easily enough. It's the socket without a port > that's giving me trouble. Oops, followup question. If the situation is that these are simply unbound sockets that don't receive traffic, that makes life easier. I wasn't sure if they were some catch-all sockets or what.
Re: netstat *:* udp sockets
Philip Guenther wrote: > And, perhaps more directly, how would I block this in pf.conf? > > > > Excellent choice, blocking dhclient from receiving the leases that it > requests. > "What problem are you trying to solve?" Well, this may be something of a lost cause, but I would prefer that chrome not listen for stuff I don't understand. It listens on port 5353 as well, for mDNS, and I can block that easily enough. It's the socket without a port that's giving me trouble.
netstat *:* udp sockets
netstat -an tells me I am listening to all the udp. Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address(state) udp 0 0 *.**.* udp 0 0 127.0.0.1.53 *.* udp 0 0 *.**.* udp 0 0 *.5353 *.* udp 0 0 *.**.* What are those *.* sockets doing? How can you listen to all the ports? According to fstat, two belong to dhclient and one to chrome. root dhclient 552413* internet dgram udp *:0 root dhclient 552415* internet dgram udp *:0 tedu chrome 52839 107* internet dgram udp *:0 Although now they are printed as *:0. How do such sockets work? And, perhaps more directly, how would I block this in pf.conf?
Re: Change to init in -current?
Theodore Wynnychenko wrote: > Does this mean that getty is only allowed to access "/usr/bin/login," and that > my custom script is not in an allowed location after unveil "locks down" > getty? yes. > Obviously, my script is named autologin.sh and lives in /local; and it does > exist with appropriate file permissions. It appears that getty does not have > access to it any longer. I surmise this error is because getty's filesystem > access has been locked down by unveil. > > Is that what was meant by "unveil of /usr/bin/login specifically," or is it > something else? yes. > Also, I am assuming that the only way I could correct this for myself would be > to learn a lot more of C than I know now, edit the getty source, and compile > it > locally. In other words, there isn't something I can do from the command line > to get it to work again, is there? yes. the C involved is actually very rudimentary. just look for calls to unveil in the source. the downside is this isn't likely to be a change taken back.
Re: File sealing
Simon Ser wrote: > Sometimes the two processes don't trust each other, for instance in the > case of Wayland. Bad clients may try to crash the compositor. > > One way to crash the compositor is to send a shared memory file descriptor > and then shrink the file. When the compositor tries to read the > now-unmapped part of the file it'll receive SIGBUS. > > What the compositor currently does is that it handles SIGBUS and ignores it > if it's about a memory slice mmapped from IPC. Apart from being a hack, > this makes things complicated because: I'be been reminded that there's a different way to solve this problem in OpenBSD. The secret __MAP_NOFAULT flag to mmap. See for instance use in libxshmfence.
Re: File sealing
Simon Ser wrote: > Hi all> I'd like to know if there are plans to add a feature similar to file > sealing [2] in OpenBSD. I don't think so. You explained a possible use, but didn't actually explain if code using file sealing already exists.
Re: 6.4 doas gives "command not found" if no #!/bin/sh up top
tomr wrote: > I'm a bit confused here. I have some cwm keybindings that `doas rcctl` > things, which now aren't working as they used to - which isn't > necessarily a problem - but I'm surprised at the behaviour below: > > # this doesn't work anymore.. > $ doas rcctl > doas: rcctl: command not found are you using a snapshot? there's something broken, but 6.4 should work.
Re: 6.4 doas gives "command not found" if no #!/bin/sh up top
Ted Unangst wrote: > Ted Unangst wrote: > > Derek wrote: > > > Adding a "#!/bin/sh" at the top of the scripts made them all work again. > > > > i don't believe this is a change; that's how it should always work. > > sorry, this appears wrong. doas actually uses execvpe() from libc, which is > supposed to do the sh interpretation thing, except now it doesn't work right. > this is a behavior change. sorry for the burst of email. i was a little out of touch about what was happening. there were changes made, but they were not entirely expected or planned. old behavior: doas uses execvpe(), which as the man page notes, follows sh behavior and will execute the command using the sh if it has the x bit but lacks a magic header. new behavior: some unveil() calls were added to doas which restricts access to /bin/sh, meaning execvpe() no longer works as before. as hinted in my original reply below, i kind of like this behavior. the change to restrict commands to only those with valid headers was inadvertent, but the outcome seems positive. we will probably stick with it. so... the behavior changed, that's probably a bug, but we're going to call it a feature. problem solved. :) some documentation changes may be forthcoming to make everything clear. thanks for finding and reporting this. > > > > > > execve() returns ENOEXEC if the file doesn't have the right magic header. sh > > will attempt to interpret the file as a script after that error, but i don't > > think doas should have such a fallback. it may not be a sh script, and then > > weird and possibly bad things will happen (has happened before).
Re: 6.4 doas gives "command not found" if no #!/bin/sh up top
Ted Unangst wrote: > Derek wrote: > > Just upgraded from 6.3 to 6.4 and the doas behaviour seems to have changed. > > > > I finally solved it, but just posting here in case anyone has this problem. > > > > I had a few little shell scripts in /usr/local/sbin/ - intended to be run > > by doas : one-liners like bioctl mounting a USB stick or whatever. > > > > After upgrading to OpenBSD 6.4, all of them returned a "command not found" > > error. I tried moving them to different paths in $PATH, but no luck. > > Yet they'd work if I was root - just not via doas. > > > > Adding a "#!/bin/sh" at the top of the scripts made them all work again. > > i don't believe this is a change; that's how it should always work. sorry, this appears wrong. doas actually uses execvpe() from libc, which is supposed to do the sh interpretation thing, except now it doesn't work right. this is a behavior change. > > execve() returns ENOEXEC if the file doesn't have the right magic header. sh > will attempt to interpret the file as a script after that error, but i don't > think doas should have such a fallback. it may not be a sh script, and then > weird and possibly bad things will happen (has happened before).
Re: 6.4 doas gives "command not found" if no #!/bin/sh up top
Derek wrote: > Just upgraded from 6.3 to 6.4 and the doas behaviour seems to have changed. > > I finally solved it, but just posting here in case anyone has this problem. > > I had a few little shell scripts in /usr/local/sbin/ - intended to be run > by doas : one-liners like bioctl mounting a USB stick or whatever. > > After upgrading to OpenBSD 6.4, all of them returned a "command not found" > error. I tried moving them to different paths in $PATH, but no luck. > Yet they'd work if I was root - just not via doas. > > Adding a "#!/bin/sh" at the top of the scripts made them all work again. i don't believe this is a change; that's how it should always work. execve() returns ENOEXEC if the file doesn't have the right magic header. sh will attempt to interpret the file as a script after that error, but i don't think doas should have such a fallback. it may not be a sh script, and then weird and possibly bad things will happen (has happened before).
Re: net-snmpd extend and doas : a tty is required
Joel Carnat wrote: > Hi, > > I want net-snmpd to run a script via the extend directive. > This script has to run a command using doas to get temporary root > permission. > > The script is run on snmpcmd call but the doas command returns: > doas: a tty is required > > Is there a way to run doas from net-snmpd ? > I already have doas running from collectd-exec without issues. it needs a tty to ask for the password. you can use the nopasswd option, or something like expect to provide a tty.
Re: xlock Does Not Unlock (Snapshot)
Chris Wojo wrote: > I feel like these two issues could be related; but I'm not aware of any way > to diagnose why it won't accept my password or yubikey. > The yubikey authentication works on login; just not on screen locks. this depends on login.conf i believe, but for xlock you may have to type "yubikey:" followed by the otp.
Re: signify [file ... ]
Andrew wrote: > Just wondering if signify(1) is intended to exit 0 ONLY if the [file > ...] is within the shell's pwd ?? By chance, I noticed that > /path/to/file will fail on the same bsd.rd controlling for the working > directory. Mostly, yes. The filename is compared to the one in the signature file with a simple comparison. > h) /home/bench $> signify -Cp /etc/signify/openbsd-63-base.pub > -x SHA256.sig snaps/bsd.rd > Signature Verified > snaps/bsd.rd: FAIL The name in SHA256.sig is not snaps/bsd.rd, and so there is no match.
Re: Signify option semantics
multiplex'd wrote: > Hello all, > > I've been reading into the signify(1) program a little recently, and the > manual page mentons the '-t' option, which is used to ensure the public > key deduced from the signature comment "matches /etc/signify/*-keytype.pub", > where 'keytype' is the argument given to '-t'. I'm not sure what this > means. I've taken a glance over the source code, and it looks like specifying > this option is simply intended to ensure that the path to the public key used > to verify the given signature matches the path mentioned in the manual page. > Is this a correct interpretation? What's the rationale behind this option? this is used to ensure that pkg keys are not used to sign base sets, or vice versa, or any other combination, while still allowing a bit of flexibility.
Re: MAXDSIZ limits
Jordan Geoghegan wrote: > Is there any particular reason for the low sparc64 MAXDSIZ? Is there any > way for this limit to be increased as I have some large data > manipulation that needs to be done and I really would love to be able to increasing the value can be done by changing the header and compiling a new kernel. larger values should work, but apparently nobody has needed them until now.
Re: MAXDSIZ limits
Jordan Geoghegan wrote: > amd64 MAXDSIZ : ((paddr_t)32*1024*1024*1024) > i386 MAXDSIZ : (3UL*1024*1024*1024) > sparc64 MAXDSIZ : (8L*1024*1024*1024) > mips64 MAXDSIZ : 16UL*1024*1024*1024 > hppa MAXDSIZ : 1*1024*1024*1024UL > arm64 MAXDSIZ: ((paddr_t)16*1024*1024*1024) > > Could anyone tell me what the 'U' , "L' and '((paddr_t)' means? Unsigned, long, and typedef for physical address. Casts to make sure the multiplication doesn't overflow. > I hope I'm reading this wrong, but does sparc64 have an 8GB per-process > limit? I will be shocked if a mips64 box can allocate more memory > per-process than a sparc64 T-series. The limits are somewhat conservative, and there's no particular logic to any of them (except maybe i386, which is about as large as it can possibly be). They're generally set to be big enough that nobody complains.
Re: Kernel memory leaking on Intel CPUs?
Ted Unangst wrote: > Otto Moerbeek wrote: > > Sparc64 and powerpc also have speculative execution, branch > > prediction and extensive caches. It is much wiser to assume they are > > also affected by (similar) bugs/explots or whatever you call it. > > A lot of the commonly available sparc64 gear, T2 and USIII, are in order. So that's not exactly right, since branch prediction and speculative exection are somewhat orthogonal to out of order execution. I'm assuming they are somewhat less affected because without all the fun out of order machinery the CPU won't go nearly so far down the branch. Specifically regarding meltdown, sparc64 doesn't map the kernel in userland, right? Regarding spectre, the bounds check bypass requires executing past two branches. Can a sparc do that?
Re: Kernel memory leaking on Intel CPUs?
Otto Moerbeek wrote: > Sparc64 and powerpc also have speculative execution, branch > prediction and extensive caches. It is much wiser to assume they are > also affected by (similar) bugs/explots or whatever you call it. A lot of the commonly available sparc64 gear, T2 and USIII, are in order.
Re: bug tracking system for OpenBSD
Kai Wetlesen wrote: > Put bluntly, I was busy with completing my bachelors degree which was far > more important. You would have waited six months regardless. Now that it’s > done and out of the way I’ll happily take your advice. No need to explain that other things come up. OpenBSD developers are aware this happens. It's everybody else that seems to forget. :)
Re: bug tracking system for OpenBSD
Kai Wetlesen wrote: > > > you don't have to announce your bug database the first day you set it up. > > > in > > > fact, it's better not to. but in a few months time, when somebody > > > inevitably > > > asks misc how do i contribute, where's the todo list, you'll have this > > > handy > > > list of unresolved bugs to point them at. > There are many decisions that would need to be made that will piss somebody > off. Decisions like what software/platform to use, where to host the thing, > and > how much the tool should integrate into existing bug reporting mechanisms > (right now just fancy emailing). > > To answer your tactful question Theo, I personally haven’t done anything > because > I do not have your blessing nor of someone who can say “yes just effing do > it". But, > if you would be willing to give me free reign it will be done. Imagine if you'd followed my suggestion and spent the last six months curating a bug database. Then today you could have sent us a link to it and everybody would see how useful it is. Now we have to wait another six months.
Re: Wireless not working with Linksys
TimoMyyrä wrote: > > But scan results see the 2.4Ghz network but not the 5Ghz network: > > > > $ doas ifconfig iwn0 scan | grep MyNet > > nwid MyNet chan 11 bssid xx:xx:xx:xx:xx:xx -21dBm HT-MCS23 > > privacy,short_preamble,short_slottime,wpa2,wpa1 > > > > > > timo > > Actually, did quick test and seems that I can get link and ip when booting 6.0 > bsd.rd. Not that this is much help, but the reason I asked is I have (had) an AP (made by WD) with a similar problem. Worked without problems with 6.0, then sometime after that the new 802.11n code made it disappear. Can't associate, can't see the AP at all in ifconfig scan. The problem is unresolved (I ended up replacing the AP). There is a particular kind of packet which seems to be "invisible". But I'm out of my depth. Nobody else had seen this, but you appear to be the lucky second victim.
Re: Wireless not working with Linksys
TimoMyyrä wrote: > I just got Linksys 1900ACS wireless router and it works great, except with > OpenBSD. I've got Thinkpad T430s running -current and I can't get DHCP lease > from the new > router. > I noticed lines: "dhclient[22294]: fatal in iwn0: yielding responsibility" in > messages file which might be relating to this. > > Any ideas what could be the problem and how to begin debugging this further? Does it work with 6.0? Does the network appear in scan?
Re: Query regarding exec in mandocdb.c
Ted Unangst wrote: > Ingo Schwarze wrote: > > > this could just be memcmp. > > > > I avoided that over quibbles about the argument type (off_t vs. > > size_t), though i admit that database files larger than a Gigabyte > > make no sense at all. > > > > If you consider that an improvement, i'm not opposed to using > > memcmp(3). But i don't really have a good idea what to do if > > st_size does happen to exceed SIZE_MAX. Maybe just error out? > > in that case, you have already failed to mmap it, so i wouldn't worry too > much. actually, maybe not. if it's 4GB + a bit, the truncation will occur in the mmap call and you'll only map a part of the file. (and then, with the hand loop, you'll read well past the end of mapped memory and crash. with memcmp, it will truncate to the mapped length.) so if you want correctness, need to check both stats and error out.
Re: Query regarding exec in mandocdb.c
Ingo Schwarze wrote: > > this could just be memcmp. > > I avoided that over quibbles about the argument type (off_t vs. > size_t), though i admit that database files larger than a Gigabyte > make no sense at all. > > If you consider that an improvement, i'm not opposed to using > memcmp(3). But i don't really have a good idea what to do if > st_size does happen to exceed SIZE_MAX. Maybe just error out? in that case, you have already failed to mmap it, so i wouldn't worry too much.
Re: Query regarding exec in mandocdb.c
Ingo Schwarze wrote:
> + if ((cp1 = mmap(NULL, sb1.st_size, PROT_READ, MAP_PRIVATE,
> + fd1, 0)) == NULL) {
> + say(MANDOC_DB, "");
> + goto err;
> + }
> + if ((cp2 = mmap(NULL, sb2.st_size, PROT_READ, MAP_PRIVATE,
> + fd2, 0)) == NULL) {
> + say(tfn, "");
> + goto err;
> + }
mmap returns MAP_FAILED (-1), not null, on failure.
> + for (i = 0; i < sb1.st_size; i++)
> + if (cp1[i] != cp2[i])
> + goto err;
this could just be memcmp.
> + if (cp1 != NULL)
> + munmap(cp1, sb1.st_size);
> + if (cp2 != NULL)
> + munmap(cp2, sb2.st_size);
may need adjustment after fixing mmap checks, too.
Re: Full disk encryption questions
Philippe Meunier wrote: > - is the panic intended (well, known to the developers and considered > normal; I hesitate to call it a feature) or is it an oversight? no, nothing bioctl does should kill init like that. > - I would have thought that, once the softraid volume has been created, its > metadata wouldn't need to change (unless the passphrase is changed, or the > volume is roaming, as seen above). Any idea why part of it gets trashed? that's true, but maybe a stray write killed it? > - is there a way to get the computer to boot again, short of wiping the > disk with dd and starting from scratch again? you can run installboot. use the softraid disk name.
Re: lock X on suspend
tomr wrote:
> I've been struggling to get X to lock by calling xlock(1) from
> /etc/apm/{hibernate,resume,standby,suspend}
>
> Haven't seen a lot of useful debug output from xlock...
>
> # xlock -verbose ; echo $?
> 1
> # xlock -verbose -display :0.0 ; echo $?
> No protocol specified
> 1
> #
>
> I've figured out an effective workaround I think, which is to SIGUSR1 my
> running xidle(1) process, which works. I'm just wondering if there's a
> better way to get apmd, running /etc/apm/* as root, to do the same. I
> tried calling xlock both as root and as the current X user, no
> noticeable difference in results.
pkill -USR1 xidle from apm/suspend. don't forget chmod +x and !/bin/sh.
x40 users?
anyone using an x40? what have you set machdep.apmhalt to?
Re: How to find out which files were changed in -CURRENT and -STABLE between two releases?
pipfsta...@openmailbox.org wrote: > Hello, > > CVS is delivering me my daily dose of PITA (and I'm delivering a daily > dose of whining to the list). I feel like I'm trying to use a wooden bicycle > driven by jolts from the ground to make a tour from Washington, DC to > Sacramento, California. > > I've found cvs2cl.pl that turns pretty useless output of `cvs log` into > something meaningful. > But I didn't made my way through branches and tags. > I know that when release is done, sources are tagged with a > 'OPENBSD_x_y_BASE' tag. But cvs doesn't provide a way (well, at least > I didn't find it) to find a commit id when a certain tag was created. > Well, I tried to grep (1) the raw output of cvs log to see how tags > refer to files in per-file basis. But some files don't have any symbolic > names at all! > E.g.: > > "RCS file: /cvs/src/sys/arch/armv7/sunxi/Attic/sximmc.c,v > Working file: sys/arch/armv7/sunxi/sximmc.c > head: 1.12 > branch: > locks: strict > access list: > symbolic names: > keyword substitution: kv > total revisions: 12; > selected revisions: 12" > > And it is not a new file, first revision is dated 2016/08/15. It might > be some development branch, but then how do I differ which commits are > made into a release, and which are not? well, you're looking at a file that was deleted before it made it into any releases. it's not going to have tags. > Is there any way to make cvs show a bunch of changes that are made > between two releases in the -CURRENT and -STABLE branches? cvs diff -rOPENBSD_6_1 -rHEAD ? it's not clear what you're really trying to do. if you want the files for a release, cvs co -r that release.
Re: touchpad input driver: testing needed
Bryan Vyhmeister wrote: > On Mon, Jul 31, 2017 at 11:02:28PM +0200, Ulf Brosziewski wrote: > > for you. As always, a dmesg would be appreciated. The output of > > # wsconsctl | grep 'mouse' > > could also be of interest here (you must run it as root). > > This report is from a MacBookAir7,2 which is a 2015 13-inch MacBook Air. > Anything more than a regular click is not working as can be seen from > the wsconsctl output. I was using synclient to configure previously > which did allow the other settings. Can you also share your synclient settings?
Re: Calculate the frequency of the tsc timecounter
Adam Steen wrote:
> Sorry, i sent that before i had finished.
>
> I am trying to find an equivalent of the following code for FreeBSD
we don't currently export this info, but we could add some sysctls. there's
some cpufeatures stuff there, but generally stuff isn't exported until
somebody finds a use for it... it shouldn't be too hard to add something to
amd64/machdep.c sysctl if you're interested.
>
> size_t outsz = sizeof bi->cpu.tsc_freq;
> int ret = sysctlbyname("machdep.tsc_freq", >cpu.tsc_freq, ,
> NULL,
> 0);
Re: diff exit status
Ibrahim Khalifa wrote: > Hi, > > If you run diff against two directories where you have file(s) and the only > difference is that you have file(s) that only exists in one of the > directories, diff will exit with 0. If you use -N och -P it will however exit > with 1. > > Reading through the man-page, I can’t find any reference that this would be > intentionally. Rather I expected it to exit with 1, since there is a > difference found. The only other diff I have access to is GNU diff, which > seems to exit with 1 in the same scenario. > > If the behavior is intentionally, I think the man-page should also reflect > this. Otherwise diff should be changed to exit with 1 even if -N or -P isn’t > used. > > Both changes are trivial and I can provide a patch if there is some consensus > on which behavior is the best. it's probably an oversight. the exit code should be 1.
Re: signify implementation details and memory usage
Fabio Scotoni wrote: > Is there any particular reason why things are being done this way? I > could imagine that it's to stay compatible with upstream SUPERCOP, but > mod_ed25519.c does not seem to have changed in CVS for over three years. Yes, the idea is you should be able to diff the files with those in supercop and see that they are the same. it's not how i would have made the api, but i didn't make the api. :) i'll note that libsodium offers more convenient versions of these functions.
Re: Verified auth tty ioctl()s implementation details
multiplex'd wrote: > From an end-user standpoint, this means that if a user has run a > priviledged command using sudo and then (within the timeout) runs a > script which itself calls sudo, then they will not be prompted to > enter a password as the script is running with the same foreground > process group on the controlling terminal as the first invocation. > However, in the same scenario, doas would prompt for a password > when it is invoked from within the script, as its parent process ID > is different when running under an interactive user shell from when > it's executed in a shell script. (This can also be observed when > building ports with SUDO=doas, as doas is invoked at various points > in the build process under different make (sub)processes, which > results in doas prompting for a password many times.) > > Now, I am running on the assumption that these ioctl()s were > implemented as a kernel-side component of doas's "password timeout" > functionality as observed when using the "persist" configuration > keyword. From that, my question is whether there is any particular > reason for recording the parent process ID in particular as part of > the cookie stored by the persistent authentication ioctl() as opposed > to the process group ID of the calling process's session leader, as > with sudo. Yes, the difference is intentional. For pretty much exactly the reason you noticed, although perhaps with the opposite result. A successful authentication is not meant to be inherited by any random program or script you run. A) because vague security concerns, but also B) because I think it's weird that a script maybe works if it runs fast enough, but fails if it takes five minutes to get to doas. Like "make; doas make install" works on a fast machine but fails unexectedly on a slower machine. A more robust approach to this problem is to invert privilege. Start as root, then drop to another user.
Re: Using signify into shell script
Stephane HUC PengouinBSD wrote: > > $ signify -G -p Test.pub -s Test.sec > passphrase: > signify: please provide a password > $ ls -al | egrep Test > $ > > If not entry password, key files are not created! you can create keys without passphrases using -n.
Re: Skylake experience with -current
Bryan C. Everly wrote: > Thanks again to tedu and everyone else who put in the effort to get us > working on this architecture. I can't imagine it was easy! For the record, it wasn't me. Kettenis did some great work, though.
Re: A question of lock usage in OpenBSD kernel code
J Doe wrote: > Ok, thank you for clarifying that for me. I will proceed with development in > C. As an aside - do OpenBSD developers track with the latest standard (C11), > or is another standard preferred ? mostly c89. in particular, don't mix code and declarations.
Re: Playing (screwing up ) with partitions
Manuel Solis wrote: > My question is: > I know that i am missing some step to fulfill the shrinking process > but in the FAQ there is only a way to grow fs and i didn’t find the shrinking > fs, and in the book says that i should move the partition, well it does not > say it but i figured out with the information in there, > is there another way to fix my mistake so i could work with the new fs > size? > (Or there is a rule that no FFS could be shrinked, only growed) OpenBSD does not have any tools to shrink a filesystem. Changing the disklabel doesn't change the filesystem. *IF* you didn't write anything to the space that used to be your filesystem, you should be able to change the disklabel back to the way it was before.
Re: Missed ifconfig [[-]txpower dBm] option for 802.11
Denis wrote: > Looking for ifconfig '[[-]txpower dBm]' option which was present in > OpenBSD 5.4 amd64. Try to find 'txpower' on 6.0 amd64 but seems it > missed out. > > Actively using it to match power for 802.11 card and it's RF recipient > (post amp). What mechanism of output power matching is provided > currently since 5.4 amd64? txpower was removed because only the wi driver supported it and the relevance of the wi driver has faded.
Re: ext2 or usb problem
Donald Allen wrote: > I am guessing, but do not know, that the trouble here is either in the > ext2 support or perhaps in the usb driver. If ext2, I realize that it It wouldn't surprise me that the USB stack can get wedged if it does lots of IO. ext2fs probably has other bugs, but I wouldn't expect it to just hang. It would more likely trash your files in a reasonable amount of time. Bugs in USB do get fixed over time, although it's rarely obvious what the problem is from any one report.
Re: ipmi driver broken
Paul B. Henson wrote: > After applying this and installing the resulting kernel, ipmi worked > fine. I skipped 6.0, but just updated my boxes to 6.1, and see the same > ipmi failures. It looks like this fix hasn't been applied, the code in > head is still missing this line. I applied it again to my 6.1 kernel and > it still seems to make ipmi work fine as far as I can tell. > > Is there anyone maintaining ipmi or someone with commit privs that might > be kind enough to apply this so the next release version would have > working ipmi? i'm afraid i won't make a very good ipmi maintainer, but i think i applied the patch in the right spot.
Re: Bioctl rounds doesn't appear to affect the passphrase time?
Kevin Chadwick wrote: > On Fri, 23 Jun 2017 20:24:24 +0200 > > > > > > > I started by trying very high values with a simple password and > > > > > expected to have to wait a long time but it was always around 7 > > > > > seconds? > > > > very high as in -r 2000 ? > > > > > > Yeah, 2048? Is there a MAX? > > Not really. > > > > Oh it's been only 9 month since bioctl(8) switched over to bcrypt > > PBKDF. You might run a older version (dmesg would help) in which case > > you want to go much higher... 16000? > > > > # bioctl -v -c C -l /dev/vnd0a softraid0 > > > > shows you what KDF you are using. > > Thanks > > -r 1 shows "bioctl: number of KDF rounds is too small: 1" > > -r 4 shows "Deriving key using bcrypt PBKDF with 256 rounds..." > > whatever I set -r to, seems to say 256 rounds and returns in a similar > timeframe. > > e.g. bioctl -v -c C -r 32000 -l /dev/vnd0a softraid0 well, of course. if it used a different number of rounds, the key wouldn't match the one generated when the volume was created. if you're trying to create a new volume, start with blank metadata.
Re: Bioctl rounds doesn't appear to affect the passphrase time?
Kevin Chadwick wrote: > On Fri, 23 Jun 2017 18:13:20 +0200 > > > > > I started by trying very high values with a simple password and > > > expected to have to wait a long time but it was always around 7 > > > seconds? > > very high as in -r 2000 ? > > Yeah, 2048? Is there a MAX? i do not recommend using the maximum.
