bugThe GNU Hurd - Bugs: bug #49023, glibc - hurd_safe_{copyin,...

 
 

bug #49023: glibc - hurd_safe_{copyin, copyout, memmove, memset} broken

Submitter:  Brent Baccala <baccala>
Submitted:  Wed 07 Sep 2016 09:02:09 PM UTC
   
 
Category:  glibc Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Privacy:  Public
Assigned to:  None Originator Name: 
Open/Closed:  Closed Reproducibility:  Every Time
Size (loc):  None Planned Release:  None
Effort:  0.00
Wiki-like text discussion box: 


* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 20 Sep 2016 08:11:25 PM UTC, comment #6: 

Done so in 8cb2537239f143c374d9b0ec818e7e180a6a2207, thanks!

Samuel Thibault <sthibaul>
Group administrator
Tue 20 Sep 2016 06:32:41 AM UTC, comment #5: 

Hint: use codesearch.debian.net ;)

Samuel Thibault <sthibaul>
Group administrator
Tue 20 Sep 2016 12:32:38 AM UTC, comment #4: 

Yes, that's what I meant.  The relation is that HURD_PREEMPT_SIGNAL_P's first argument is a struct hurd_signal_preemptor, so we'd be effectively changing how that structure is interpreted.  Its "first, last" range would now be compared against detail->exc_subcode instead of detail->code.

I don't know how far ranging the effect of that change would be.

I was thinking that the C++ library would be a good place to use signal preemptors, to convert memory faults into C++ exceptions.  That's hard to do with standard POSIX signals, since they're delivered to the process, but C++ exceptions are delivered to the thread.

I think there's a Microsoft C++ extension that does something like that.

My point is that signal preemptors seem useful, but I don't know where else they're currently used.

Brent Baccala <baccala>
Mon 19 Sep 2016 11:22:00 PM UTC, comment #3: 

I don't see the relation with HURD_PREEMPT_SIGNAL_P.  Did you mean "is
there some code which relies on the previous semantic of detail->code?"
?

Samuel Thibault <sthibaul>
Group administrator
Mon 19 Sep 2016 10:37:24 PM UTC, comment #2: 

Is the signal preemption code used anywhere outside the C library?

If not, changing the parameter to HURD_PREEMPT_SIGNAL_P sounds like a good solution.

Brent Baccala <baccala>
Fri 16 Sep 2016 06:48:35 PM UTC, comment #1: 

Hello,

Wouldn't the solution be to pass detail->exc_subcode to
HURD_PREEMPT_SIGNAL_P instead of detail->code?

How to reproduce the issue easily btw?

Samuel Thibault <sthibaul>
Group administrator
Wed 07 Sep 2016 09:02:09 PM UTC, original submission:  

The hurd_safe_* routines currently fail to catch memory faults and instead deliver signals which, if uncaught, terminate the faulting task.

The problem seems to lie in the interaction between the signal preemption code in hurd/ and sysdeps/mach/hurd/i386/exc2signal.c's exception2signal():


     38     case EXC_BAD_ACCESS:
     39       switch (detail->exc_code)
     40         {
     41         case KERN_INVALID_ADDRESS:
     42         case KERN_MEMORY_FAILURE:
     43           *signo = SIGSEGV;
     44           detail->code = posix ? SEGV_MAPERR : detail->exc_subcode;
     45           break;


Notice that if the 'posix' flag is set, detail->code becomes SEGV_MAPERR (#defined to be 1), instead of the faulting memory address, which the kernel provides in exc_subcode.  However, the hurd_signal_preemptor structure, as it is used in hurd/catch-signal.c (see also the macro HURD_PREEMPT_SIGNAL_P), is used to compare detail->code to the memory range being accessed by the hurd_safe_* routine to determine if the signal should be preempted.

The net result is that 1 (SEGV_MAPERR) is never in the memory range being accessed, so the signal is never preempted.


Brent Baccala <baccala>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by sthibaul (Posted a comment)
  • -email is unavailable- added by baccala (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-09-20 sthibaul StatusNone Fixed
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code