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)
No comments:
Post a Comment