Re: security/polkit not working with evbarm-current

[Michael Plass <mfpnb%plass-family.net@localhost>]

On Jun 26, 2016, at 3:41 PM, Michael Plass wrote:

> 
> On Jun 26, 2016, at 2:03 AM, Thomas Klausner wrote:
> 
>> On Sat, Jun 25, 2016 at 07:30:52PM -0700, Michael Plass wrote:
>>> 
>>> On Jun 25, 2016, at 3:50 PM, Michael Plass wrote:
>>> 
>>>> On Jun 25, 2016, at 11:55 AM, Thomas Klausner wrote:
>>>> 
>>>>> On Wed, Jun 22, 2016 at 07:15:59PM -0700, Michael Plass wrote:
>>>>>> On Jun 14, 2016, at 12:13 AM, John Klos wrote:
>>>>>> 
>>>>>>> /usr/local/bin/xsltproc -nonet --stringparam man.base.url.for.relative.links /usr/local/share/gtk-doc/html/polkit-1/ --xincludehttp://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl pkcheck.xml
>>>>>>> /usr/local/lib/libgcrypt.so.20: text relocations/usr/local/lib/libgcrypt.so.20: text relocations
>>>>>>> 
>>>>>>> /usr/local/lib/libgcrypt.so.20: Cannot write-enable text segment: Permission denied/usr/local/lib/libgcrypt.so.20: Cannot write-enable text segment: Permission denied
>>>>>>> 
>>>>>>> /usr/local/lib/libgcrypt.so.20: text relocations/usr/local/lib/libgcrypt.so.20: text relocations
>>>>>>> 
>>>>>>> /usr/local/lib/libgcrypt.so.20: Cannot write-enable text segment: Permission denied/usr/local/lib/libgcrypt.so.20: Cannot write-enable text segment: Permission denied
>>>>>>> 
>>>>>>> gmake[3]: *** [Makefile:647: polkitd.8] Error 1
>>>>>> 
>>>>>> I ran into a similar problem today, building devel/git-contrib.
>>>>>> A workaround is
>>>>>> 
>>>>>> # paxctl +m /usr/pkg/bin/xsltproc
>>>>>> 
>>>>>> (see http://mail-index.netbsd.org/current-users/2016/05/20/msg029398.html)
>>>>> 
>>>>> That's strange. This paxctl is not necessary for me on 7.99.32/amd64,
>>>>> and I don't think there should be differences between the
>>>>> architectures in this regard. (My cc1 also does not need +m.)
>>>>> 
>>>>> Can you update to 7.99.32 and check if it's still needed?
>>>>> Thomas
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> Will do - I happen to have a build underway.
>>>> 
>>>> But I think it may be in libgcrypt, which has a fair bit of assembly code
>>>> for various architectures, including armv7-neon. All of the programs in 
>>>> /usr/pkgsrc/security/libgcrypt/work/libgcrypt-1.7.1/tests get the same message:
>>>> 
>>>> $ /usr/pkgsrc/security/libgcrypt/work/libgcrypt-1.7.1/tests/version
>>>> /usr/pkg/lib/libgcrypt.so.20: text relocations
>>>> /usr/pkg/lib/libgcrypt.so.20: Cannot write-enable text segment: Permission denied
>>>> 
>>>> - Michael
>>>> 
>>>> NetBSD mipi 7.99.30 NetBSD 7.99.30 (RPI2) #3: Sun Jun 19 20:55:51 PDT 2016  michael@mipi:/usr/obj/sys/arch/evbarm/compile/RPI2 evbarm
>>>> 
>>> 
>>> Indeed, configuring libgcrypt with --disable-neon-support seems to avoid the problem.
>> 
>> I don't speak ARM ASM; do you want to fix it or should we use
>> --disable-neon-support for now to work around it?
>> Thomas
>> 
>> 
> 
> 
> I'm not very familiar with ARM ASM myself, but I think I tracked
> down the offending instruction. With the following change, the
> library reference works:
> =======================
> diff --git a/work/libgcrypt-1.7.1/cipher/poly1305-armv7-neon.S b/work/libgcrypt-1.7.1/cipher/poly1305-armv7-neon.S
> index 1134e85..e2727bd 100644
> --- a/work/libgcrypt-1.7.1/cipher/poly1305-armv7-neon.S
> +++ b/work/libgcrypt-1.7.1/cipher/poly1305-armv7-neon.S
> @@ -52,7 +52,7 @@ _gcry_poly1305_armv7_neon_init_ext:
> 	and r2, r2, r2
> 	moveq r14, #-1
> 	ldmia r1!, {r2-r5}
> -	ldr r7, =.Lpoly1305_init_constants_neon
> +	adr r7, .Lpoly1305_init_constants_neon
> 	mov r6, r2
> 	mov r8, r2, lsr #26
> 	mov r9, r3, lsr #20
> =======================
> Running   make check  gets a bus error in tests/basic, but that's doing
> an aes test so I don't think it's related to the poly1305 change. The rest
> of the tests pass (hashtest-256g was skipped).
> 
> Hopefully someone who does know ARM ASM can review the above change!

Thomas,

I ran some tests, and I think the patch I provided for poly1305 is OK.

I also investigated the bus error in tests/basic. This happens on armv7 because
the assembly code in cipher/rijndael-arm.S assumes that unaligned accesses are OK,
which is true except for ldm/stm (load and store multiple). On armv6 it works because
the assembler does not define __ARM_FEATURE_UNALIGNED, so the extra instructions to
handle the alignment are generated. So I tried undefining this symbol near the top
of the module, and this allowed the tests to pass. By the way, disabling neon
support doesn't help with this second problem.

Here's the diff for both fixes:
==================================
diff --git a/work/libgcrypt-1.7.1/cipher/poly1305-armv7-neon.S b/work/libgcrypt-1.7.1/cipher/poly1305-armv7-neon.S
index 1134e85..e2727bd 100644
--- a/work/libgcrypt-1.7.1/cipher/poly1305-armv7-neon.S
+++ b/work/libgcrypt-1.7.1/cipher/poly1305-armv7-neon.S
@@ -52,7 +52,7 @@ _gcry_poly1305_armv7_neon_init_ext:
        and r2, r2, r2
        moveq r14, #-1
        ldmia r1!, {r2-r5}
-       ldr r7, =.Lpoly1305_init_constants_neon
+       adr r7, .Lpoly1305_init_constants_neon
        mov r6, r2
        mov r8, r2, lsr #26
        mov r9, r3, lsr #20
diff --git a/work/libgcrypt-1.7.1/cipher/rijndael-arm.S b/work/libgcrypt-1.7.1/cipher/rijndael-arm.S
index 694369d..34a9acc 100644
--- a/work/libgcrypt-1.7.1/cipher/rijndael-arm.S
+++ b/work/libgcrypt-1.7.1/cipher/rijndael-arm.S
@@ -19,6 +19,7 @@
  */
 
 #include <config.h>
+#undef __ARM_FEATURE_UNALIGNED
 
 #if defined(__ARMEL__)
 #ifdef HAVE_COMPATIBLE_GCC_ARM_PLATFORM_AS
==================================

Thanks,
- Michael