Re: port-hppa/56118: sporadic app crashes in HPPA -current

[Tom Lane <tgl%sss.pgh.pa.us@localhost>]

The following reply was made to PR port-hppa/56118; it has been noted by GNATS.

From: Tom Lane <tgl%sss.pgh.pa.us@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: port-hppa/56118: sporadic app crashes in HPPA -current
Date: Sun, 05 Jun 2022 17:36:23 -0400

 chris%groessler.org@localhost writes:
 > Thread 1 "" received signal SIGSEGV, Segmentation fault.
 > 0x00035228 in __canonicalize_funcptr_for_compare ()
 > ...
 > (gdb) x/4i $pc
 > =3D> 0x35228 <__canonicalize_funcptr_for_compare+48>: probei,r (r3),3,r2=
 0
 >    0x3522c <__canonicalize_funcptr_for_compare+52>: cmpiclr,<> 0,r20,r0
 >    0x35230 <__canonicalize_funcptr_for_compare+56>: b,l,n 0x3527c <__can=
 onicalize_funcptr_for_compare+132>,r0
 >    0x35234 <__canonicalize_funcptr_for_compare+60>: ldw 0(r3),r20
 
 I poked into this a little bit.  I think what is happening is that
 makemandb assumes that it can do this function pointer comparison:
 
         } else if (mdocs[n->tok] =3D=3D pmdoc_Xr) {
 
 without regard for whether "mdocs[n->tok]" is a valid pointer;
 as Nick Hudson points out downthread, the value being passed to
 __canonicalize_funcptr_for_compare looks a lot more like a bit of
 ASCII text than it does a pointer.
 
 Now, __canonicalize_funcptr_for_compare does try to defend itself
 against being given a bogus pointer, but it's crashing exactly where
 it tries to do that.  The PROBEI instruction corresponds to this bit
 in external/gpl3/gcc/dist/libgcc/config/pa/fptr.c:
 
   if (!_dl_read_access_allowed ((unsigned int)plabel))
     return (unsigned int) fptr;
 
 So seemingly, _dl_read_access_allowed fails on sufficiently-bogus
 pointers.  I looked up PROBEI in the HPPA Architecture Reference,
 and I found out that it only knows how to give the correct answer
 if the target address is in the data TLB table.  If it isn't (which
 of course it wouldn't be in this case), PROBEI causes a "non-access
 data TLB miss fault".  The manual then says:
 
     If this instruction causes a non-access data TLB miss
     fault/non-access data page fault, the operating system's handler is
     required to search its page tables for the given address. If found,
     it does the appropriate TLB insert and returns to the interrupting
     instruction. If not found, the handler must decode the target field
     of the instruction, set that GR to 0, set the IPSW[N] bit to 1, and
     return to the interrupting instruction.
 
 I don't have a good idea where to look in the NetBSD sources for
 HPPA TLB miss handling, but I will bet lunch that it is not handling
 this case correctly, because surely PROBEI will never actually try
 to dereference the target address, as the SIGSEGV trap would seem to
 indicate.  I suspect the TLB miss logic just treats any invalid
 address as SIGSEGV, without this special case for PROBEI.
 (Note there is also a PROBE instruction with the same requirement.)
 
 So the direct cause of the crash looks to me to be missing kernel
 functionality.  However, I'm also fairly suspicious of makemandb's
 code, because it seems to me that comparing ASCII text to a function
 pointer is someday going to result in a false match and ensuing
 misbehavior.  I wonder if that is basically an uninitialized-variable
 problem.
 
 The crash in bash does seem quite unrelated.
 
 			regards, tom lane