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

 
 

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

Submitted by:  Brent Baccala <baccala>
Submitted on:  Wed 07 Sep 2016 09:02:09 PM UTC  
 
Category: glibcSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: FixedPrivacy: Public
Assigned to: NoneOriginator Name: 
Open/Closed: ClosedReproducibility: Every Time
Size (loc): NonePlanned Release: None
Effort: 0.00
Wiki-like text discussion box: 

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

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

Done so in 8cb2537239f143c374d9b0ec818e7e180a6a2207, thanks!

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

Hint: use codesearch.debian.net ;)

Samuel Thibault <sthibaul>
Project Member
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>
Project Member
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>
Project Member
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():

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 File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 20 Sep 2016 08:11:25 PM UTCsthibaulStatusNone=>Fixed
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1