On Monday, May 23, 2016 15:34 CEST, Jeremie Courreges-Anglas <[email protected]> wrote:
> "Sebastian Reitenbach" <[email protected]> writes: > > > > > On Monday, May 23, 2016 14:00 CEST, Jeremie Courreges-Anglas > > <[email protected]> wrote: > > > >> Stuart Henderson <[email protected]> writes: > >> > >> > This disables PROT_EXEC mappings in libffi (and thus python). > >> > I'm running with it in a bulk build with the "mandatory W^X" > >> > printfs that are going into snapshots and haven't triggered > >> > them yet, building python itself (done 2.7 and 3.4 so far) > >> > or in the ~200 py-* and py3-* things that have built already > >> > (I would have had a whole stack by now otherwise). > >> > > >> > There are a lot of test failures when this diff is used. > >> > Can anyone figure out if they're anything to worry about? > >> > >> So I think the problem is simply that since the closure isn't allocated > >> with PROT_EXEC permissions, you can't... execute it. > >> > >> I'm kinda discovering libffi so sorry in advance if I'm mistaken, but it > >> seems that the logical steps are always: > >> - ffi_closure_alloc > >> - ffi_prep_closure_loc > >> - ffi_closure_free > >> > > > > I was looking what the gnustep conftest is doing, and I also found > > the ffi_closure_alloc function, that comment on the function says: > > > > /* Allocate a chunk of memory with the given size. Returns a pointer > > to the writable address, and sets *CODE to the executable > > corresponding virtual address. */ > > void * > > ffi_closure_alloc (size_t size, void **code) > > > > but both code and the return value point to the same address. > > whereas I think those should differ? > > IIUC they would differ on OSes where libffi can't get a single mapping > with both W and X access. On those OSes libffi uses a workaround, two > mappings are allocated one with RW, the other with RX. While we want to > disable RWX on OpenBSD as an end goal, I don't think we want to let > libffi use this hack, 'cause it it basically the same as RWX. Oh, I was thinking that both are supposed to point to different locations, and not to the same. > > > Then ffi_prep_closure_loc should do the right thing? > > Hmm, I'm not sure I understand what you mean by this. with the different locations handed over to ffi_prep_closure_loc, it would kind of get it right. But I don't want to exclude I got things totally wrong. Sebastian > > [...] > > -- > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
