Re: ldd error with setuid/setgid binaries
From: "Theo de Raadt" Subject: Re: ldd error with setuid/setgid binaries Date: Wed, 18 Oct 2023 10:01:34 -0600 > But anyways, you are not talking about OpenBSD. I am using the normal OpenBSD 7.4 installation from ftp.jaist.ac.jp, one of the official mirrors. I am talking about that, not anything else.
Re: xenodm blank screen
Hi Ryan, Yes, please paste the output of: $ dmesg | less $ less /var/log/Xorg.0.log I see you already sent part of the Xorg log. Please send the entire output of the commands above. The information those provide will help us better assist you. Usually when you create your own ~/.xsession the main X config file /etc/X11/xenodm/Xsession won't start fvwm or xtem. so my .xsession starts xterm and cwm. xterm & cwm Additionally, do you have prior experience with cwm(1)? You can start a new xterm window with Ctrl-Alt-Enter or launch other apps (Firefox, Chrome) with Alt-? (Alt-Shift-/). Let us know the info above and if this explanation helps.
Re: ldd error with setuid/setgid binaries
On Wed, Oct 18, 2023 at 09:38:32PM +0200, Theo Buehler wrote: > On Thu, Oct 19, 2023 at 01:39:00AM +0900, Yoshihiro Kawamata wrote: > > From: Marc Espie > > Subject: Re: ldd error with setuid/setgid binaries > > Date: Wed, 18 Oct 2023 18:04:45 +0200 > > > > > objdump -p > > > will be as good. > > > > > > Yes, it does not recurse, but it doesn't need to, since you also > > > want to wipe libraries that link with old libraries. > > > > This seems to be easier to parse in a shell script than "readelf -d". > > If you need recursion you may want to try lddtree from devel/pax-utils. > Admittedly, I think what Yoshihiro-kun is trying to achieve may be under the realm of sysclean.
Re: ldd error with setuid/setgid binaries
On Thu, Oct 19, 2023 at 01:39:00AM +0900, Yoshihiro Kawamata wrote: > From: Marc Espie > Subject: Re: ldd error with setuid/setgid binaries > Date: Wed, 18 Oct 2023 18:04:45 +0200 > > > objdump -p > > will be as good. > > > > Yes, it does not recurse, but it doesn't need to, since you also > > want to wipe libraries that link with old libraries. > > This seems to be easier to parse in a shell script than "readelf -d". If you need recursion you may want to try lddtree from devel/pax-utils.
Re: ldd error with setuid/setgid binaries
From: Stuart Henderson Subject: Re: ldd error with setuid/setgid binaries Date: Wed, 18 Oct 2023 13:58:26 +0100 > There are two approaches. > > - use another tool to read the ELF header and parse NEEDED entries > from that. several are available (including at least one which will > recurse to show inter-library dependencies too, though I forget > what it's called) > > - provide an alternative binary which _can_ be executed by ldd It would be possible to create an alternative script using "readelf -d". Thanks for the suggestion. Yoshihiro Kawamata https://fuguita.org/
Re: OpenBSD 7.4 released -- Oct 16, 2023
Same. Preparing to upgrade. On 10/16/23 10:42, Claudio Miranda wrote: Congratulations to Theo and everyone involved in making OpenBSD 7.4 a reality and for this awesome project altogether! I also love the artwork (big thanks also to the artist that created it). so I'll be getting some 7.4 merch soon! Claudio Miranda On Mon, Oct 16, 2023 at 9:37 AM pela0 wrote: Upgrading... ;) --- Original Message --- On Monday, October 16th, 2023 at 09:53, Theo de Raadt wrote: - OpenBSD 7.4 RELEASED - October 16, 2023. We are pleased to announce the official release of OpenBSD 7.4. This is our 55th release. We remain proud of OpenBSD's record of more than twenty years with only two remote holes in the default install. As in our previous releases, 7.4 provides significant improvements, including new features, in nearly all areas of the system: - Various kernel improvements: o On arm64, show BTI and SBSS features in dmesg(8). o New kqueue1(2) system call supporting the O_CLOEXEC flag. o Map device tree read/write to unbreak root on softraid(4). o Correctly recognize umass(4) floppy disk devices as floppy disks. o In wscons(4), catch up with box drawing characters which have been standardized in unicode after the original wscons code was written and chose placeholder values. o In wscons(4), make sure we do not increase the escape sequence argument count beyond usable bounds. o Implement dt(4) utrace(2) support on amd64 and i386. o Correct undefined behavior when using MS-DOS filesystems, fixes imported from FreeBSD. o Make the softdep mount(8) option a no-op. Softdep was a significant impediment to improving the vfs layer. o Allow unveil(2)ed programs to dump core(5) into the current working directory. o Address incomplete validation of ELF program headers in execve(2). o On arm64, use the deep idle state available on Apple M1/M2 cores in the idle loop and for suspend, resulting in power savings. o Update AMD CPU microcode if a newer patch is available. o Enable a workaround for the 'Zenbleed' AMD CPU bug. o Report speculation control bits in dmesg(8) CPU lines. o To give the primary CPU an opportunity to perform clock interrupt preparation in a machine-independent manner we need to separate the "initialization" parts of cpu_initclocks() from the "start the clock interrupt" parts. Separate cpu_initclocks() from cpu_startclock(). o Fix a problem where CPU time accounting and RLIMIT_CPU was unreliable on idle systems. o Improve the output of the "show proc" command of the kernel debugger ddb(4) and show both the PID and TID of the proc. - SMP Improvements o Rewrite pfsync(4), in particular to improve locking and to help with unlocking more of pf(4) and with parallelisation of the network stack in the future. The protocol remains compatible with the older version. o Remove kernel locks from the ARP input path. o Pull MP-safe arprequest() out of kernel lock. o Remove the kernel lock from IPv6 neighbor discovery. o Unlock more parts of ioctl(2) and the routing code in the network stack. - Direct Rendering Manager and graphics drivers o Update drm(4) to Linux 6.1.55. o Don't change end marker in sg_set_page(). Caused bad memory accesses when using page flipping on Alder Lake and Raptor Lake. - VMM/VMD improvements o Allowed vmm(4) guests to enable and use supervisor IBT. o Suppressed AMD hardware p-state visibility to vmm(4) guests. o Avoid use of uninitialised memory in vmd(8). o Migrate vmd_vm.vm_ttyname to char array allowing a vmd_vm object to be transmitted over an ipc channel. o Cleaned up file descriptor closing in vmd(8) vmm process. o Fixed vm send/receive, restoring device virtqueue addresses on receive. o Introduced execvp(3) after fork for child vm processes. o No longer generate an error in vmd(8) if vm.conf(5) is absent. o Split vmm(4) into MI/MD parts. o Introduced multi-process model for vmd(8) virtio block and network devices. o Allowed vm owners to override boot kernel when using vmctl(8) to start a vm. o Changed staggered start of vms to number of online CPUs. o Fixed a segfault on vm creation. o Switched to anonymous shared memory mappings for vmd(8) vm processes, introducing a new vmm(4) ioctl(2). o Relaxed absolute path requirements for vmd(8) configtest mode (-n). o Adjusted shutdown logic by vm id to function similarly as by name. o Moved validation of local network prefixes for the internal vmd(8) DHCP service into the config parser. o Fixed QCOW2 base images when used with the vmd(8) multi-process device model. o Fixed setting verbose logging in child processes. o Fixed a race condition related to the emulated i8259 interrupt controller by ignoring interrupt masks on assert. o Inlined pending interrupts in the vmm(4) ioctl(2) for running the vcpu, reducing vm latency. o Added zero-copy, vectored io to the vmd(8) virtio block device. o Changed to logging
Re: ldd error with setuid/setgid binaries
From: Marc Espie Subject: Re: ldd error with setuid/setgid binaries Date: Wed, 18 Oct 2023 18:04:45 +0200 > objdump -p > will be as good. > > Yes, it does not recurse, but it doesn't need to, since you also > want to wipe libraries that link with old libraries. This seems to be easier to parse in a shell script than "readelf -d". Thank you very much.
Re: OpenBSD 7.4 released -- Oct 16, 2023
Awesome new release as usual and the artwork is also superb. Regards, Jean-François
Re: ldd error with setuid/setgid binaries
On Wed, Oct 18, 2023 at 11:41:12PM +0900, Yoshihiro Kawamata wrote: > From: "Theo de Raadt" > Subject: Re: ldd error with setuid/setgid binaries > Date: Wed, 18 Oct 2023 06:35:51 -0600 > > > You don't explain why you need to do this. You just completely skipped > > that. > > You don't justify why you need it to work. Does that make me care?? No, it > > really doesn't make me care. > > This is to find executable binaries that use old shared libraries that > no longer exist after an OS upgrade. > objdump -p will be as good. Yes, it does not recurse, but it doesn't need to, since you also want to wipe libraries that link with old libraries.
Re: ldd error with setuid/setgid binaries
Yoshihiro Kawamata wrote: > From: "Theo de Raadt" > Subject: Re: ldd error with setuid/setgid binaries > Date: Wed, 18 Oct 2023 06:35:51 -0600 > > > You don't explain why you need to do this. You just completely skipped > > that. > > You don't justify why you need it to work. Does that make me care?? No, it > > really doesn't make me care. > > This is to find executable binaries that use old shared libraries that > no longer exist after an OS upgrade. But anyways, you are not talking about OpenBSD.
Re: ldd error with setuid/setgid binaries
From: "Theo de Raadt" Subject: Re: ldd error with setuid/setgid binaries Date: Wed, 18 Oct 2023 06:35:51 -0600 > You don't explain why you need to do this. You just completely skipped that. > You don't justify why you need it to work. Does that make me care?? No, it > really doesn't make me care. This is to find executable binaries that use old shared libraries that no longer exist after an OS upgrade.
Re: 7.4 on Mac M1 UTM (qemu) - X11
Hello John, I'm a veteran (a passed user) of Qemu. I go by memory: it seems to me that viogpu must be specified in the configuration of the virtual machine... Hope it is somewhat helpful. -- Daniele Bonini Oct 18, 2023 15:44:55 John Holland : > Hello, > I see 7.4 has been released and has the new viogpu(4) driver by joshua stein. > I am trying to use it in a VM created with UTM, a wrapper for QEMU that works > on M1 Macs. The virtual machine installs and starts up fine from the > install74.img mounted as a disk, but running startx/X/xenodm produces a black > screen. > > in ~/.local/share/xorg/Xorg.0.log.old I see the following: > > Fatal server error: > [ 419.659] (EE) xf86OpenConsole: No console driver found > Supported drivers: wscons > Check your kernel's console driver configuration and /dev entries(EE) > [ 419.663] (EE) > > > I am guessing creating an xorg.conf might help but I am not seeing anything > about how to specify viogpu (virtio-gpu?) for that. > > I see this in dmesg: > > wsdisplay0 at viogpu0 mux 1: console (std, vt100 emulation) > wsdisplay0: screen 1-5 added (std, vt100 emulation) > > > Is X11 possible in this setup? It would let me run OpenBSD on a HiRes > laptop. > > Thanks, > John
Re: Lenovo Thinkpad T14 Gen3 very slow on MP kernel, faster on GENERIC
Stuart Henderson writes: > On 2023-10-17, Comète wrote: >> Hi, >> >> Wow ! you're absolutely right ! If I unplug, no lagg anymore. >> So the solution should be to apply your patch and rebuild the kernel ? > > It's certainly worth trying. If you do, please report back here. > I have a particular Lenovo machine (AMD Ryzen-based, though) that routinely suffers from some perf throttling I think (guessing) in the bios or hardware itself. Usually a complete shutdown and plugging and unplugging the power gets it to start working as expected. Until then it's dog slow showing now reason why (pretty sure apm shows a normal cpu frequency and there's no interrupt storm). I would not be surprised if that's the same problem reported here. It happens enough to be mildly annoying, but not enough (and it's not my daily driver) that I have dug into it further beyond just the power cycle. Is it kernel state? Bios? /shrug
Re: xscreensaver-settings keeps on crashing
On Wed, Oct 18, 2023 at 03:46:51AM -0500, Luke Small wrote: I discovered that if I run xfce desktop that I have on here for thunar file manager, that it works. I don???t know why. AFAIK, xfce now has its own internal screensaver, it stopped using xscreensaver a release or 2 ago. I can???t run xscreensaver-settings under fvwm. The screensavers work though. Any suggestions? It said something about conflicting with xfce4-screensaver or something too. Interesting, on cwm xscreensaver-settings works OK, on fvwm it fails with: xscreensaver-demo: 09:19:14: X error: xscreensaver-demo: Failed request: BadMatch (invalid parameter attributes) xscreensaver-demo: Major opcode: 42 (X_SetInputFocus) xscreensaver-demo: Resource id:0x203 xscreensaver-demo: Serial number: 447 / 449 I think it is time for you to connect with people in mailing list po...@openbsd.org and/or search the archive in case someone already noticed this. It looks like an issue with xscreensaver and fvwm. John
7.4 on Mac M1 UTM (qemu) - X11
Hello, I see 7.4 has been released and has the new viogpu(4) driver by joshua stein. I am trying to use it in a VM created with UTM, a wrapper for QEMU that works on M1 Macs. The virtual machine installs and starts up fine from the install74.img mounted as a disk, but running startx/X/xenodm produces a black screen. in ~/.local/share/xorg/Xorg.0.log.old I see the following: Fatal server error: [ 419.659] (EE) xf86OpenConsole: No console driver found Supported drivers: wscons Check your kernel's console driver configuration and /dev entries(EE) [ 419.663] (EE) I am guessing creating an xorg.conf might help but I am not seeing anything about how to specify viogpu (virtio-gpu?) for that. I see this in dmesg: wsdisplay0 at viogpu0 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) Is X11 possible in this setup? It would let me run OpenBSD on a HiRes laptop. Thanks, John
Re: ldd error with setuid/setgid binaries
Stuart Henderson wrote: > On 2023/10/18 06:35, Theo de Raadt wrote: > > ldd around suid programs has a fine history of security holes. > > > > One idea is for you to just not not do that. > > > > You don't explain why you need to do this. You just completely skipped > > that. > > You don't justify why you need it to work. Does that make me care?? No, it > > really doesn't make me care. > > The usual reason for this is to find libraries needed to copy into > a chroot jail to make some binary work. > > > > How can I solve this? Please let me know if you have any good > > > alternatives. > > There are two approaches. > > - use another tool to read the ELF header and parse NEEDED entries > from that. several are available (including at least one which will > recurse to show inter-library dependencies too, though I forget > what it's called) > > - provide an alternative binary which _can_ be executed by ldd > No Stuart, I don't care because he doesn't care to tell us why he needs this. It remains possible to simply not need to inspect those programs. I doubt setuid programs are being copied into a chroot jail. But, mostly I don't care because I'm sick and tired of 'bug reports' that don't explain the usage case. ldd's environment variable game has had holes, and all the valiant attempts we make will create holes in the future, I'd bet money on it.
Re: ldd error with setuid/setgid binaries
On 2023/10/18 06:35, Theo de Raadt wrote: > ldd around suid programs has a fine history of security holes. > > One idea is for you to just not not do that. > > You don't explain why you need to do this. You just completely skipped that. > You don't justify why you need it to work. Does that make me care?? No, it > really doesn't make me care. The usual reason for this is to find libraries needed to copy into a chroot jail to make some binary work. > > How can I solve this? Please let me know if you have any good > > alternatives. There are two approaches. - use another tool to read the ELF header and parse NEEDED entries from that. several are available (including at least one which will recurse to show inter-library dependencies too, though I forget what it's called) - provide an alternative binary which _can_ be executed by ldd
Re: Dark theme in Xorg and trackpad
Will go with "colors"
THANKS!!
P.
--- Original Message ---
On Wednesday, October 18th, 2023 at 09:13, Johannes Thyssen Tishman
wrote:
>
>
> > # 1
>
> > Since a couple months ago I started using CWM, at first it was a
> > little weird to use but now I find it hard to come back to fluxbox
> > or I3, my favorite WMs...but (always one), I'd like to set Xorg
> > (not GTK), in a dark theme, dunno if that's even possible...I've
> > been a *BSD / linux user since '96-98... Never asked myself if
> > that can be done... Any clue?
>
>
> Not sure what you mean by setting a dark theme for Xorg, but AFAIK,
> you don't theme Xorg, but rather your {window manager (in your case
> cwm), desktop environment, widget libraries (gtk, qt)}. I don't use
> cwm, but a quick search for 'color' in cwmrc(5) should give you an
> idea of what colors you can configure. Other than that, some X
> client applications such as xterm can be configured through
> ~/.Xresources.
>
> Regarding #2, no clue. Sorry.
>
> Kind regards,
> Johannes
Re: ldd error with setuid/setgid binaries
ldd around suid programs has a fine history of security holes.
One idea is for you to just not not do that.
You don't explain why you need to do this. You just completely skipped that.
You don't justify why you need it to work. Does that make me care?? No, it
really doesn't make me care.
Yoshihiro Kawamata wrote:
> From: Stuart Henderson
> Subject: Re: ldd error with setuid/setgid binaries
> Date: Wed, 18 Oct 2023 10:00:19 - (UTC)
>
> > ldd started using execpromises, and:
> >
> > /* SUID programs may not be started with execpromises */
>
> I see. thank you.
> I created and used a shell script to create a list of dynamic link
> libraries used for all commands:
>
> #!/bin/sh
> [[ -z "$1" ]] && set /
>
> find "$@" \
> \! -fstype local -prune \
> -o \
> -type f \
> \( -perm -100 -o -perm -010 -o -perm -001 \) \
> -print \
> | xargs file \
> | awk '
> BEGIN {FS=":"}
> /ELF 64-bit LSB shared object/ {print $1}' \
> | xargs ldd \
> | awk '
> /^\/.*:$/ {fname = $1; sub(/:/, "", fname)}
> $3 == "rlib" {print $7, fname}' \
> | sort
>
> But this no longer works properly on OpenBSD 4.7.
>
> How can I solve this? Please let me know if you have any good
> alternatives.
>
>
> Yoshihiro Kawamata
> https://fuguita.org/
>
Re: ldd error with setuid/setgid binaries
From: Stuart Henderson
Subject: Re: ldd error with setuid/setgid binaries
Date: Wed, 18 Oct 2023 10:00:19 - (UTC)
> ldd started using execpromises, and:
>
> /* SUID programs may not be started with execpromises */
I see. thank you.
I created and used a shell script to create a list of dynamic link
libraries used for all commands:
#!/bin/sh
[[ -z "$1" ]] && set /
find "$@" \
\! -fstype local -prune \
-o \
-type f \
\( -perm -100 -o -perm -010 -o -perm -001 \) \
-print \
| xargs file \
| awk '
BEGIN {FS=":"}
/ELF 64-bit LSB shared object/ {print $1}' \
| xargs ldd \
| awk '
/^\/.*:$/ {fname = $1; sub(/:/, "", fname)}
$3 == "rlib" {print $7, fname}' \
| sort
But this no longer works properly on OpenBSD 4.7.
How can I solve this? Please let me know if you have any good
alternatives.
Yoshihiro Kawamata
https://fuguita.org/
Re: Dark theme in Xorg and trackpad
> # 1
> Since a couple months ago I started using CWM, at first it was a
> little weird to use but now I find it hard to come back to fluxbox
> or I3, my favorite WMs...but (always one), I'd like to set Xorg
> (not GTK), in a dark theme, dunno if that's even possible...I've
> been a *BSD / linux user since '96-98... Never asked myself if
> that can be done... Any clue?
Not sure what you mean by setting a dark theme for Xorg, but AFAIK,
you don't theme Xorg, but rather your {window manager (in your case
cwm), desktop environment, widget libraries (gtk, qt)}. I don't use
cwm, but a quick search for 'color' in cwmrc(5) should give you an
idea of what colors you can configure. Other than that, some X
client applications such as xterm can be configured through
~/.Xresources.
Regarding #2, no clue. Sorry.
Kind regards,
Johannes
Dark theme in Xorg and trackpad
Hi list, # 1 Since a couple months ago I started using CWM, at first it was a little weird to use but now I find it hard to come back to fluxbox or I3, my favorite WMs...but (always one), I'd like to set Xorg (not GTK), in a dark theme, dunno if that's even possible...I've been a *BSD / linux user since '96-98... Never asked myself if that can be done... Any clue? # 2 I've have a Lenovo Ideapad 14W, which I use mainly to pentesting, It works flawessly with OpenBSD...X, suspend, network...everything...but (again), I can't get the trackpad to work...There is a 70-synaptics.conf under /usr/X11R6/share/X11/xorg.conf.d, but I'm not sure if it has any effect at all. Again, any clue to start working on it? Thnx!!! P. PS... Upgrade to 7.4 flawless...not a single problem and so far seems that general performance is even better than 7.3, amazing.
Re: X session doesn't survive zzz
On Oct 18 11:11:54, h...@stare.cz wrote: > This is current/amd64 on a PC (dmesg below). > After a resume from zzz inside a running X session, > I am greeted with the xenodm login screen > into which I cannot login: the keyboard does nothing > (is it the USB keyboard not reattaching properly?). > > Loging in on the console, To be clear: typing the username and passwd into the xenodm login screen does nothing, but on the console the kbd works as expeceted. > I see that the X session > and the X applications (firefox, xterms) are dead. > On the other hand, the mplayer that has been zzz'ed > inside a tmux session starts playing again. > > After restarting xenodm with rcctl restart xenodm, > I can log in and everything seems to work again. > > See the dmesg below, including the zzz and resume, > and the full X log up to here. How can I debug this? > > Jan > > > OpenBSD 7.4-current (GENERIC.MP) #1406: Sun Oct 15 10:34:05 MDT 2023 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 8285454336 (7901MB) > avail mem = 8014598144 (7643MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (36 entries) > bios0: vendor Award Software International, Inc. version "F3" date 03/31/2011 > bios0: Gigabyte Technology Co., Ltd. H67MA-USB3-B3 > acpi0 at bios0: ACPI 1.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP HPET MCFG ASPT SSPT EUDS MATS TAMG APIC SSDT > acpi0: wakeup devices PCI0(S5) PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5) > PEX5(S5) PEX6(S5) PEX7(S5) HUB0(S5) UAR1(S3) USBE(S3) USE2(S3) AZAL(S5) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpihpet0 at acpi0: 14318179 Hz > acpimcfg0 at acpi0 > acpimcfg0: addr 0xf400, bus 0-63 > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.09 MHz, 06-2a-07, patch > 002f > 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 8-way L2 cache, 8MB 64b/line 16-way L3 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.12 MHz, 06-2a-07, patch > 002f > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 8-way L2 cache, 8MB 64b/line 16-way L3 cache > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0: apid 4 (application processor) > cpu2: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.19 MHz, 06-2a-07, patch > 002f > cpu2: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 8-way L2 cache, 8MB 64b/line 16-way L3 cache > cpu2: smt 0, core 2, package 0 > cpu3 at mainbus0: apid 6 (application processor) > cpu3: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.25 MHz, 06-2a-07, patch > 002f > cpu3: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 8-way L2 cache, 8MB 64b/line 16-way L3 cache > cpu3: smt 0, core 3, package 0 > cpu4 at mainbus0: apid 1 (application processor) > cpu4: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.37 MHz, 06-2a-07, patch > 002f > cpu4: >
Re: xscreensaver-settings keeps on crashing
I discovered that if I run xfce desktop that I have on here for thunar file manager, that it works. I don’t know why. I can’t run xscreensaver-settings under fvwm. The screensavers work though. Any suggestions? It said something about conflicting with xfce4-screensaver or something too. On Fri, Sep 29, 2023 at 06:38 John McCue wrote: > On Mon, Sep 11, 2023 at 10:51:55AM -0500, Luke Small wrote: > > > >I attached ???.xscreensaver??? I had to change the file type to send it. > > I ended up installing xscreensaver-6.05.1 via pkg_add(1) and > xscreensaver-demo and xscreensaver works good for me. > > You can get my old .xscreensaver from: > https://jmcunx.com/data/xscreensaver.txt > you would copy it to ~/.xscreensaver > > FWIW, I use a combination of xidle(1) and xlock(1) > since I try to stick with "base" whenever possible. > > This has information on using xidle/xlock that I used for my > setup. > > https://www.c0ffee.net/blog/openbsd-on-a-laptop > > HTH >
Re: ldd error with setuid/setgid binaries
On 2023-10-18, Yoshihiro Kawamata wrote: > In OpenBSD 7.4, running ldd on a setuid or setgid executable returns > an error. Why is this? ldd started using execpromises, and: /* SUID programs may not be started with execpromises */
ldd error with setuid/setgid binaries
In OpenBSD 7.4, running ldd on a setuid or setgid executable returns an error. Why is this? # ls -l atrm -r-xr-sr-x 1 root crontab 34864 Oct 10 23:41 atrm # ldd atrm atrm: atrm: Permission denied atrm: exit status 1 # chmod g-s atrm # ls -l atrm -r-xr-xr-x 1 root crontab 34864 Oct 10 23:41 atrm # ldd atrm atrm: StartEnd Type Open Ref GrpRef Name 0512c652d000 0512c6539000 exe 10 0 atrm 0514fad79000 0514fae73000 rlib 01 0 /usr/lib/libc.so.97.1 0515abed4000 0515abed4000 ld.so 01 0 /usr/libexec/ld.so Until OpenBSD 7.3, such errors did not occur. Yoshihiro Kawamata https://fuguita.org/
X session doesn't survive zzz
This is current/amd64 on a PC (dmesg below). After a resume from zzz inside a running X session, I am greeted with the xenodm login screen into which I cannot login: the keyboard does nothing (is it the USB keyboard not reattaching properly?). Loging in on the console, I see that the X session and the X applications (firefox, xterms) are dead. On the other hand, the mplayer that has been zzz'ed inside a tmux session starts playing again. After restarting xenodm with rcctl restart xenodm, I can log in and everything seems to work again. See the dmesg below, including the zzz and resume, and the full X log up to here. How can I debug this? Jan OpenBSD 7.4-current (GENERIC.MP) #1406: Sun Oct 15 10:34:05 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8285454336 (7901MB) avail mem = 8014598144 (7643MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (36 entries) bios0: vendor Award Software International, Inc. version "F3" date 03/31/2011 bios0: Gigabyte Technology Co., Ltd. H67MA-USB3-B3 acpi0 at bios0: ACPI 1.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET MCFG ASPT SSPT EUDS MATS TAMG APIC SSDT acpi0: wakeup devices PCI0(S5) PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5) PEX5(S5) PEX6(S5) PEX7(S5) HUB0(S5) UAR1(S3) USBE(S3) USE2(S3) AZAL(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimcfg0 at acpi0 acpimcfg0: addr 0xf400, bus 0-63 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.09 MHz, 06-2a-07, patch 002f 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 8MB 64b/line 16-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.12 MHz, 06-2a-07, patch 002f cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 8MB 64b/line 16-way L3 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.19 MHz, 06-2a-07, patch 002f cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 8MB 64b/line 16-way L3 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.25 MHz, 06-2a-07, patch 002f cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 8MB 64b/line 16-way L3 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.37 MHz, 06-2a-07, patch 002f cpu4: 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu4: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 8MB 64b/line 16-way L3 cache cpu4: smt 1, core 0, package 0 cpu5 at mainbus0: apid 3 (application processor) cpu5:
Re: Lenovo Thinkpad T14 Gen3 very slow on MP kernel, faster on GENERIC
On 2023-10-17, Comète wrote:
> Hi,
>
> Wow ! you're absolutely right ! If I unplug, no lagg anymore.
> So the solution should be to apply your patch and rebuild the kernel ?
It's certainly worth trying. If you do, please report back here.
> Thanks a lot !
>
> Morgan
>
> 17 octobre 2023 14:24 "Stuart Henderson" a écrit:
>
>> On 2023-10-16, Comète wrote:
>>
>>> Hello,
>>>
>>> I'm experiencing big slowdowns on a LENOVO Thinkpad T14 Gen3 when using MP
>>> kernel (on 7.3 and 7.4)
>>> but strangely not on GENERIC.
>>> For example, starting LibreOffice on GENERIC takes 7 seconds but 35 seconds
>>> on MP kernel. It's even
>>> lagging when typing some text in an editor or a mail.
>>> Switching to GENERIC and all is working as expected...
>>>
>>> Thanks for your help !
>>>
>>> Morgan
>>>
>>> This is my dmesg on both kernels:
>>>
>>> OpenBSD 7.4 (GENERIC) #1336: Tue Oct 10 08:52:22 MDT 2023
>>> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
>>> real mem = 34026549248 (32450MB)
>>> avail mem = 32975671296 (31448MB)
>>> random: good seed from bootblocks
>>> mpath0 at root
>>> scsibus0 at mpath0: 256 targets
>>> mainbus0 at root
>>> bios0 at mainbus0: SMBIOS rev. 3.4 @ 0x8f8a3000 (81 entries)
>>> bios0: vendor LENOVO version "N3MET16W (1.15 )" date 06/25/2023
>>
>> No problem with MP here, but I have an older BIOS -
>>
>> bios0 at mainbus0: SMBIOS rev. 3.4 @ 0x8d8a3000 (81 entries)
>> bios0: vendor LENOVO version "N3MET12W (1.11 )" date 02/09/2023
>>
>> (grumble stupid US date format)
>>
>>> bios0: LENOVO 21AHCTO1WW
>>> efi0 at bios0: UEFI 2.7
>>> efi0: Lenovo rev 0x1150
>>> acpi0 at bios0: ACPI 6.3
>>> acpi0: sleep states S0 S3 S4 S5
>>> acpi0: tables DSDT FACP SSDT SSDT SSDT SSDT SSDT TPM2 HPET APIC MCFG ECDT
>>> SSDT SSDT SSDT SSDT SSDT
>>> SSDT LPIT WSMT SSDT DBGP DBG2 NHLT MSDM SSDT BATB DMAR SSDT SSDT SSDT BGRT
>>> PHAT UEFI FPDT
>>> acpi0: wakeup devices PEG0(S4) PEGP(S4) PEGP(S4) PEG2(S4) PEGP(S4) GLAN(S4)
>>> XHCI(S3) XDCI(S4)
>>> HDAS(S4) CNVW(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4)
>>> [...]
>>> acpitimer0 at acpi0: 3579545 Hz, 24 bits
>>> acpihpet0 at acpi0: 1920 Hz
>>> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
>>> cpu0 at mainbus0: apid 0 (boot processor)
>>> cpu0: 12th Gen Intel(R) Core(TM) i7-1260P, 2151.34 MHz, 06-9a-03, patch
>>> 042c
>>
>> and different cpu:
>>
>> cpu0: 12th Gen Intel(R) Core(TM) i5-1245U, 1568.55 MHz, 06-9a-04, patch
>> 042c
>>
>> FWIW I can definitely get mine to throttle when it's busy. And your
>> CPU uses a fair bit more power than mine (I specifically looked for a
>> U rather than a P cpu for exactly this reason) so I'd guess might be
>> easier to hit the throttle.
>>
>> The OpenBSD kernel tries to set cpu clock speed high when on mains
>> power, so it might be worth trying unplugged to see if there's any
>> difference, or disable that thing with this
>>
>> Index: sched_bsd.c
>> ===
>> RCS file: /cvs/src/sys/kern/sched_bsd.c,v
>> retrieving revision 1.88
>> diff -u -p -r1.88 sched_bsd.c
>> --- sched_bsd.c 11 Oct 2023 15:42:44 - 1.88
>> +++ sched_bsd.c 17 Oct 2023 12:10:41 -
>> @@ -605,7 +605,7 @@ setperf_auto(void *v)
>> if (cpu_setperf == NULL)
>> return;
>>
>> - if (hw_power) {
>> + if (0 && hw_power) {
>> speedup = 1;
>> goto faster;
>> }
>
>
Re: xenodm blank screen
On 2023-10-18, Ryan England wrote: > Hello everyone, > > I've got an issue when attempting to start xenodm. When it starts, I only see > a blank screen. Looking in Xorg0.log, I see the following: > > wsfb(0): error in WSDISPLAY_SVIDEO Operation not supported > > I have ~/.xsession configured with `exec cwm`. Can't seem to get it working. There is very little information in your mail. Start with at least full dmesg and the full Xorg log. -- Please keep replies on the mailing list.
