On 2011-07-28 18:26, Jan Kiszka wrote: > On 2011-07-27 20:41, Gilles Chanteperdrix wrote: >> On 07/12/2011 09:15 AM, Jan Kiszka wrote: >>> On 2011-07-12 08:48, Gilles Chanteperdrix wrote: >>>> On 07/08/2011 02:15 PM, Jan Kiszka wrote: >>>>> On 2011-07-08 13:55, Gilles Chanteperdrix wrote: >>>>>> On 07/07/2011 09:14 PM, Jan Kiszka wrote: >>>>>>> From: Jan Kiszka <[email protected]> >>>>>>> >>>>>>> Page protection changes issued via mprotect, e.g. to enable executable >>>>>>> stacks, cause spurious minor faults as they remove the write permission >>>>>>> from the modified range again. Avoid this by faking shared pages so that >>>>>>> vm_get_page_prot returns the desired page permissions. >>>>>> >>>>>> This looks dangerous to me. Have you checked that write to private heaps >>>>>> will not end up corrupting shared data? >>>>> >>>>> Can't follow this yet. >>>>> >>>>> If you check the comment on protection_map in mm/mmap.c, the difference >>>>> between private and shared is in real write vs. COW-able write. That's >>>>> what my patch is exploiting to get the proper arch-dependent page >>>>> protection bits. >>>>> >>>>> Are you aware of side effects or do you know a better way to inject >>>>> write permissions into the protection flags? >>>> >>>> I would tend to think that shared and private mappings do not react the >>>> same way when we write to them. >>> >>> Yes, private mappings can undergo COW. >> >> My point exactly, so, say, if the mapping is an anonymous mapping with >> only the zero page mapped, you will allow writing to the zero page, this >> does not look like a sane thing to do. The same goes for private file >> mappings where the code need to be modified (for instance relocations >> when mixing non PIC code with PIC code). > > To my understanding, and testing seems to confirm this, the branch under > vma_wants_writenotify in mprotect_fixup: if there is a need to fault ^handles this
> even on shared pages (or pseudo-shared in our case), vm_page_prot will > be overwritten anyway. > Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux _______________________________________________ Adeos-main mailing list [email protected] https://mail.gna.org/listinfo/adeos-main
