Re: ruby arm64 BTI

Mark Kettenis <mark.kettenis@xs4all.nl> wrote:

> > From: "Theo de Raadt" <deraadt@openbsd.org>
> > Date: Sat, 22 Jun 2024 06:16:03 -0600
> >
> > Mark Kettenis <mark.kettenis@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