<taleon>
I still have the problem that pil + does not work. Both under OpenBSD stable and OpenBSD current. I have tested this on two different Thinkpads. Maybe there is a difference to the real hardware and virtual machine.
<taleon>
pil (without +) works
<abu[7]>
Hi taleon o/
<taleon>
Hi :-)
<taleon>
Under OpenBSD 7.4, pil + also works on real hardware.
<tankf33der>
back
<tankf33der>
so
<tankf33der>
taleon: in general pil21 works on openbsd
<taleon>
aye
<tankf33der>
i am under vm of course
<taleon>
My guess is that it is due to the new pinsyscall. golang also has massive problems with syscalls.
<taleon>
"Assuming you have identified an application crash caused by ILL_BTCFI, you will need to locate the sections of code with indirect jumps and calls and implement the endbr64 command as a crucial mitigation measure. endbr64, which stands for “ENDBRanch 64-bit”, is a security-enhancing instruction within the x86-64 architecture, utilized by processors adhering to the AMD64 or Intel 64 instruction sets,
nat-418 has quit [Remote host closed the connection]
<tankf33der>
compiled
<tankf33der>
didnt received
<abu[7]>
Same as pil12?
<tankf33der>
pil32, 64, 21 - the same - didnt receive
<abu[7]>
:(
<taleon>
- Introduce pinsyscalls(2): The kernel and ld.so(1) register the precise entry location of every system call used by a program, as described in the new ELF section .openbsd.syscalls inside ld.so and libc.so. ld.so uses the new syscall pinsyscalls(2) to tell the kernel the precise entry location of system calls in libc.so.
<taleon>
Attempting to use a different system call entry instruction to perform a non-corresponding system call operation will fail and the process will be terminated with signal SIGABRT.
<taleon>
Removed support for syscall(2), the "indirection system call," a dangerous alternative entry point for all system calls.
<taleon>
Together with pinsyscalls(2) this change makes it impossible to perform system call through any other way than the libc system call wrapper functions.
<taleon>
From the 7.5 changelog
<tankf33der>
c code works without problems
<tankf33der>
c code from internet
<tankf33der>
for udp
<abu[7]>
And pil uses native calls
<taleon>
The obsolete syscall(2) was finally removed from OpenBSD 7.5 at the request of Theo de Raadt, as a more precise and therefore more secure system call scheme using pinsyscalls(2) has been implemented over the last five years. To further protect against return-oriented programming (ROP) attacks, the OpenBSD compiler inserts an additional statement at all points where a branch is to land. If a ROP attack
<taleon>
causes a branch to jump to another location, this triggers a CPU error and the executing program terminates with "illegal instruction" (SIGILL). The exact cause of the error can be traced in ktrace.
<taleon>
Translated from heise.de
<taleon>
terminates with "illegal instruction"
<taleon>
Exactly what happens to me when I call up pil +
<tankf33der>
did you installed 64bit openbsd? :)
<tankf33der>
did you install 64bit openbsd? :)
<taleon>
pinsyscalls came with OpenBSD 7.5 and exactly since this version pil + does not work anymore on real hardware. Tried on several different computers.
<taleon>
Yes
<tankf33der>
your issue does explain why all works on my side
<tankf33der>
does not
<taleon>
Tried with OpenBSD 7.5 stable and OpenBSD 7.5 current. All 64 bit and real hardware
<tankf33der>
generic kernel ?
<tankf33der>
default one right ?
<taleon>
Maybe virtual machines work differently? I honestly have no idea.
<taleon>
Yes default
rob_w has quit [Remote host closed the connection]
<tankf33der>
taleon: eh
<taleon>
Newly installed, original kernels.
<taleon>
Tested on Thinkpad X1, Thinkpad X13 and Thinkpad X270.
<taleon>
Unfortunately, I don't have any manufacturers other than Thinkpads to test.
<taleon>
Lenovo Thinkpads
<tankf33der>
lets try with your issue
<abu[7]>
Hmm, but Pil calls the native C library, thus the internal syscall mechanism should be irrelevant, no?
<tankf33der>
show me output from:
<tankf33der>
ldd bin/picolisp
<tankf33der>
first i want your issue on my side
<taleon>
The only difference to the standard installation is that I have added the user to the `staff` group and increased a few values in /etc/login.conf. Likewise in /etc/sysctl.conf
<taleon>
tankf33der: It seems that you cannot run ldd on xterm. However, there is another way: https://termbin.com/sr7e
<taleon>
readelf -d `which xterm` | grep hare
<taleon>
"ldd, by the way, can run arbitrary code, so maybe don't use it so much especially if a confused user has a binary in their home dir they want you to look at as root"
<beneroth>
good advice ^^
<tankf33der>
taleon: xterm do not use readline, see
<taleon>
ou're right. I also installed readline directly as in your instructions and xterm still works. I don't know why that made half my system unusable the other day.
<tankf33der>
:)
<tankf33der>
I do not have openbsd systems home since cannot install openbsd on qemu
<tankf33der>
lets continue tomorrow
<abu[7]>
Thanks to both of you!
<tankf33der>
I will send you mine bin/picolisp or you have to switch to pil64
<tankf33der>
afk.
msavoritias has quit [Remote host closed the connection]
msavoritias has joined #picolisp
<taleon>
Aye, thank you for your time and support.
<taleon>
Under linux, OpenBSD should also run in qemu. In any case, it has always worked for me.