So why ?

I can't see how it can work as-is. proc_rwmem() uses a copy-on-read fault to map a private copy of the page, and then modifies that page directly, but vm_map_lookup() requires maxprot VM_PROT_WRITE for this operation.

Sorry for the noise, I missed that the restriction applies only to shared mappings.

Where do you see it ? If it is, I do not understand the reasoning. For 'attacker', the private rwx memory is as good as shared one.

In vm_map_lookup():

4122         if ((fault_typea & VM_PROT_COPY) != 0 &&                                                                                                         
4123             (entry->max_protection & VM_PROT_WRITE) == 0 &&                                                                                              
4124             (entry->eflags & MAP_ENTRY_COW) == 0) {                                                                                                      
4125                 vm_map_unlock_read(map);                                                                                                                 
4126                 return (KERN_PROTECTION_FAILURE);                                                                                                        
4127         }

To make use of proc_rwmem(), an attacker would need to perform the modification from a separate process AFAIK.

No, there is something mixed in the responses. My initial concern, still not refuted, is that breakpoints do not work with this patch, exactly due to the fragment in the vm_map_lookup(_entry) which you pointed out. I do not care about a way to subvert this feature, I only want to discuss breakpoints ATM.

Segments mapped by rtld are private, so the corresponding map entries will have MAP_ENTRY_COW set, so the fragment I pointed out should have no effect. I tried the patch and was able to set breakpoints on libc symbols.