On Mon, May 02, 2022 at 08:40:23AM +0000, Klemens Nanni wrote: > On Fri, Mar 25, 2022 at 11:27:12AM +0000, Klemens Nanni wrote: > > On Fri, Mar 25, 2022 at 08:47:39AM +0100, Theo Buehler wrote: > > > On Fri, Mar 25, 2022 at 06:42:26AM +0100, Rafael Sadowski wrote: > > > > On Thu Mar 24, 2022 at 03:27:04PM +0000, Klemens Nanni wrote: > > > > > On Tue, Mar 15, 2022 at 09:23:51PM +0000, Klemens Nanni wrote: > > > > > > On Tue, Mar 15, 2022 at 08:20:35PM +0000, Stuart Henderson wrote: > > > > > > > On 2022/03/15 21:03, Theo Buehler wrote: > > > > > > > > On Tue, Mar 15, 2022 at 07:47:03PM +0000, Klemens Nanni wrote: > > > > > > > > > On Tue, Mar 15, 2022 at 06:27:13PM +0000, Klemens Nanni wrote: > > > > > > > > > > Just tried it on a kern.wxabort=1 machine which causes > > > > > > > > > > > > > > > > > > > > At least two programs in this port need W^X: > > > > > > > > > > kdeconnect-app(83050): mmap W^X violation > > > > > > > > > > kdeconnect-sms(27246): mmap W^X violation > > > > > > > > > > > > > > > > > > > > OK? > > > > > > > > > > > > > > > > > > > RCS file: /cvs/ports/net/neochat/Makefile,v > > > > > > > > > > > > > > > > > > Used an old mail as template and forgot to send the right > > > > > > > > > patch... > > > > > > > > > > > > > > > > Before USE_WXNEEDED is sprinkled all over kde/Qt ports, what is > > > > > > > > the root > > > > > > > > cause of this? Can it perhaps be neutered? > > > > > > > > > > > > > > By sprinkling USE_WXNEEDED you allow software to carry out these > > > > > > > mappings _even if they don't need them_. > > > > > > > > > > > > > > The default kern.wxabort=0 setting returns a failure to the > > > > > > > software > > > > > > > rather than killing it. This is like what PaX does. It's not > > > > > > > uncommon > > > > > > > for software to handle this case correctly: try a mapping, if it > > > > > > > fails > > > > > > > then use a non-W+X fallback. > > > > > > > > > > > > Thanks for the feedback (both on- and off-list). > > > > > > > > > > > > Turns out both neochat and kdeconnect-kde abort in the same Qt5Qml > > > > > > lib > > > > > > which in fact has fallback code for W^X mappings, i.e. it'll > > > > > > gracefully > > > > > > try non-W^X mappings. > > > > > > > > > > > > That W^X check is what's triggering wxabort=1 in the first place, so > > > > > > by neutering the check on OpenBSD we can avoid triggering it and > > > > > > thus > > > > > > USE_WXNEEDED=Yes. > > > > > > > > > > > > Feedback? Obejctions? OK? > > > > > > > > > > Anyone? > > > > > > > > It looks good and makes sense but I think it's better to test with more > > > > qtdeclarative consumers and for this reason I would wait until after > > > > 7.1. > > > > > > It makes sense to wait with this until after release. However, I think > > > in that case we should revert the various USE_WXNEEDED patches that > > > already landed. > > > > > > > Is that okay with you? If yes, ok rsadowski@ > > > > > > I do not know how QT_CONFIG works, but I suspect that this patch has > > > the same effect as disabling QT_CONFIG(qml_jit) so maybe something in > > > the makefile might be enough to achieve the same effect. > > > > Thanks, I'll do the reverts now and defer the Qt fix; maybe I'll have > > time to look into the qml_jit approach until then. > > I haven't had time to look at qml_jit, but the proposed fix does work > and I have an OK from rsadowksi. > > OK to commit that to fix packages and polish the patch later?
I'm no Qt user, so I really didn't intend to block progress rather than just pointing out a possible alternative - sorry. There's now rsadowski's diff that seems to do what I suggested: https://marc.info/?l=openbsd-ports&m=165116024523912&w=2 If you prefer your approach, just go ahead. > > > Index: x11/qt5/qtdeclarative/Makefile > =================================================================== > RCS file: /cvs/ports/x11/qt5/qtdeclarative/Makefile,v > retrieving revision 1.18 > diff -u -p -r1.18 Makefile > --- x11/qt5/qtdeclarative/Makefile 11 Mar 2022 20:16:59 -0000 1.18 > +++ x11/qt5/qtdeclarative/Makefile 15 Mar 2022 20:38:50 -0000 > @@ -4,6 +4,8 @@ USE_WXNEEDED = Yes > QT5NAME = QtDeclarative > COMMENT-main = Qt5 Quick and QML components > > +REVISION-main = 0 > + > MULTI_PACKAGES = -main -examples > DPB_PROPERTIES = parallel > > Index: > x11/qt5/qtdeclarative/patches/patch-src_3rdparty_masm_wtf_OSAllocatorPosix_cpp > =================================================================== > RCS file: > x11/qt5/qtdeclarative/patches/patch-src_3rdparty_masm_wtf_OSAllocatorPosix_cpp > diff -N > x11/qt5/qtdeclarative/patches/patch-src_3rdparty_masm_wtf_OSAllocatorPosix_cpp > --- /dev/null 1 Jan 1970 00:00:00 -0000 > +++ > x11/qt5/qtdeclarative/patches/patch-src_3rdparty_masm_wtf_OSAllocatorPosix_cpp > 15 Mar 2022 21:20:10 -0000 > @@ -0,0 +1,16 @@ > +canAllocateExecutableMemory() maps memory W^X to see if that is allowed, > +which triggers our kern.wxabort sysctl(2); always return false to neuter > +that mmap(2) test call and have (at least libQt5Qml) always fall back to > +non-W^X mappings. > + > +Index: src/3rdparty/masm/wtf/OSAllocatorPosix.cpp > +--- src/3rdparty/masm/wtf/OSAllocatorPosix.cpp.orig > ++++ src/3rdparty/masm/wtf/OSAllocatorPosix.cpp > +@@ -262,6 +262,7 @@ void OSAllocator::releaseDecommitted(void* address, si > + > + bool OSAllocator::canAllocateExecutableMemory() > + { > ++ return false; > + int flags = MAP_PRIVATE | MAP_ANON; > + #if PLATFORM(IOS) > + if (executable)
