Mark Kettenis <mark.kette...@xs4all.nl> wrote: > > From: "Theo de Raadt" <dera...@openbsd.org> > > Date: Sat, 22 Jun 2024 06:16:03 -0600 > > > > Mark Kettenis <mark.kette...@xs4all.nl> wrote: > > > > > Theo pointed out the NOBTCFI reversal here. Now the reason that we > > > still see SIGILL despite fixes to the assembly code is because the > > > -mbranch-protection=pac-ret option added by the configure script > > > actually downgrades our default of enabling both BTI and PAC to just > > > enabling PAC. So the necessary BTI instructrions were missing from > > > the C code. > > > > How did this issue arise? Is PAC without BTI the case on MacOS? > > Well, M1 did have PAC but no BTI. BTI only came with M2. > > > > With the diff below things seem to work fine on Apple M2. There is > > > one failure in the testsuite: > > > 1) Failure: > > > TestIO_Console#test_failed_path > > > [/home/ports/pobj/ruby-3.3.3/ruby-3.3.3/test/io/console/test_io_console.rb:46]: > > > [Errno::ENODEV, Errno::ENOTTY, Errno::EBADF, Errno::ENXIO] exception > > > expected, not #<Errno::EOPNOTSUPP: Operation not supported - /dev/null>. > > > > > > but I'm pretty sure that is unrelated to BTI support. > > > > I suspect that's the recent delution over "isatty is poorly standardized, > > and we believe it should return linux errno". > > Not sure if it isatty(3), but it is related to an ioctl on /dev/null. > And we have a problem in OpenBSD here. > > On amd64, the mmioctl() function returns ENODEV for unimplemented > ioctls. And this is one of the values that ruby expects. But on most > other architectures mmioctl() return EOPNOTSUPP. I think that's a bug > introduced 23 years ago by christos when an MI mmioctl() was > introduced in NetBSD that got somehow copied into our MD variants of > mmioctl().
Yes, that is a bug. > That said, I think the actual correct return value should be ENOTTY is > that is what our man page and POSIX say. And that would probably fix > isatty(3) as well, which according to the man page should return > ENOTTY if the file descriptor isn't associated with a terminal. This > is what modern FreeBSD does. This remains contentious: https://austingroupbugs.net/view.php?id=618
