Re: missing endbr64

2024-02-29 Thread Theo Buehler
On Thu, Feb 29, 2024 at 11:01:49AM +0100, Sebastian Reitenbach wrote:
> On Wednesday, February 28, 2024 22:49 CET, Theo Buehler 
>  wrote:
> 
> > On Wed, Feb 28, 2024 at 10:44:27PM +0100, Sebastian Reitenbach wrote:
> > > Hi,
> > > On Wednesday, February 28, 2024 21:13 CET, Theo Buehler 
> > >  wrote:
> > > 
> > > > On Sun, Feb 25, 2024 at 10:13:44PM +0100, Sebastian Reitenbach wrote:
> > > > > On Sunday, February 25, 2024 16:44 CET, Mark Kettenis 
> > > > >  wrote:
> > > > > 
> 
> Tested your patch, the warnings are gone. A couple of apps tested, seems to 
> work.
> I don't have a machine where it would cause aborts.
> 
> Additionally, the typo fix (which I found in upstream already fixed) also 
> prevents the
> Git checkout at configure stage. The revision bump might not be needed, as no 
> packages
> could have been built, but someone might have manually built it?

Yes, this definitely needs a bump.

> OK?

ok tb, but please give kettenis a chance to take a look.

> 
> Sebastian
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/x11/gnustep/libobjc2/Makefile,v
> diff -u -r1.34 Makefile
> --- Makefile  28 Feb 2024 19:52:15 -  1.34
> +++ Makefile  29 Feb 2024 09:54:53 -
> @@ -4,7 +4,7 @@
>  
>  # note: this port does not use the gnustep module
>  VERSION =2.2
> -REVISION =   0
> +REVISION =   1
>  GH_ACCOUNT = gnustep
>  GH_PROJECT = libobjc2
>  GH_TAGNAME = v${VERSION}
> Index: patches/patch-CMakeLists_txt
> ===
> RCS file: patches/patch-CMakeLists_txt
> diff -N patches/patch-CMakeLists_txt
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-CMakeLists_txt  29 Feb 2024 09:54:53 -
> @@ -0,0 +1,12 @@
> +Index: CMakeLists.txt
> +--- CMakeLists.txt.orig
>  CMakeLists.txt
> +@@ -126,7 +126,7 @@ endif ()
> + 
> + find_package(tsl-robin-map)
> + 
> +-if (NOT tls-robin-map_FOUND)
> ++if (NOT tsl-robin-map_FOUND)
> + FetchContent_Declare(
> + robinmap
> + GIT_REPOSITORY https://github.com/Tessil/robin-map/
> Index: patches/patch-block_trampolines_S
> ===
> RCS file: patches/patch-block_trampolines_S
> diff -N patches/patch-block_trampolines_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-block_trampolines_S 29 Feb 2024 09:54:53 -
> @@ -0,0 +1,19 @@
> +Index: block_trampolines.S
> +--- block_trampolines.S.orig
>  block_trampolines.S
> +@@ -22,6 +22,7 @@
> + // x86-64 trampoline
> + 
> 
> + .macro trampoline arg0, arg1
> ++endbr64
> + mov   -0x1007(%rip), \arg1   # Load the block pointer into the second 
> argument
> + xchg  \arg1, \arg0   # Swap the first and second arguments
> + jmp   *-0x1008(%rip) # Call the block function
> +@@ -121,6 +122,7 @@
> + // AArch64 (ARM64) trampoline
> + 
> 
> + .macro trampoline arg0, arg1
> ++bti c
> + adr x17, #-4096
> + mov \arg1, \arg0
> + ldp \arg0, x17, [x17]
> Index: patches/patch-objc_msgSend_aarch64_S
> ===
> RCS file: patches/patch-objc_msgSend_aarch64_S
> diff -N patches/patch-objc_msgSend_aarch64_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-objc_msgSend_aarch64_S  29 Feb 2024 09:54:53 -
> @@ -0,0 +1,12 @@
> +Index: objc_msgSend.aarch64.S
> +--- objc_msgSend.aarch64.S.orig
>  objc_msgSend.aarch64.S
> +@@ -47,7 +47,7 @@
> + #   define EH_NOP .seh_nop
> + #else
> + // Marks the real start and end of the function
> +-#   define EH_START .cfi_startproc
> ++#   define EH_START .cfi_startproc; bti c
> + #   define EH_END .cfi_endproc
> + 
> + // The following directives are either not
> Index: patches/patch-objc_msgSend_x86-64_S
> ===
> RCS file: patches/patch-objc_msgSend_x86-64_S
> diff -N patches/patch-objc_msgSend_x86-64_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-objc_msgSend_x86-64_S   29 Feb 2024 09:54:53 -
> @@ -0,0 +1,12 @@
> +Index: objc_msgSend.x86-64.S
> +--- objc_msgSend.x86-64.S.orig
>  objc_msgSend.x86-64.S
> +@@ -8,7 +8,7 @@
> + #   define SECOND_ARGUMENT %rdx
> + #   define THIRD_ARGUMENT %r8
> + #else
> +-#   define START_PROC(x) .cfi_startproc
> ++#   define START_PROC(x) .cfi_startproc; endbr64
> + #   define END_PROC(x) .cfi_endproc
> + #   define FRAME_OFFSET(x) .cfi_adjust_cfa_offset x
> + #   define FIRST_ARGUMENT_STR "%rdi"
> 



Re: missing endbr64

2024-02-29 Thread Sebastian Reitenbach
On Wednesday, February 28, 2024 22:49 CET, Theo Buehler  
wrote:

> On Wed, Feb 28, 2024 at 10:44:27PM +0100, Sebastian Reitenbach wrote:
> > Hi,
> > On Wednesday, February 28, 2024 21:13 CET, Theo Buehler 
> >  wrote:
> > 
> > > On Sun, Feb 25, 2024 at 10:13:44PM +0100, Sebastian Reitenbach wrote:
> > > > On Sunday, February 25, 2024 16:44 CET, Mark Kettenis 
> > > >  wrote:
> > > > 

Tested your patch, the warnings are gone. A couple of apps tested, seems to 
work.
I don't have a machine where it would cause aborts.

Additionally, the typo fix (which I found in upstream already fixed) also 
prevents the
Git checkout at configure stage. The revision bump might not be needed, as no 
packages
could have been built, but someone might have manually built it?

OK?

Sebastian

Index: Makefile
===
RCS file: /cvs/ports/x11/gnustep/libobjc2/Makefile,v
diff -u -r1.34 Makefile
--- Makefile28 Feb 2024 19:52:15 -  1.34
+++ Makefile29 Feb 2024 09:54:53 -
@@ -4,7 +4,7 @@
 
 # note: this port does not use the gnustep module
 VERSION =  2.2
-REVISION = 0
+REVISION = 1
 GH_ACCOUNT =   gnustep
 GH_PROJECT =   libobjc2
 GH_TAGNAME =   v${VERSION}
Index: patches/patch-CMakeLists_txt
===
RCS file: patches/patch-CMakeLists_txt
diff -N patches/patch-CMakeLists_txt
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-CMakeLists_txt29 Feb 2024 09:54:53 -
@@ -0,0 +1,12 @@
+Index: CMakeLists.txt
+--- CMakeLists.txt.orig
 CMakeLists.txt
+@@ -126,7 +126,7 @@ endif ()
+ 
+ find_package(tsl-robin-map)
+ 
+-if (NOT tls-robin-map_FOUND)
++if (NOT tsl-robin-map_FOUND)
+   FetchContent_Declare(
+   robinmap
+   GIT_REPOSITORY https://github.com/Tessil/robin-map/
Index: patches/patch-block_trampolines_S
===
RCS file: patches/patch-block_trampolines_S
diff -N patches/patch-block_trampolines_S
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-block_trampolines_S   29 Feb 2024 09:54:53 -
@@ -0,0 +1,19 @@
+Index: block_trampolines.S
+--- block_trampolines.S.orig
 block_trampolines.S
+@@ -22,6 +22,7 @@
+ // x86-64 trampoline
+ 

+ .macro trampoline arg0, arg1
++  endbr64
+   mov   -0x1007(%rip), \arg1   # Load the block pointer into the second 
argument
+   xchg  \arg1, \arg0   # Swap the first and second arguments
+   jmp   *-0x1008(%rip) # Call the block function
+@@ -121,6 +122,7 @@
+ // AArch64 (ARM64) trampoline
+ 

+ .macro trampoline arg0, arg1
++  bti c
+   adr x17, #-4096
+   mov \arg1, \arg0
+   ldp \arg0, x17, [x17]
Index: patches/patch-objc_msgSend_aarch64_S
===
RCS file: patches/patch-objc_msgSend_aarch64_S
diff -N patches/patch-objc_msgSend_aarch64_S
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-objc_msgSend_aarch64_S29 Feb 2024 09:54:53 -
@@ -0,0 +1,12 @@
+Index: objc_msgSend.aarch64.S
+--- objc_msgSend.aarch64.S.orig
 objc_msgSend.aarch64.S
+@@ -47,7 +47,7 @@
+ #   define EH_NOP .seh_nop
+ #else
+ // Marks the real start and end of the function
+-#   define EH_START .cfi_startproc
++#   define EH_START .cfi_startproc; bti c
+ #   define EH_END .cfi_endproc
+ 
+ // The following directives are either not
Index: patches/patch-objc_msgSend_x86-64_S
===
RCS file: patches/patch-objc_msgSend_x86-64_S
diff -N patches/patch-objc_msgSend_x86-64_S
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-objc_msgSend_x86-64_S 29 Feb 2024 09:54:53 -
@@ -0,0 +1,12 @@
+Index: objc_msgSend.x86-64.S
+--- objc_msgSend.x86-64.S.orig
 objc_msgSend.x86-64.S
+@@ -8,7 +8,7 @@
+ # define SECOND_ARGUMENT %rdx
+ # define THIRD_ARGUMENT %r8
+ #else
+-# define START_PROC(x) .cfi_startproc
++# define START_PROC(x) .cfi_startproc; endbr64
+ # define END_PROC(x) .cfi_endproc
+ # define FRAME_OFFSET(x) .cfi_adjust_cfa_offset x
+ # define FIRST_ARGUMENT_STR "%rdi"



Re: libdv: missing ENDBR64

2024-02-28 Thread Mark Kettenis
> Date: Wed, 28 Feb 2024 20:10:58 +0100
> From: Theo Buehler 
> 
> This is straightforward. There doesn't seem to be a possibility of
> shortcuts via a macro, so just add endbr64 to the four functions in this
> file. I could not find code that actually uses these, but it's probably
> better to be safe than sorry.
> 
> The code is too old to have arm64 assembly.

ok kettenis@

> Index: Makefile
> ===
> RCS file: /cvs/ports/multimedia/libdv/Makefile,v
> diff -u -p -r1.28 Makefile
> --- Makefile  7 Nov 2023 14:19:39 -   1.28
> +++ Makefile  28 Feb 2024 19:01:33 -
> @@ -1,7 +1,7 @@
>  COMMENT= Quasar DV codec
>  
>  DISTNAME=libdv-1.0.0
> -REVISION=4
> +REVISION=5
>  
>  CATEGORIES=  multimedia
>  
> Index: patches/patch-libdv_vlc_x86_64_S
> ===
> RCS file: patches/patch-libdv_vlc_x86_64_S
> diff -N patches/patch-libdv_vlc_x86_64_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-libdv_vlc_x86_64_S  28 Feb 2024 19:00:50 -
> @@ -0,0 +1,35 @@
> +Index: libdv/vlc_x86_64.S
> +--- libdv/vlc_x86_64.S.orig
>  libdv/vlc_x86_64.S
> +@@ -6,6 +6,7 @@
> + .globl dv_decode_vlc
> + .typedv_decode_vlc,@function
> + dv_decode_vlc:
> ++endbr64
> + push %rbx
> + push %rbp
> + 
> +@@ -102,6 +103,7 @@ void __dv_decode_vlc(int bits, dv_vlc_t *result)
> + .globl __dv_decode_vlc
> + .type__dv_decode_vlc,@function
> + __dv_decode_vlc:
> ++endbr64
> + push %rbx
> + push %rbp
> + 
> +@@ -174,6 +176,7 @@ void dv_parse_ac_coeffs_pass0(bitstream_t *bs,
> + .type   dv_parse_ac_coeffs_pass0,@function
> + 
> + dv_parse_ac_coeffs_pass0:
> ++endbr64
> + 
> + /* Args are at rdi=bs, rsi=mb, rdx=bl */
> + push%r12
> +@@ -427,6 +430,7 @@ gint dv_parse_video_segment(dv_videosegment_t *seg, gu
> + .globl dv_parse_video_segment
> + .type  dv_parse_video_segment,@function
> + dv_parse_video_segment:
> ++endbr64
> + 
> + /* Args are at rdi=seg, rsi=quality */
> + push%r12
> 



Re: missing endbr64

2024-02-28 Thread Stuart Henderson
On 2024/02/28 22:49, Theo Buehler wrote:
> PORTS_PRIVSEP should catch such things. (The CMakeLists file also has
> a tls vs tsl typo)

Plus pf.conf rules to block network access from _pbuild e.g. something
along these lines (the first one is optional but helps with some tests
that otherwise fail)

pass quick proto {tcp udp} to 127.0.0.1 user _pbuild
block return quick proto {tcp udp} user _pbuild



Re: missing endbr64

2024-02-28 Thread Theo Buehler
On Wed, Feb 28, 2024 at 10:44:27PM +0100, Sebastian Reitenbach wrote:
> Hi,
> On Wednesday, February 28, 2024 21:13 CET, Theo Buehler 
>  wrote:
> 
> > On Sun, Feb 25, 2024 at 10:13:44PM +0100, Sebastian Reitenbach wrote:
> > > On Sunday, February 25, 2024 16:44 CET, Mark Kettenis 
> > >  wrote:
> > > 
> > > > > x11/gnustep/libobjc2.log
> > > > > ld: warning: __objc_block_trampoline_sret: missing endbr64
> > > > > ld: warning: __objc_block_trampoline: missing endbr64
> > > > > ld: warning: objc_msgSend: missing endbr64
> > > > > ld: warning: objc_msgSend_fpret: missing endbr64
> > > > > ld: warning: objc_msgSend_stret: missing endbr64
> > > > 
> > > > I guess this is very similay to devel/objfw.  Just add endbr64 to
> > > > those functions like we did there.  No aarch64 support here by the
> > > > looks of it.
> > > 
> > > Above version of libobjc2 is old, but due to build errors, and runtime 
> > > errors, I was 
> > > unable to upgrade. However, a new version was released just a few days 
> > > ago, and that one even builds
> > > and doesn't show runtime errors so far.
> > > I updated one test box, to get these new ld warnings, there are only 
> > > these left on amd64:
> > > 
> > > ld: warning: objc_msgSend: missing endbr64
> > > ld: warning: objc_msgSend_fpret: missing endbr64
> > > ld: warning: objc_msgSend_stret: missing endbr64
> > > 
> > > Which are all the platforms, that need such fix? I see objc_msgSend_fpret 
> > > for aarch64, arm, 
> > > amd64, i386, mips and riscv64.
> > > 
> > > Attached patch to update to the new 2.2 release, without any fixes for 
> > > the missing endbr64.
> > > 
> > > Sebastian
> > 
> > Not sure what to do for riscv64.
> > 
> > The diff below on top of what you committed a few minutes ago should do
> > the trick. However, the port needs fixing because of this:
> > 
> > [1/9] Performing download step (git clone) for 'robinmap-populate'
> > Cloning into 'robinmap-src'...
> > fatal: unable to access 'https://github.com/Tessil/robin-map/': Could not 
> > resolve host: github.com
> > Cloning into 'robinmap-src'...
> > fatal: unable to access 'https://github.com/Tessil/robin-map/': Could not 
> > resolve host: github.com
> > Cloning into 'robinmap-src'...
> > fatal: unable to access 'https://github.com/Tessil/robin-map/': Could not 
> > resolve host: github.com
> > -- Had to git clone more than once: 3 times.
> > CMake Error at 
> > robinmap-subbuild/robinmap-populate-prefix/tmp/robinmap-populate-gitclone.cmake:39
> >  (message):
> >   Failed to clone repository: 'https://github.com/Tessil/robin-map/'
> > 
> do you have robin-map-1.2.1 installed, or some older version?

Yes I saw it on two machines with 1.2.1 installed.

> I haven't seen that here, but can trash that downloading with a patch if 
> necessary.

PORTS_PRIVSEP should catch such things. (The CMakeLists file also has
a tls vs tsl typo)

> 
> I was just working on it (without having any clue what I'm doing here)
> It got rid of the warnings, but looks differently to what you have.
> I'll try your patch below Tomorrow
> 
> cheers,
> Sebastian
> 
> > 
> > Index: patches/patch-block_trampolines_S
> > ===
> > RCS file: patches/patch-block_trampolines_S
> > diff -N patches/patch-block_trampolines_S
> > --- /dev/null   1 Jan 1970 00:00:00 -
> > +++ patches/patch-block_trampolines_S   28 Feb 2024 20:08:24 -
> > @@ -0,0 +1,19 @@
> > +Index: block_trampolines.S
> > +--- block_trampolines.S.orig
> >  block_trampolines.S
> > +@@ -22,6 +22,7 @@
> > + // x86-64 trampoline
> > + 
> > 
> > + .macro trampoline arg0, arg1
> > ++  endbr64
> > +   mov   -0x1007(%rip), \arg1   # Load the block pointer into the second 
> > argument
> > +   xchg  \arg1, \arg0   # Swap the first and second arguments
> > +   jmp   *-0x1008(%rip) # Call the block function
> > +@@ -121,6 +122,7 @@
> > + // AArch64 (ARM64) trampoline
> > + 
> > 
> > + .macro trampoline arg0, arg1
> > ++  bti c
> > +   adr x17, #-4096
> > +   mov \arg1, \arg0
> > +   ldp \arg0, x17, [x17]

Re: libdv: missing ENDBR64

2024-02-28 Thread Stuart Henderson
On 2024/02/28 20:10, Theo Buehler wrote:
> This is straightforward. There doesn't seem to be a possibility of
> shortcuts via a macro, so just add endbr64 to the four functions in this
> file. I could not find code that actually uses these, but it's probably
> better to be safe than sorry.
> 
> The code is too old to have arm64 assembly.

I found a test file at
https://downloads.sourceforge.net/project/libdv/examples/examples/pond.dv)

Not really sure how to test properly; mplayer depends on it but
actually uses libavformat to play them (and works on a build without
USE_NOBTCFI). Anyway LGTM, OK sthen@.


> Index: Makefile
> ===
> RCS file: /cvs/ports/multimedia/libdv/Makefile,v
> diff -u -p -r1.28 Makefile
> --- Makefile  7 Nov 2023 14:19:39 -   1.28
> +++ Makefile  28 Feb 2024 19:01:33 -
> @@ -1,7 +1,7 @@
>  COMMENT= Quasar DV codec
>  
>  DISTNAME=libdv-1.0.0
> -REVISION=4
> +REVISION=5
>  
>  CATEGORIES=  multimedia
>  
> Index: patches/patch-libdv_vlc_x86_64_S
> ===
> RCS file: patches/patch-libdv_vlc_x86_64_S
> diff -N patches/patch-libdv_vlc_x86_64_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-libdv_vlc_x86_64_S  28 Feb 2024 19:00:50 -
> @@ -0,0 +1,35 @@
> +Index: libdv/vlc_x86_64.S
> +--- libdv/vlc_x86_64.S.orig
>  libdv/vlc_x86_64.S
> +@@ -6,6 +6,7 @@
> + .globl dv_decode_vlc
> + .typedv_decode_vlc,@function
> + dv_decode_vlc:
> ++endbr64
> + push %rbx
> + push %rbp
> + 
> +@@ -102,6 +103,7 @@ void __dv_decode_vlc(int bits, dv_vlc_t *result)
> + .globl __dv_decode_vlc
> + .type__dv_decode_vlc,@function
> + __dv_decode_vlc:
> ++endbr64
> + push %rbx
> + push %rbp
> + 
> +@@ -174,6 +176,7 @@ void dv_parse_ac_coeffs_pass0(bitstream_t *bs,
> + .type   dv_parse_ac_coeffs_pass0,@function
> + 
> + dv_parse_ac_coeffs_pass0:
> ++endbr64
> + 
> + /* Args are at rdi=bs, rsi=mb, rdx=bl */
> + push%r12
> +@@ -427,6 +430,7 @@ gint dv_parse_video_segment(dv_videosegment_t *seg, gu
> + .globl dv_parse_video_segment
> + .type  dv_parse_video_segment,@function
> + dv_parse_video_segment:
> ++endbr64
> + 
> + /* Args are at rdi=seg, rsi=quality */
> + push%r12
> 



Re: missing endbr64

2024-02-28 Thread Sebastian Reitenbach
Hi,
On Wednesday, February 28, 2024 21:13 CET, Theo Buehler  
wrote:

> On Sun, Feb 25, 2024 at 10:13:44PM +0100, Sebastian Reitenbach wrote:
> > On Sunday, February 25, 2024 16:44 CET, Mark Kettenis 
> >  wrote:
> > 
> > > > x11/gnustep/libobjc2.log
> > > > ld: warning: __objc_block_trampoline_sret: missing endbr64
> > > > ld: warning: __objc_block_trampoline: missing endbr64
> > > > ld: warning: objc_msgSend: missing endbr64
> > > > ld: warning: objc_msgSend_fpret: missing endbr64
> > > > ld: warning: objc_msgSend_stret: missing endbr64
> > > 
> > > I guess this is very similay to devel/objfw.  Just add endbr64 to
> > > those functions like we did there.  No aarch64 support here by the
> > > looks of it.
> > 
> > Above version of libobjc2 is old, but due to build errors, and runtime 
> > errors, I was 
> > unable to upgrade. However, a new version was released just a few days ago, 
> > and that one even builds
> > and doesn't show runtime errors so far.
> > I updated one test box, to get these new ld warnings, there are only these 
> > left on amd64:
> > 
> > ld: warning: objc_msgSend: missing endbr64
> > ld: warning: objc_msgSend_fpret: missing endbr64
> > ld: warning: objc_msgSend_stret: missing endbr64
> > 
> > Which are all the platforms, that need such fix? I see objc_msgSend_fpret 
> > for aarch64, arm, 
> > amd64, i386, mips and riscv64.
> > 
> > Attached patch to update to the new 2.2 release, without any fixes for the 
> > missing endbr64.
> > 
> > Sebastian
> 
> Not sure what to do for riscv64.
> 
> The diff below on top of what you committed a few minutes ago should do
> the trick. However, the port needs fixing because of this:
> 
> [1/9] Performing download step (git clone) for 'robinmap-populate'
> Cloning into 'robinmap-src'...
> fatal: unable to access 'https://github.com/Tessil/robin-map/': Could not 
> resolve host: github.com
> Cloning into 'robinmap-src'...
> fatal: unable to access 'https://github.com/Tessil/robin-map/': Could not 
> resolve host: github.com
> Cloning into 'robinmap-src'...
> fatal: unable to access 'https://github.com/Tessil/robin-map/': Could not 
> resolve host: github.com
> -- Had to git clone more than once: 3 times.
> CMake Error at 
> robinmap-subbuild/robinmap-populate-prefix/tmp/robinmap-populate-gitclone.cmake:39
>  (message):
>   Failed to clone repository: 'https://github.com/Tessil/robin-map/'
> 
do you have robin-map-1.2.1 installed, or some older version?
I haven't seen that here, but can trash that downloading with a patch if 
necessary.


I was just working on it (without having any clue what I'm doing here)
It got rid of the warnings, but looks differently to what you have.
I'll try your patch below Tomorrow

cheers,
Sebastian

> 
> Index: patches/patch-block_trampolines_S
> ===
> RCS file: patches/patch-block_trampolines_S
> diff -N patches/patch-block_trampolines_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-block_trampolines_S 28 Feb 2024 20:08:24 -
> @@ -0,0 +1,19 @@
> +Index: block_trampolines.S
> +--- block_trampolines.S.orig
>  block_trampolines.S
> +@@ -22,6 +22,7 @@
> + // x86-64 trampoline
> + 
> 
> + .macro trampoline arg0, arg1
> ++endbr64
> + mov   -0x1007(%rip), \arg1   # Load the block pointer into the second 
> argument
> + xchg  \arg1, \arg0   # Swap the first and second arguments
> + jmp   *-0x1008(%rip) # Call the block function
> +@@ -121,6 +122,7 @@
> + // AArch64 (ARM64) trampoline
> + 
> 
> + .macro trampoline arg0, arg1
> ++bti c
> + adr x17, #-4096
> + mov \arg1, \arg0
> + ldp \arg0, x17, [x17]
> Index: patches/patch-objc_msgSend_aarch64_S
> ===
> RCS file: patches/patch-objc_msgSend_aarch64_S
> diff -N patches/patch-objc_msgSend_aarch64_S
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-objc_msgSend_aarch64_S  28 Feb 2024 20:08:24 -
> @@ -0,0 +1,12 @@
> +Index: objc_msgSend.aarch64.S
> +--- objc_msgSend.aarch64.S.orig
>  objc_msgSend.aarch64.S
> +@@ -47,7 +47,7 @@
> + #   define EH_NOP .seh_nop
> + #else
> + // Marks the real start and end of the function
> +-#   define EH_START .cfi_startproc
> ++#   define EH_START .cfi_startproc; bti c
> + #   define EH_END .cfi_endproc

Re: missing endbr64

2024-02-28 Thread Theo Buehler
On Sun, Feb 25, 2024 at 10:13:44PM +0100, Sebastian Reitenbach wrote:
> On Sunday, February 25, 2024 16:44 CET, Mark Kettenis 
>  wrote:
> 
> > > x11/gnustep/libobjc2.log
> > > ld: warning: __objc_block_trampoline_sret: missing endbr64
> > > ld: warning: __objc_block_trampoline: missing endbr64
> > > ld: warning: objc_msgSend: missing endbr64
> > > ld: warning: objc_msgSend_fpret: missing endbr64
> > > ld: warning: objc_msgSend_stret: missing endbr64
> > 
> > I guess this is very similay to devel/objfw.  Just add endbr64 to
> > those functions like we did there.  No aarch64 support here by the
> > looks of it.
> 
> Above version of libobjc2 is old, but due to build errors, and runtime 
> errors, I was 
> unable to upgrade. However, a new version was released just a few days ago, 
> and that one even builds
> and doesn't show runtime errors so far.
> I updated one test box, to get these new ld warnings, there are only these 
> left on amd64:
> 
> ld: warning: objc_msgSend: missing endbr64
> ld: warning: objc_msgSend_fpret: missing endbr64
> ld: warning: objc_msgSend_stret: missing endbr64
> 
> Which are all the platforms, that need such fix? I see objc_msgSend_fpret for 
> aarch64, arm, 
> amd64, i386, mips and riscv64.
> 
> Attached patch to update to the new 2.2 release, without any fixes for the 
> missing endbr64.
> 
> Sebastian

Not sure what to do for riscv64.

The diff below on top of what you committed a few minutes ago should do
the trick. However, the port needs fixing because of this:

[1/9] Performing download step (git clone) for 'robinmap-populate'
Cloning into 'robinmap-src'...
fatal: unable to access 'https://github.com/Tessil/robin-map/': Could not 
resolve host: github.com
Cloning into 'robinmap-src'...
fatal: unable to access 'https://github.com/Tessil/robin-map/': Could not 
resolve host: github.com
Cloning into 'robinmap-src'...
fatal: unable to access 'https://github.com/Tessil/robin-map/': Could not 
resolve host: github.com
-- Had to git clone more than once: 3 times.
CMake Error at 
robinmap-subbuild/robinmap-populate-prefix/tmp/robinmap-populate-gitclone.cmake:39
 (message):
  Failed to clone repository: 'https://github.com/Tessil/robin-map/'


Index: patches/patch-block_trampolines_S
===
RCS file: patches/patch-block_trampolines_S
diff -N patches/patch-block_trampolines_S
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-block_trampolines_S   28 Feb 2024 20:08:24 -
@@ -0,0 +1,19 @@
+Index: block_trampolines.S
+--- block_trampolines.S.orig
 block_trampolines.S
+@@ -22,6 +22,7 @@
+ // x86-64 trampoline
+ 

+ .macro trampoline arg0, arg1
++  endbr64
+   mov   -0x1007(%rip), \arg1   # Load the block pointer into the second 
argument
+   xchg  \arg1, \arg0   # Swap the first and second arguments
+   jmp   *-0x1008(%rip) # Call the block function
+@@ -121,6 +122,7 @@
+ // AArch64 (ARM64) trampoline
+ 

+ .macro trampoline arg0, arg1
++  bti c
+   adr x17, #-4096
+   mov \arg1, \arg0
+   ldp \arg0, x17, [x17]
Index: patches/patch-objc_msgSend_aarch64_S
===
RCS file: patches/patch-objc_msgSend_aarch64_S
diff -N patches/patch-objc_msgSend_aarch64_S
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-objc_msgSend_aarch64_S28 Feb 2024 20:08:24 -
@@ -0,0 +1,12 @@
+Index: objc_msgSend.aarch64.S
+--- objc_msgSend.aarch64.S.orig
 objc_msgSend.aarch64.S
+@@ -47,7 +47,7 @@
+ #   define EH_NOP .seh_nop
+ #else
+ // Marks the real start and end of the function
+-#   define EH_START .cfi_startproc
++#   define EH_START .cfi_startproc; bti c
+ #   define EH_END .cfi_endproc
+ 
+ // The following directives are either not
Index: patches/patch-objc_msgSend_x86-64_S
===
RCS file: patches/patch-objc_msgSend_x86-64_S
diff -N patches/patch-objc_msgSend_x86-64_S
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-objc_msgSend_x86-64_S 28 Feb 2024 20:08:24 -
@@ -0,0 +1,12 @@
+Index: objc_msgSend.x86-64.S
+--- objc_msgSend.x86-64.S.orig
 objc_msgSend.x86-64.S
+@@ -8,7 +8,7 @@
+ # define SECOND_ARGUMENT %rdx
+ # define THIRD_ARGUMENT %r8
+ #else
+-# define START_PROC(x) .cfi_startproc
++# define START_PROC(x) .cfi_startproc; endbr64
+ # define END_PROC(x) .cfi_endproc
+ # define FRAME_OFFSET(x) .cfi_adjust_cfa_offset x
+ # define FIRST_ARGUMENT_STR "%rdi"



libdv: missing ENDBR64

2024-02-28 Thread Theo Buehler
This is straightforward. There doesn't seem to be a possibility of
shortcuts via a macro, so just add endbr64 to the four functions in this
file. I could not find code that actually uses these, but it's probably
better to be safe than sorry.

The code is too old to have arm64 assembly.

Index: Makefile
===
RCS file: /cvs/ports/multimedia/libdv/Makefile,v
diff -u -p -r1.28 Makefile
--- Makefile7 Nov 2023 14:19:39 -   1.28
+++ Makefile28 Feb 2024 19:01:33 -
@@ -1,7 +1,7 @@
 COMMENT=   Quasar DV codec
 
 DISTNAME=  libdv-1.0.0
-REVISION=  4
+REVISION=  5
 
 CATEGORIES=multimedia
 
Index: patches/patch-libdv_vlc_x86_64_S
===
RCS file: patches/patch-libdv_vlc_x86_64_S
diff -N patches/patch-libdv_vlc_x86_64_S
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-libdv_vlc_x86_64_S28 Feb 2024 19:00:50 -
@@ -0,0 +1,35 @@
+Index: libdv/vlc_x86_64.S
+--- libdv/vlc_x86_64.S.orig
 libdv/vlc_x86_64.S
+@@ -6,6 +6,7 @@
+ .globl dv_decode_vlc
+   .typedv_decode_vlc,@function
+ dv_decode_vlc:
++  endbr64
+   push %rbx
+   push %rbp
+ 
+@@ -102,6 +103,7 @@ void __dv_decode_vlc(int bits, dv_vlc_t *result)
+ .globl __dv_decode_vlc
+   .type__dv_decode_vlc,@function
+ __dv_decode_vlc:
++  endbr64
+   push %rbx
+   push %rbp
+ 
+@@ -174,6 +176,7 @@ void dv_parse_ac_coeffs_pass0(bitstream_t *bs,
+ .type dv_parse_ac_coeffs_pass0,@function
+ 
+ dv_parse_ac_coeffs_pass0:
++  endbr64
+   
+   /* Args are at rdi=bs, rsi=mb, rdx=bl */
+   push%r12
+@@ -427,6 +430,7 @@ gint dv_parse_video_segment(dv_videosegment_t *seg, gu
+   .globl dv_parse_video_segment
+   .type  dv_parse_video_segment,@function
+ dv_parse_video_segment:
++  endbr64
+   
+   /* Args are at rdi=seg, rsi=quality */
+   push%r12



Re: missing endbr64

2024-02-27 Thread Mark Kettenis
> Date: Tue, 27 Feb 2024 16:06:59 +
> From: Stuart Henderson 
> 
> On 2024/02/27 16:03, Stuart Henderson wrote:
> > On 2024/02/27 12:08, Theo Buehler wrote:
> > > Now that the bulk has completed here's the remainder of the list with
> > > two more that may need fixing. 119 ports total contained a warning.
> > > I did not build the chromium variants.
> > > 
> > > audio/deadbeef.log
> > > ld: warning: ff_scalarproduct_and_madd_int16_sse2: missing endbr64
> > 
> > This is when building the plugin for playback of monkey's audio (ape)
> > files (plugins/ffap) which has its own copy of (a very old version of)
> > some asm from ffmpeg, see plugins/ffap/x86inc.asm and dsputil_yasm.asm.
> > 
> > This seems to do the trick on amd64, there might be a better way but
> > I was struggling with yasm vs nasm syntax. I'm testing to make sure it
> > doesn't break i386 now.
> 
> Still builds on i386.

Using

%ifdef ARCH_X86_64
dd 0xfa1e0ff3
%endif

directly into the cglobal_internal macro worked fine in other places
that used yasm.  But your diff is probably a step closer to something
that would be accepted upstream.

Either way, ok kettenis@

> > This Index: Makefile
> > ===
> > RCS file: /cvs/ports/audio/deadbeef/Makefile,v
> > retrieving revision 1.53
> > diff -u -p -r1.53 Makefile
> > --- Makefile20 Sep 2023 15:58:34 -  1.53
> > +++ Makefile27 Feb 2024 16:00:57 -
> > @@ -1,7 +1,7 @@
> >  COMMENT =  DeaDBeeF is an audio player
> >  DISTNAME = deadbeef-1.9.4
> >  CATEGORIES =   audio
> > -REVISION = 0
> > +REVISION = 1
> >  
> >  HOMEPAGE = https://deadbeef.sourceforge.io/
> >  
> > Index: patches/patch-plugins_ffap_x86inc_asm
> > ===
> > RCS file: patches/patch-plugins_ffap_x86inc_asm
> > diff -N patches/patch-plugins_ffap_x86inc_asm
> > --- /dev/null   1 Jan 1970 00:00:00 -
> > +++ patches/patch-plugins_ffap_x86inc_asm   27 Feb 2024 16:00:57 -
> > @@ -0,0 +1,28 @@
> > +Index: plugins/ffap/x86inc.asm
> > +--- plugins/ffap/x86inc.asm.orig
> >  plugins/ffap/x86inc.asm
> > +@@ -28,6 +28,16 @@
> > + %endif
> > + %endif
> > + 
> > ++%ifdef ARCH_X86_64
> > ++%imacro _endbr64 0
> > ++dd 0xfa1e0ff3
> > ++%endmacro
> > ++%else
> > ++%imacro _endbr64 0
> > ++; empty
> > ++%endmacro
> > ++%endif
> > ++
> > + ; FIXME: All of the 64bit asm functions that take a stride as an argument
> > + ; via register, assume that the high dword of that register is filled 
> > with 0.
> > + ; This is true in practice (since we never do any 64bit arithmetic on 
> > strides,
> > +@@ -446,6 +456,7 @@ DECLARE_REG 6, ebp, ebp, bp, null, [esp + stack_offset
> > + %endif
> > + align function_align
> > + %1:
> > ++_endbr64
> > + RESET_MM_PERMUTATION ; not really needed, but makes disassembly 
> > somewhat nicer
> > + %assign stack_offset 0
> > + %if %0 > 1
> > 
> 



Re: missing endbr64

2024-02-27 Thread Stuart Henderson
On 2024/02/27 16:03, Stuart Henderson wrote:
> On 2024/02/27 12:08, Theo Buehler wrote:
> > Now that the bulk has completed here's the remainder of the list with
> > two more that may need fixing. 119 ports total contained a warning.
> > I did not build the chromium variants.
> > 
> > audio/deadbeef.log
> > ld: warning: ff_scalarproduct_and_madd_int16_sse2: missing endbr64
> 
> This is when building the plugin for playback of monkey's audio (ape)
> files (plugins/ffap) which has its own copy of (a very old version of)
> some asm from ffmpeg, see plugins/ffap/x86inc.asm and dsputil_yasm.asm.
> 
> This seems to do the trick on amd64, there might be a better way but
> I was struggling with yasm vs nasm syntax. I'm testing to make sure it
> doesn't break i386 now.

Still builds on i386.

> This Index: Makefile
> ===
> RCS file: /cvs/ports/audio/deadbeef/Makefile,v
> retrieving revision 1.53
> diff -u -p -r1.53 Makefile
> --- Makefile  20 Sep 2023 15:58:34 -  1.53
> +++ Makefile  27 Feb 2024 16:00:57 -
> @@ -1,7 +1,7 @@
>  COMMENT =DeaDBeeF is an audio player
>  DISTNAME =   deadbeef-1.9.4
>  CATEGORIES = audio
> -REVISION =   0
> +REVISION =   1
>  
>  HOMEPAGE =   https://deadbeef.sourceforge.io/
>  
> Index: patches/patch-plugins_ffap_x86inc_asm
> ===
> RCS file: patches/patch-plugins_ffap_x86inc_asm
> diff -N patches/patch-plugins_ffap_x86inc_asm
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-plugins_ffap_x86inc_asm 27 Feb 2024 16:00:57 -
> @@ -0,0 +1,28 @@
> +Index: plugins/ffap/x86inc.asm
> +--- plugins/ffap/x86inc.asm.orig
>  plugins/ffap/x86inc.asm
> +@@ -28,6 +28,16 @@
> + %endif
> + %endif
> + 
> ++%ifdef ARCH_X86_64
> ++%imacro _endbr64 0
> ++dd 0xfa1e0ff3
> ++%endmacro
> ++%else
> ++%imacro _endbr64 0
> ++; empty
> ++%endmacro
> ++%endif
> ++
> + ; FIXME: All of the 64bit asm functions that take a stride as an argument
> + ; via register, assume that the high dword of that register is filled with 
> 0.
> + ; This is true in practice (since we never do any 64bit arithmetic on 
> strides,
> +@@ -446,6 +456,7 @@ DECLARE_REG 6, ebp, ebp, bp, null, [esp + stack_offset
> + %endif
> + align function_align
> + %1:
> ++_endbr64
> + RESET_MM_PERMUTATION ; not really needed, but makes disassembly 
> somewhat nicer
> + %assign stack_offset 0
> + %if %0 > 1
> 



Re: missing endbr64

2024-02-27 Thread Stuart Henderson
On 2024/02/27 12:08, Theo Buehler wrote:
> Now that the bulk has completed here's the remainder of the list with
> two more that may need fixing. 119 ports total contained a warning.
> I did not build the chromium variants.
> 
> audio/deadbeef.log
> ld: warning: ff_scalarproduct_and_madd_int16_sse2: missing endbr64

This is when building the plugin for playback of monkey's audio (ape)
files (plugins/ffap) which has its own copy of (a very old version of)
some asm from ffmpeg, see plugins/ffap/x86inc.asm and dsputil_yasm.asm.

This seems to do the trick on amd64, there might be a better way but
I was struggling with yasm vs nasm syntax. I'm testing to make sure it
doesn't break i386 now.

This Index: Makefile
===
RCS file: /cvs/ports/audio/deadbeef/Makefile,v
retrieving revision 1.53
diff -u -p -r1.53 Makefile
--- Makefile20 Sep 2023 15:58:34 -  1.53
+++ Makefile27 Feb 2024 16:00:57 -
@@ -1,7 +1,7 @@
 COMMENT =  DeaDBeeF is an audio player
 DISTNAME = deadbeef-1.9.4
 CATEGORIES =   audio
-REVISION = 0
+REVISION = 1
 
 HOMEPAGE = https://deadbeef.sourceforge.io/
 
Index: patches/patch-plugins_ffap_x86inc_asm
===
RCS file: patches/patch-plugins_ffap_x86inc_asm
diff -N patches/patch-plugins_ffap_x86inc_asm
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-plugins_ffap_x86inc_asm   27 Feb 2024 16:00:57 -
@@ -0,0 +1,28 @@
+Index: plugins/ffap/x86inc.asm
+--- plugins/ffap/x86inc.asm.orig
 plugins/ffap/x86inc.asm
+@@ -28,6 +28,16 @@
+ %endif
+ %endif
+ 
++%ifdef ARCH_X86_64
++%imacro _endbr64 0
++dd 0xfa1e0ff3
++%endmacro
++%else
++%imacro _endbr64 0
++; empty
++%endmacro
++%endif
++
+ ; FIXME: All of the 64bit asm functions that take a stride as an argument
+ ; via register, assume that the high dword of that register is filled with 0.
+ ; This is true in practice (since we never do any 64bit arithmetic on strides,
+@@ -446,6 +456,7 @@ DECLARE_REG 6, ebp, ebp, bp, null, [esp + stack_offset
+ %endif
+ align function_align
+ %1:
++_endbr64
+ RESET_MM_PERMUTATION ; not really needed, but makes disassembly somewhat 
nicer
+ %assign stack_offset 0
+ %if %0 > 1



Re: missing endbr64

2024-02-27 Thread Mark Kettenis
> Date: Tue, 27 Feb 2024 12:08:22 +0100
> From: Theo Buehler 
> 
> Now that the bulk has completed here's the remainder of the list with
> two more that may need fixing. 119 ports total contained a warning.
> I did not build the chromium variants.

Only two more?  I guess all the libs (where this matters) get build
early...

> audio/deadbeef.log
> ld: warning: ff_scalarproduct_and_madd_int16_sse2: missing endbr64

Another x86inc.asm case I think.

> x11/afterstep.log
> ld: warning: unw_getcontext: missing endbr64

That seems to be a problem with base.  Sent a diff for that to those
that matter.



Re: missing endbr64

2024-02-27 Thread Theo Buehler
Now that the bulk has completed here's the remainder of the list with
two more that may need fixing. 119 ports total contained a warning.
I did not build the chromium variants.

audio/deadbeef.log
ld: warning: ff_scalarproduct_and_madd_int16_sse2: missing endbr64

x11/afterstep.log
ld: warning: unw_getcontext: missing endbr64

===

Go (with NOBTCFI)

audio/ymuse.log
mail/aerc,notmuch.log
net/mautrix-whatsapp.log

Haskell (with NOBTCFI)

devel/happy.log

Kikad (with NOBTCFI warnings from embedded libcontext?)

cad/kicad.log 
ld.lld: warning: jump_fcontext: missing endbr64
ld.lld: warning: make_fcontext: missing endbr64

Luajit (with NOBTCFI)

editors/neovim.log
games/tome4,-data.log

Mono (with NOBTCFI)

lang/mono.log

Mozilla (with NOBTCFI)

mail/mozilla-thunderbird.log
www/firefox-esr.log
www/mozilla-firefox.log
www/seamonkey,,-main.log
www/tor-browser/browser.log

Ocaml (with NOBTCFI)

devel/coccinelle.log
devel/frama-c.log
devel/ocaml-graph.log
graphics/ocaml-cairo.log
lang/compcert.log
math/coq.log
x11/lablgtk3.log
net/unison,-gui.log
textproc/bibtex2html.log

Qt (with NOBTCFI)

x11/qt5/qtwebengine.log
x11/qt6/qtwebengine.log

sbcl (with NOBTCFI)

lang/sbcl.log



Re: missing endbr64

2024-02-25 Thread Sebastian Reitenbach
On Sunday, February 25, 2024 16:44 CET, Mark Kettenis  
wrote:

> > x11/gnustep/libobjc2.log
> > ld: warning: __objc_block_trampoline_sret: missing endbr64
> > ld: warning: __objc_block_trampoline: missing endbr64
> > ld: warning: objc_msgSend: missing endbr64
> > ld: warning: objc_msgSend_fpret: missing endbr64
> > ld: warning: objc_msgSend_stret: missing endbr64
> 
> I guess this is very similay to devel/objfw.  Just add endbr64 to
> those functions like we did there.  No aarch64 support here by the
> looks of it.

Above version of libobjc2 is old, but due to build errors, and runtime errors, 
I was 
unable to upgrade. However, a new version was released just a few days ago, and 
that one even builds
and doesn't show runtime errors so far.
I updated one test box, to get these new ld warnings, there are only these left 
on amd64:

ld: warning: objc_msgSend: missing endbr64
ld: warning: objc_msgSend_fpret: missing endbr64
ld: warning: objc_msgSend_stret: missing endbr64

Which are all the platforms, that need such fix? I see objc_msgSend_fpret for 
aarch64, arm, 
amd64, i386, mips and riscv64.

Attached patch to update to the new 2.2 release, without any fixes for the 
missing endbr64.

Sebastian


libobjc2-2.2.diff
Description: Binary data


Re: Add missing endbr64 to gstreamer1-plugins-good

2024-02-25 Thread Mark Kettenis
> Date: Sun, 25 Feb 2024 19:49:52 +0100
> From: Theo Buehler 
> 
> This fixes
> 
> ld: warning: gst_yadif_filter_line_mode0_ssse3: missing endbr64
> ld: warning: gst_yadif_filter_line_mode2_ssse3: missing endbr64
> ld: warning: gst_yadif_filter_line_mode0_sse2: missing endbr64
> ld: warning: gst_yadif_filter_line_mode2_sse2: missing endbr64
> 
> These are generated by the two cglobal in gst/deinterlace/x86/yadif.asm
> and assigned to function pointers in gst/deinterlace/yadif.c.
> 
> There are no uses of the cvisible macro (public visibility), but if
> there were, they would also need endbr64, hence I placed the endbr64
> there without conditioning on %1.

Ah another x86inc.asm user.  ok kettenis@


> Index: Makefile
> ===
> RCS file: /cvs/ports/multimedia/gstreamer1/plugins-good/Makefile,v
> diff -u -p -r1.79 Makefile
> --- Makefile  27 Sep 2023 10:10:20 -  1.79
> +++ Makefile  25 Feb 2024 18:45:03 -
> @@ -7,6 +7,7 @@ COMMENT-pulse=pulseaudio(1) element fo
>  
>  DISTNAME=gst-plugins-good-${V}
>  PKGNAME= ${GST_PKGNAME_PREFIX}-plugins-good-${V}
> +REVISION=0
>  
>  PKGNAME-main=${PKGNAME}
>  PKGNAME-pulse=   ${GST_PKGNAME_PREFIX}-plugins-pulse-${V}
> Index: patches/patch-gst_deinterlace_x86_x86inc_asm
> ===
> RCS file: patches/patch-gst_deinterlace_x86_x86inc_asm
> diff -N patches/patch-gst_deinterlace_x86_x86inc_asm
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-gst_deinterlace_x86_x86inc_asm  25 Feb 2024 18:42:45 
> -
> @@ -0,0 +1,13 @@
> +Index: gst/deinterlace/x86/x86inc.asm
> +--- gst/deinterlace/x86/x86inc.asm.orig
>  gst/deinterlace/x86/x86inc.asm
> +@@ -732,6 +732,9 @@ BRANCH_INSTR jz, je, jnz, jne, jl, jle, jnl, jnle, jg,
> + %endif
> + align function_align
> + %2:
> ++%if ARCH_X86_64
> ++endbr64
> ++%endif
> + RESET_MM_PERMUTATION; needed for x86-64, also makes disassembly 
> somewhat nicer
> + %xdefine rstk rsp   ; copy of the original stack pointer, used 
> when greater alignment than the known stack alignment is required
> + %assign stack_offset 0  ; stack pointer offset relative to the 
> return address
> 



Re: missing endbr64

2024-02-25 Thread Mark Kettenis
> Date: Sun, 25 Feb 2024 18:43:54 +
> From: Stuart Henderson 
> 
> > > sysutils/borgbackup/2.0.log: lots of warnings about symbols from 
> > > openssl/3.1:
> > > ld: warning: aesni_set_decrypt_key: missing endbr64
> > > ld: warning: aesni_set_encrypt_key: missing endbr64
> > > ld: warning: ChaCha20_ctr32: missing endbr64
> > > ld: warning: bn_mul_mont: missing endbr64
> > > ld: warning: bn_mul_mont_gather5: missing endbr64
> > > ld: warning: bn_power5: missing endbr64
> > > ld: warning: bn_get_bits5: missing endbr64
> > > ld: warning: bn_scatter5: missing endbr64
> > > ld: warning: bn_gather5: missing endbr64
> > > ld: warning: rsaz_1024_sqr_avx2: missing endbr64
> > > ld: warning: rsaz_1024_mul_avx2: missing endbr64
> > > etc
> > 
> > WTF, so this links against the static version of the lib in order to
> > be able to call non-public functions?  USE_NOBTCFI and laugh at them?
> 
> Links against the static version to try and avoid symbol conflicts
> with libressl libs (which python is linked against).

Ah, Python.  So it is building a Python module with the crypto in it
and because you're linking in it is re-exporting the internal openssl
symbols.  But Python uses NOBTCFI so this is not an immediate problem.



Re: Add missing endbr64 to gstreamer1-plugins-good

2024-02-25 Thread Stuart Henderson
On 2024/02/25 19:49, Theo Buehler wrote:
> This fixes
> 
> ld: warning: gst_yadif_filter_line_mode0_ssse3: missing endbr64
> ld: warning: gst_yadif_filter_line_mode2_ssse3: missing endbr64
> ld: warning: gst_yadif_filter_line_mode0_sse2: missing endbr64
> ld: warning: gst_yadif_filter_line_mode2_sse2: missing endbr64
> 
> These are generated by the two cglobal in gst/deinterlace/x86/yadif.asm
> and assigned to function pointers in gst/deinterlace/yadif.c.
> 
> There are no uses of the cvisible macro (public visibility), but if
> there were, they would also need endbr64, hence I placed the endbr64
> there without conditioning on %1.
> 
> Index: Makefile
> ===
> RCS file: /cvs/ports/multimedia/gstreamer1/plugins-good/Makefile,v
> diff -u -p -r1.79 Makefile
> --- Makefile  27 Sep 2023 10:10:20 -  1.79
> +++ Makefile  25 Feb 2024 18:45:03 -
> @@ -7,6 +7,7 @@ COMMENT-pulse=pulseaudio(1) element fo
>  
>  DISTNAME=gst-plugins-good-${V}
>  PKGNAME= ${GST_PKGNAME_PREFIX}-plugins-good-${V}
> +REVISION=0
>  
>  PKGNAME-main=${PKGNAME}
>  PKGNAME-pulse=   ${GST_PKGNAME_PREFIX}-plugins-pulse-${V}
> Index: patches/patch-gst_deinterlace_x86_x86inc_asm
> ===
> RCS file: patches/patch-gst_deinterlace_x86_x86inc_asm
> diff -N patches/patch-gst_deinterlace_x86_x86inc_asm
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-gst_deinterlace_x86_x86inc_asm  25 Feb 2024 18:42:45 
> -
> @@ -0,0 +1,13 @@
> +Index: gst/deinterlace/x86/x86inc.asm
> +--- gst/deinterlace/x86/x86inc.asm.orig
>  gst/deinterlace/x86/x86inc.asm
> +@@ -732,6 +732,9 @@ BRANCH_INSTR jz, je, jnz, jne, jl, jle, jnl, jnle, jg,
> + %endif
> + align function_align
> + %2:
> ++%if ARCH_X86_64
> ++endbr64
> ++%endif
> + RESET_MM_PERMUTATION; needed for x86-64, also makes disassembly 
> somewhat nicer
> + %xdefine rstk rsp   ; copy of the original stack pointer, used 
> when greater alignment than the known stack alignment is required
> + %assign stack_offset 0  ; stack pointer offset relative to the 
> return address
> 

I've changed -Dtests=disabled for enabled and run through them on an IBT
machine. Without this diff, the only failures are timeouts not SIGILL,
so gstreamer plugins-good's test suite doesn't seem to exercise this
(presumably need to run something that does deinterlacing to do that).
Not sure how to test that.

Anyway the diff seems sane. OK with me.



Re: missing endbr64

2024-02-25 Thread Stuart Henderson
On 2024/02/25 13:01, Stuart Henderson wrote:
> On 2024/02/25 12:46, Stuart Henderson wrote:
> > I will look at rspamd and luajit later today.
> 
> > > lang/luajit.log
> > > ld.lld: warning: lj_vm_unwind_c_eh: missing endbr64
> > > ld.lld: warning: lj_vm_unwind_rethrow: missing endbr64
> > > ld.lld: warning: lj_vm_unwind_ff_eh: missing endbr64
> > > ld.lld: warning: lj_cont_cat: missing endbr64
> > > ld.lld: warning: lj_cont_ra: missing endbr64
> > > ld.lld: warning: lj_cont_nop: missing endbr64
> > > ld.lld: warning: lj_cont_condt: missing endbr64
> > > etc
> 
> ah, actually I think I'll need help with luajit, these look like they
> may be encoding luajit bytecode so I'm not sure how to deal with them
> or whether they're actually needed at all.
> 
> The trivial "make test" example which just prints a string works on an
> IBT machine but there are missing endbr64 in various fuctions with an
> sse/x87 name - if there are any lua-knowledgeable people reading that
> can show me something that would be likely to use these that I can run
> to test, that would be handy.
> 
> (No need to worry about arm64 for lang/luajit, it uses the 2.0 branch
> which doesn't support arm64 anyway).
> 

semarie points out that luajit already has USE_NOBTCFI (I missed it because
it was low down in the Makefile - personally I try to put things like
USE_WXNEEDED or USE_NOBTCFI right up top so they're easily visible), so
it uses -z nobtcfi.

Building without USE_NOBTCFI I confirm that luajit does crash on an IBT
machine.

Of the ports using luajit's library, most of them also have USE_NOBTCFI.
Only games/luasteam doesn't. (graphics/gimp/snapshot only uses the luajit
binary so doesn't need USE_NOBTCFI itself for any luajit-related reason).

So games/luasteam needs USE_NOBTCFI and a bump.



Add missing endbr64 to gstreamer1-plugins-good

2024-02-25 Thread Theo Buehler
This fixes

ld: warning: gst_yadif_filter_line_mode0_ssse3: missing endbr64
ld: warning: gst_yadif_filter_line_mode2_ssse3: missing endbr64
ld: warning: gst_yadif_filter_line_mode0_sse2: missing endbr64
ld: warning: gst_yadif_filter_line_mode2_sse2: missing endbr64

These are generated by the two cglobal in gst/deinterlace/x86/yadif.asm
and assigned to function pointers in gst/deinterlace/yadif.c.

There are no uses of the cvisible macro (public visibility), but if
there were, they would also need endbr64, hence I placed the endbr64
there without conditioning on %1.

Index: Makefile
===
RCS file: /cvs/ports/multimedia/gstreamer1/plugins-good/Makefile,v
diff -u -p -r1.79 Makefile
--- Makefile27 Sep 2023 10:10:20 -  1.79
+++ Makefile25 Feb 2024 18:45:03 -
@@ -7,6 +7,7 @@ COMMENT-pulse=  pulseaudio(1) element fo
 
 DISTNAME=  gst-plugins-good-${V}
 PKGNAME=   ${GST_PKGNAME_PREFIX}-plugins-good-${V}
+REVISION=  0
 
 PKGNAME-main=  ${PKGNAME}
 PKGNAME-pulse= ${GST_PKGNAME_PREFIX}-plugins-pulse-${V}
Index: patches/patch-gst_deinterlace_x86_x86inc_asm
===
RCS file: patches/patch-gst_deinterlace_x86_x86inc_asm
diff -N patches/patch-gst_deinterlace_x86_x86inc_asm
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-gst_deinterlace_x86_x86inc_asm25 Feb 2024 18:42:45 
-
@@ -0,0 +1,13 @@
+Index: gst/deinterlace/x86/x86inc.asm
+--- gst/deinterlace/x86/x86inc.asm.orig
 gst/deinterlace/x86/x86inc.asm
+@@ -732,6 +732,9 @@ BRANCH_INSTR jz, je, jnz, jne, jl, jle, jnl, jnle, jg,
+ %endif
+ align function_align
+ %2:
++%if ARCH_X86_64
++endbr64
++%endif
+ RESET_MM_PERMUTATION; needed for x86-64, also makes disassembly 
somewhat nicer
+ %xdefine rstk rsp   ; copy of the original stack pointer, used 
when greater alignment than the known stack alignment is required
+ %assign stack_offset 0  ; stack pointer offset relative to the return 
address



Re: missing endbr64

2024-02-25 Thread Stuart Henderson
> > sysutils/borgbackup/2.0.log: lots of warnings about symbols from 
> > openssl/3.1:
> > ld: warning: aesni_set_decrypt_key: missing endbr64
> > ld: warning: aesni_set_encrypt_key: missing endbr64
> > ld: warning: ChaCha20_ctr32: missing endbr64
> > ld: warning: bn_mul_mont: missing endbr64
> > ld: warning: bn_mul_mont_gather5: missing endbr64
> > ld: warning: bn_power5: missing endbr64
> > ld: warning: bn_get_bits5: missing endbr64
> > ld: warning: bn_scatter5: missing endbr64
> > ld: warning: bn_gather5: missing endbr64
> > ld: warning: rsaz_1024_sqr_avx2: missing endbr64
> > ld: warning: rsaz_1024_mul_avx2: missing endbr64
> > etc
> 
> WTF, so this links against the static version of the lib in order to
> be able to call non-public functions?  USE_NOBTCFI and laugh at them?

Links against the static version to try and avoid symbol conflicts
with libressl libs (which python is linked against).



Re: missing endbr64

2024-02-25 Thread Mark Kettenis
> From: Theo Buehler 
> Date: Sun, 25 Feb 2024 09:39:39 +
> 
> Here's the list of ~90 ports emitting warnings after about 1/4 of an
> amd64 bulk. First the ports that I haven't looked at more closely with
> (some of) the warnings. Then some ports using D where I suspect NOBTCFI
> is missing. Go, Haskell and Ocaml ports are linked using nobtcfi, as far
> as I know, so I moved them to the end without details.
> 
> devel/ffcall.log
> ld: warning: __vacall_r: missing endbr64

This one is deliberately not addressed; see my commit to that port.

> devel/valgrind.log
> ld: warning: __start: missing endbr64

Not a problem on OpenBSD.  This is the entry point of a static
executable and our kernel doesn't use an indirect jump to get to the
entry point.

> lang/gcc/11,-ada.log
> lang/gcc/8.log:
> ld.lld: warning: pow2_or_zerop(unsigned long long): missing endbr64
> ld.lld: warning: pow2p_hwi(unsigned long long): missing endbr64
> ld.lld: warning: types_compatible_p(tree_node*, tree_node*): missing endbr64
> ld.lld: warning: vn_hash_type(tree_node*): missing endbr64
> ld.lld: warning: vn_hash_constant_with_type(tree_node*): missing endbr64
> ld.lld: warning: vn_constant_eq_with_type(tree_node*, tree_node*): missing 
> endbr64
> ld.lld: warning: vn_constant_eq_with_type(tree_node*, tree_node*): missing 
> endbr64
> ld.lld: warning: iterative_hash_expr(tree_node const*, unsigned int): missing 
> endbr64
> and tons more

I don't think these are from assembly code.  Investigating.

> lang/gprolog.log
> ld.lld: warning: predicate(pl2wam1/1): missing endbr64
> ld.lld: warning: predicate(pl2wam1/1): missing endbr64
> ld.lld: warning: predicate(compile_msg_start/2): missing endbr64
> ld.lld: warning: predicate(cmd_line_args/3): missing endbr64
> ld.lld: warning: predicate(cmd_line_arg1/3): missing endbr64
> ld.lld: warning: predicate(cmd_line_arg1/3): missing endbr64
> ld.lld: warning: predicate(cmd_line_arg1/3): missing endbr64
> ld.lld: warning: predicate(cmd_line_arg1/3): missing endbr64
> ld.lld: warning: predicate(cmd_line_arg1/3): missing endbr64
> ld.lld: warning: directive_1: missing endbr64
> ld.lld: warning: Prolog_Object_Initializer: missing endbr64
> ld.lld: warning: System_Directives: missing endbr64
> ld.lld: warning: User_Directives: missing endbr64

Is this a compiler?  Either needs to be modified to emit endbr64 then
or some NOBTCFI.

> lang/hare/hare.log
> ld: warning: preinit_hare: missing endbr64
> ld: warning: encoding.utf8.prev: missing endbr64
> ld: warning: encoding.utf8.next: missing endbr64
> ld: warning: sort.cmp.strs: missing endbr64
> ld: warning: endian.leputu64: missing endbr64
> ld: warning: endian.legetu64: missing endbr64
> ld: warning: endian.leputu32: missing endbr64
> ld: warning: endian.legetu32: missing endbr64
> ld: warning: endian.leputu16: missing endbr64
> ld: warning: endian.legetu16: missing endbr64
> ld: warning: endian.beputu64: missing endbr64
> ld: warning: endian.begetu64: missing endbr64
> ld: warning: endian.beputu32: missing endbr64
> ld: warning: endian.begetu32: missing endbr64
> ld: warning: endian.beputu16: missing endbr64
> ld: warning: endian.begetu16: missing endbr64
> ld: warning: hare.unparse.syn_nowrap: missing endbr64

Same story.

> lang/luajit.log
> ld.lld: warning: lj_vm_unwind_c_eh: missing endbr64
> ld.lld: warning: lj_vm_unwind_rethrow: missing endbr64
> ld.lld: warning: lj_vm_unwind_ff_eh: missing endbr64
> ld.lld: warning: lj_cont_cat: missing endbr64
> ld.lld: warning: lj_cont_ra: missing endbr64
> ld.lld: warning: lj_cont_nop: missing endbr64
> ld.lld: warning: lj_cont_condt: missing endbr64
> etc

Looks like the assembly code is generated from some lua code.  Needs
someone who actually understands lua.

> mail/rspamd.log
> ld.lld: warning: chacha_blocks_avx2: missing endbr64
> ld.lld: warning: _chacha_blocks_avx2: missing endbr64
> ld.lld: warning: hchacha_avx2: missing endbr64
> ld.lld: warning: _hchacha_avx2: missing endbr64
> ld.lld: warning: chacha_avx2: missing endbr64
> ld.lld: warning: _chacha_avx2: missing endbr64
> ld.lld: warning: xchacha_avx2: missing endbr64
> ld.lld: warning: _xchacha_avx2: missing endbr64
> ld.lld: warning: chacha_blocks_avx: missing endbr64
> ld.lld: warning: _chacha_blocks_avx: missing endbr64
> ld.lld: warning: hchacha_avx: missing endbr64
> ld.lld: warning: _hchacha_avx: missing endbr64
> ld.lld: warning: chacha_avx: missing endbr64
> ld.lld: warning: _chacha_avx: missing endbr64
> ld.lld: warning: xchacha_avx: missing endbr64
> ld.lld: warning: _xchacha_avx: missing endbr64
> ld.lld: warning: chacha_blocks_sse2: missing endbr64
> ld.lld: warning: _chacha_blocks_sse2: missing endbr64
> ld.lld: warning: hchacha_sse2: missing endbr64
> ld.lld: 

Re: missing endbr64

2024-02-25 Thread Brian Callahan
On 2/25/2024 4:39 AM, Theo Buehler wrote
> D
> Missing NOBTCFI for some of these?
> 
> devel/dtools.log
> devel/dub,dmd.log
> lang/dmd.log
> lang/ldc.log
> sysutils/trash-d.log
> 

Yes, the D ports should have NOBTCFI. I am working on this, but it is
not yet ready for prime time.

Thanks.

~Brian



Re: missing endbr64

2024-02-25 Thread Theo Buehler
On Sun, Feb 25, 2024 at 01:35:54PM +0100, Mark Kettenis wrote:
> > From: Theo Buehler 
> > Date: Sun, 25 Feb 2024 09:39:39 +
> > 
> > Here's the list of ~90 ports emitting warnings after about 1/4 of an
> > amd64 bulk. First the ports that I haven't looked at more closely with
> > (some of) the warnings. Then some ports using D where I suspect NOBTCFI
> > is missing. Go, Haskell and Ocaml ports are linked using nobtcfi, as far
> > as I know, so I moved them to the end without details.
> 
> ...
> 
> > multimedia/x264.log
> > ld: warning: x264_8_sub8x8_dct_sse2.skip_prologue: missing endbr64
> > ld: warning: x264_8_sub8x8_dct8_sse2.skip_prologue: missing endbr64
> > ld: warning: x264_8_sub8x8_dct_ssse3.skip_prologue: missing endbr64
> > ld: warning: x264_8_sub8x8_dct8_ssse3.skip_prologue: missing endbr64
> > ld: warning: x264_8_sub8x8_dct_avx.skip_prologue: missing endbr64
> > ld: warning: x264_8_sub8x8_dct8_avx.skip_prologue: missing endbr64
> > ld: warning: x264_8_sub8x8_dct_xop.skip_prologue: missing endbr64
> > ld: warning: x264_8_add8x8_idct8_sse2.skip_prologue: missing endbr64
> > ld: warning: x264_8_add8x8_idct8_avx.skip_prologue: missing endbr64
> > ld: warning: x264_8_add8x8_idct_sse2.skip_prologue: missing endbr64
> > ld: warning: x264_8_add8x8_idct_avx.skip_prologue: missing endbr64
> > ld: warning: x264_10_sub8x8_dct8_sse2.skip_prologue: missing endbr64
> > ld: warning: x264_10_sub8x8_dct8_sse4.skip_prologue: missing endbr64
> > ld: warning: x264_10_sub8x8_dct8_avx.skip_prologue: missing endbr64
> > ld: warning: x264_10_add8x8_idct8_sse2.skip_prologue: missing endbr64
> > ld: warning: x264_10_add8x8_idct8_avx.skip_prologue: missing endbr64
> 
> Here is a fix:

ok tb

> 
> Index: multimedia/x264/Makefile
> ===
> RCS file: /cvs/ports/multimedia/x264/Makefile,v
> retrieving revision 1.69
> diff -u -p -r1.69 Makefile
> --- multimedia/x264/Makefile  20 Feb 2024 10:06:12 -  1.69
> +++ multimedia/x264/Makefile  25 Feb 2024 12:32:10 -
> @@ -4,7 +4,7 @@ DISTNAME= x264-20221028
>  GH_ACCOUNT=  mirror
>  GH_PROJECT=  x264
>  GH_COMMIT=   416e3eb2b52abb0a67e57599aba4f8be3003b36d
> -REVISION=2
> +REVISION=3
>  CATEGORIES=  multimedia
>  
>  SHARED_LIBS= x26424.0
> Index: multimedia/x264/patches/patch-common_x86_x86inc_asm
> ===
> RCS file: /cvs/ports/multimedia/x264/patches/patch-common_x86_x86inc_asm,v
> retrieving revision 1.1
> diff -u -p -r1.1 patch-common_x86_x86inc_asm
> --- multimedia/x264/patches/patch-common_x86_x86inc_asm   20 Feb 2024 
> 10:06:12 -  1.1
> +++ multimedia/x264/patches/patch-common_x86_x86inc_asm   25 Feb 2024 
> 12:32:10 -
> @@ -11,3 +11,13 @@ Index: common/x86/x86inc.asm
>   RESET_MM_PERMUTATION; needed for x86-64, also makes disassembly 
> somewhat nicer
>   %xdefine rstk rsp   ; copy of the original stack pointer, used 
> when greater alignment than the known stack alignment is required
>   %assign stack_offset 0  ; stack pointer offset relative to the 
> return address
> +@@ -823,6 +826,9 @@ BRANCH_INSTR jz, je, jnz, jne, jl, jle, jnl, jnle, jg,
> + global current_function %+ %1
> + %endif
> + %1:
> ++%if ARCH_X86_64
> ++endbr64
> ++%endif
> + %endmacro
> + 
> + %macro cextern 1



Re: missing endbr64

2024-02-25 Thread Stuart Henderson
On 2024/02/25 12:46, Stuart Henderson wrote:
> I will look at rspamd and luajit later today.

> > lang/luajit.log
> > ld.lld: warning: lj_vm_unwind_c_eh: missing endbr64
> > ld.lld: warning: lj_vm_unwind_rethrow: missing endbr64
> > ld.lld: warning: lj_vm_unwind_ff_eh: missing endbr64
> > ld.lld: warning: lj_cont_cat: missing endbr64
> > ld.lld: warning: lj_cont_ra: missing endbr64
> > ld.lld: warning: lj_cont_nop: missing endbr64
> > ld.lld: warning: lj_cont_condt: missing endbr64
> > etc

ah, actually I think I'll need help with luajit, these look like they
may be encoding luajit bytecode so I'm not sure how to deal with them
or whether they're actually needed at all.

The trivial "make test" example which just prints a string works on an
IBT machine but there are missing endbr64 in various fuctions with an
sse/x87 name - if there are any lua-knowledgeable people reading that
can show me something that would be likely to use these that I can run
to test, that would be handy.

(No need to worry about arm64 for lang/luajit, it uses the 2.0 branch
which doesn't support arm64 anyway).



Re: missing endbr64

2024-02-25 Thread Stuart Henderson
I will look at rspamd and luajit later today.

On 2024/02/25 10:39, Theo Buehler wrote:
> Here's the list of ~90 ports emitting warnings after about 1/4 of an
> amd64 bulk. First the ports that I haven't looked at more closely with
> (some of) the warnings. Then some ports using D where I suspect NOBTCFI
> is missing. Go, Haskell and Ocaml ports are linked using nobtcfi, as far
> as I know, so I moved them to the end without details.
> 
> devel/ffcall.log
> ld: warning: __vacall_r: missing endbr64
> 
> devel/valgrind.log
> ld: warning: __start: missing endbr64
> 
> lang/gcc/11,-ada.log
> lang/gcc/8.log:
> ld.lld: warning: pow2_or_zerop(unsigned long long): missing endbr64
> ld.lld: warning: pow2p_hwi(unsigned long long): missing endbr64
> ld.lld: warning: types_compatible_p(tree_node*, tree_node*): missing endbr64
> ld.lld: warning: vn_hash_type(tree_node*): missing endbr64
> ld.lld: warning: vn_hash_constant_with_type(tree_node*): missing endbr64
> ld.lld: warning: vn_constant_eq_with_type(tree_node*, tree_node*): missing 
> endbr64
> ld.lld: warning: vn_constant_eq_with_type(tree_node*, tree_node*): missing 
> endbr64
> ld.lld: warning: iterative_hash_expr(tree_node const*, unsigned int): missing 
> endbr64
> and tons more
> 
> lang/gprolog.log
> ld.lld: warning: predicate(pl2wam1/1): missing endbr64
> ld.lld: warning: predicate(pl2wam1/1): missing endbr64
> ld.lld: warning: predicate(compile_msg_start/2): missing endbr64
> ld.lld: warning: predicate(cmd_line_args/3): missing endbr64
> ld.lld: warning: predicate(cmd_line_arg1/3): missing endbr64
> ld.lld: warning: predicate(cmd_line_arg1/3): missing endbr64
> ld.lld: warning: predicate(cmd_line_arg1/3): missing endbr64
> ld.lld: warning: predicate(cmd_line_arg1/3): missing endbr64
> ld.lld: warning: predicate(cmd_line_arg1/3): missing endbr64
> ld.lld: warning: directive_1: missing endbr64
> ld.lld: warning: Prolog_Object_Initializer: missing endbr64
> ld.lld: warning: System_Directives: missing endbr64
> ld.lld: warning: User_Directives: missing endbr64
> 
> lang/hare/hare.log
> ld: warning: preinit_hare: missing endbr64
> ld: warning: encoding.utf8.prev: missing endbr64
> ld: warning: encoding.utf8.next: missing endbr64
> ld: warning: sort.cmp.strs: missing endbr64
> ld: warning: endian.leputu64: missing endbr64
> ld: warning: endian.legetu64: missing endbr64
> ld: warning: endian.leputu32: missing endbr64
> ld: warning: endian.legetu32: missing endbr64
> ld: warning: endian.leputu16: missing endbr64
> ld: warning: endian.legetu16: missing endbr64
> ld: warning: endian.beputu64: missing endbr64
> ld: warning: endian.begetu64: missing endbr64
> ld: warning: endian.beputu32: missing endbr64
> ld: warning: endian.begetu32: missing endbr64
> ld: warning: endian.beputu16: missing endbr64
> ld: warning: endian.begetu16: missing endbr64
> ld: warning: hare.unparse.syn_nowrap: missing endbr64
> 
> lang/luajit.log
> ld.lld: warning: lj_vm_unwind_c_eh: missing endbr64
> ld.lld: warning: lj_vm_unwind_rethrow: missing endbr64
> ld.lld: warning: lj_vm_unwind_ff_eh: missing endbr64
> ld.lld: warning: lj_cont_cat: missing endbr64
> ld.lld: warning: lj_cont_ra: missing endbr64
> ld.lld: warning: lj_cont_nop: missing endbr64
> ld.lld: warning: lj_cont_condt: missing endbr64
> etc
> 
> mail/rspamd.log
> ld.lld: warning: chacha_blocks_avx2: missing endbr64
> ld.lld: warning: _chacha_blocks_avx2: missing endbr64
> ld.lld: warning: hchacha_avx2: missing endbr64
> ld.lld: warning: _hchacha_avx2: missing endbr64
> ld.lld: warning: chacha_avx2: missing endbr64
> ld.lld: warning: _chacha_avx2: missing endbr64
> ld.lld: warning: xchacha_avx2: missing endbr64
> ld.lld: warning: _xchacha_avx2: missing endbr64
> ld.lld: warning: chacha_blocks_avx: missing endbr64
> ld.lld: warning: _chacha_blocks_avx: missing endbr64
> ld.lld: warning: hchacha_avx: missing endbr64
> ld.lld: warning: _hchacha_avx: missing endbr64
> ld.lld: warning: chacha_avx: missing endbr64
> ld.lld: warning: _chacha_avx: missing endbr64
> ld.lld: warning: xchacha_avx: missing endbr64
> ld.lld: warning: _xchacha_avx: missing endbr64
> ld.lld: warning: chacha_blocks_sse2: missing endbr64
> ld.lld: warning: _chacha_blocks_sse2: missing endbr64
> ld.lld: warning: hchacha_sse2: missing endbr64
> ld.lld: warning: _hchacha_sse2: missing endbr64
> ld.lld: warning: chacha_sse2: missing endbr64
> ld.lld: warning: _chacha_sse2: missing endbr64
> ld.lld: warning: xchacha_sse2: missing endbr64
> ld.lld: warning: _xchacha_sse2: missing endbr64
> 
> math/ecm.log
> ld: warning: mulredc1: missing endbr64
> ld: warning: mulredc2: missing endbr64
> ld: warning: mulredc3: missing endbr64
> ld: warning: m

Re: missing endbr64

2024-02-25 Thread Mark Kettenis
> From: Theo Buehler 
> Date: Sun, 25 Feb 2024 09:39:39 +
> 
> Here's the list of ~90 ports emitting warnings after about 1/4 of an
> amd64 bulk. First the ports that I haven't looked at more closely with
> (some of) the warnings. Then some ports using D where I suspect NOBTCFI
> is missing. Go, Haskell and Ocaml ports are linked using nobtcfi, as far
> as I know, so I moved them to the end without details.

...

> multimedia/x264.log
> ld: warning: x264_8_sub8x8_dct_sse2.skip_prologue: missing endbr64
> ld: warning: x264_8_sub8x8_dct8_sse2.skip_prologue: missing endbr64
> ld: warning: x264_8_sub8x8_dct_ssse3.skip_prologue: missing endbr64
> ld: warning: x264_8_sub8x8_dct8_ssse3.skip_prologue: missing endbr64
> ld: warning: x264_8_sub8x8_dct_avx.skip_prologue: missing endbr64
> ld: warning: x264_8_sub8x8_dct8_avx.skip_prologue: missing endbr64
> ld: warning: x264_8_sub8x8_dct_xop.skip_prologue: missing endbr64
> ld: warning: x264_8_add8x8_idct8_sse2.skip_prologue: missing endbr64
> ld: warning: x264_8_add8x8_idct8_avx.skip_prologue: missing endbr64
> ld: warning: x264_8_add8x8_idct_sse2.skip_prologue: missing endbr64
> ld: warning: x264_8_add8x8_idct_avx.skip_prologue: missing endbr64
> ld: warning: x264_10_sub8x8_dct8_sse2.skip_prologue: missing endbr64
> ld: warning: x264_10_sub8x8_dct8_sse4.skip_prologue: missing endbr64
> ld: warning: x264_10_sub8x8_dct8_avx.skip_prologue: missing endbr64
> ld: warning: x264_10_add8x8_idct8_sse2.skip_prologue: missing endbr64
> ld: warning: x264_10_add8x8_idct8_avx.skip_prologue: missing endbr64

Here is a fix:

Index: multimedia/x264/Makefile
===
RCS file: /cvs/ports/multimedia/x264/Makefile,v
retrieving revision 1.69
diff -u -p -r1.69 Makefile
--- multimedia/x264/Makefile20 Feb 2024 10:06:12 -  1.69
+++ multimedia/x264/Makefile25 Feb 2024 12:32:10 -
@@ -4,7 +4,7 @@ DISTNAME=   x264-20221028
 GH_ACCOUNT=mirror
 GH_PROJECT=x264
 GH_COMMIT= 416e3eb2b52abb0a67e57599aba4f8be3003b36d
-REVISION=  2
+REVISION=  3
 CATEGORIES=multimedia
 
 SHARED_LIBS=   x26424.0
Index: multimedia/x264/patches/patch-common_x86_x86inc_asm
===
RCS file: /cvs/ports/multimedia/x264/patches/patch-common_x86_x86inc_asm,v
retrieving revision 1.1
diff -u -p -r1.1 patch-common_x86_x86inc_asm
--- multimedia/x264/patches/patch-common_x86_x86inc_asm 20 Feb 2024 10:06:12 
-  1.1
+++ multimedia/x264/patches/patch-common_x86_x86inc_asm 25 Feb 2024 12:32:10 
-
@@ -11,3 +11,13 @@ Index: common/x86/x86inc.asm
  RESET_MM_PERMUTATION; needed for x86-64, also makes disassembly 
somewhat nicer
  %xdefine rstk rsp   ; copy of the original stack pointer, used 
when greater alignment than the known stack alignment is required
  %assign stack_offset 0  ; stack pointer offset relative to the return 
address
+@@ -823,6 +826,9 @@ BRANCH_INSTR jz, je, jnz, jne, jl, jle, jnl, jnle, jg,
+ global current_function %+ %1
+ %endif
+ %1:
++%if ARCH_X86_64
++endbr64
++%endif
+ %endmacro
+ 
+ %macro cextern 1



missing endbr64

2024-02-25 Thread Theo Buehler
Here's the list of ~90 ports emitting warnings after about 1/4 of an
amd64 bulk. First the ports that I haven't looked at more closely with
(some of) the warnings. Then some ports using D where I suspect NOBTCFI
is missing. Go, Haskell and Ocaml ports are linked using nobtcfi, as far
as I know, so I moved them to the end without details.

devel/ffcall.log
ld: warning: __vacall_r: missing endbr64

devel/valgrind.log
ld: warning: __start: missing endbr64

lang/gcc/11,-ada.log
lang/gcc/8.log:
ld.lld: warning: pow2_or_zerop(unsigned long long): missing endbr64
ld.lld: warning: pow2p_hwi(unsigned long long): missing endbr64
ld.lld: warning: types_compatible_p(tree_node*, tree_node*): missing endbr64
ld.lld: warning: vn_hash_type(tree_node*): missing endbr64
ld.lld: warning: vn_hash_constant_with_type(tree_node*): missing endbr64
ld.lld: warning: vn_constant_eq_with_type(tree_node*, tree_node*): missing 
endbr64
ld.lld: warning: vn_constant_eq_with_type(tree_node*, tree_node*): missing 
endbr64
ld.lld: warning: iterative_hash_expr(tree_node const*, unsigned int): missing 
endbr64
and tons more

lang/gprolog.log
ld.lld: warning: predicate(pl2wam1/1): missing endbr64
ld.lld: warning: predicate(pl2wam1/1): missing endbr64
ld.lld: warning: predicate(compile_msg_start/2): missing endbr64
ld.lld: warning: predicate(cmd_line_args/3): missing endbr64
ld.lld: warning: predicate(cmd_line_arg1/3): missing endbr64
ld.lld: warning: predicate(cmd_line_arg1/3): missing endbr64
ld.lld: warning: predicate(cmd_line_arg1/3): missing endbr64
ld.lld: warning: predicate(cmd_line_arg1/3): missing endbr64
ld.lld: warning: predicate(cmd_line_arg1/3): missing endbr64
ld.lld: warning: directive_1: missing endbr64
ld.lld: warning: Prolog_Object_Initializer: missing endbr64
ld.lld: warning: System_Directives: missing endbr64
ld.lld: warning: User_Directives: missing endbr64

lang/hare/hare.log
ld: warning: preinit_hare: missing endbr64
ld: warning: encoding.utf8.prev: missing endbr64
ld: warning: encoding.utf8.next: missing endbr64
ld: warning: sort.cmp.strs: missing endbr64
ld: warning: endian.leputu64: missing endbr64
ld: warning: endian.legetu64: missing endbr64
ld: warning: endian.leputu32: missing endbr64
ld: warning: endian.legetu32: missing endbr64
ld: warning: endian.leputu16: missing endbr64
ld: warning: endian.legetu16: missing endbr64
ld: warning: endian.beputu64: missing endbr64
ld: warning: endian.begetu64: missing endbr64
ld: warning: endian.beputu32: missing endbr64
ld: warning: endian.begetu32: missing endbr64
ld: warning: endian.beputu16: missing endbr64
ld: warning: endian.begetu16: missing endbr64
ld: warning: hare.unparse.syn_nowrap: missing endbr64

lang/luajit.log
ld.lld: warning: lj_vm_unwind_c_eh: missing endbr64
ld.lld: warning: lj_vm_unwind_rethrow: missing endbr64
ld.lld: warning: lj_vm_unwind_ff_eh: missing endbr64
ld.lld: warning: lj_cont_cat: missing endbr64
ld.lld: warning: lj_cont_ra: missing endbr64
ld.lld: warning: lj_cont_nop: missing endbr64
ld.lld: warning: lj_cont_condt: missing endbr64
etc

mail/rspamd.log
ld.lld: warning: chacha_blocks_avx2: missing endbr64
ld.lld: warning: _chacha_blocks_avx2: missing endbr64
ld.lld: warning: hchacha_avx2: missing endbr64
ld.lld: warning: _hchacha_avx2: missing endbr64
ld.lld: warning: chacha_avx2: missing endbr64
ld.lld: warning: _chacha_avx2: missing endbr64
ld.lld: warning: xchacha_avx2: missing endbr64
ld.lld: warning: _xchacha_avx2: missing endbr64
ld.lld: warning: chacha_blocks_avx: missing endbr64
ld.lld: warning: _chacha_blocks_avx: missing endbr64
ld.lld: warning: hchacha_avx: missing endbr64
ld.lld: warning: _hchacha_avx: missing endbr64
ld.lld: warning: chacha_avx: missing endbr64
ld.lld: warning: _chacha_avx: missing endbr64
ld.lld: warning: xchacha_avx: missing endbr64
ld.lld: warning: _xchacha_avx: missing endbr64
ld.lld: warning: chacha_blocks_sse2: missing endbr64
ld.lld: warning: _chacha_blocks_sse2: missing endbr64
ld.lld: warning: hchacha_sse2: missing endbr64
ld.lld: warning: _hchacha_sse2: missing endbr64
ld.lld: warning: chacha_sse2: missing endbr64
ld.lld: warning: _chacha_sse2: missing endbr64
ld.lld: warning: xchacha_sse2: missing endbr64
ld.lld: warning: _xchacha_sse2: missing endbr64

math/ecm.log
ld: warning: mulredc1: missing endbr64
ld: warning: mulredc2: missing endbr64
ld: warning: mulredc3: missing endbr64
ld: warning: mulredc4: missing endbr64
ld: warning: mulredc5: missing endbr64
etc

multimedia/aom.log
ld: warning: aom_highbd_dc_predictor_4x4_sse2: missing endbr64
ld: warning: aom_highbd_dc_predictor_8x8_sse2: missing endbr64
ld: warning: aom_highbd_dc_predictor_16x16_sse2: missing endbr64
ld: warning: aom_highbd_dc_predictor_32x32_sse2: missing endbr64
ld: warning: aom_highbd_v_predictor_4x4_sse2: missing endbr64
ld: warning: aom_highbd_v_predictor_8x8_sse2: missing endbr64
ld: warning: aom_highbd_v_predictor_16x16_sse2: missing endbr64
ld: warning: aom_highbd_v_predictor_32x32_sse2: missing endbr64
ld: warning

Re: openssl/3.1: missing endbr64 in bsaes_xts

2024-02-24 Thread Mark Kettenis
> Date: Sat, 24 Feb 2024 17:59:55 +0100
> From: Theo Buehler 
> 
> Two more endbr64 were missed in 3.1. I'll sync the diff to quictls.

These are indeed assigned to function pointers in crypto/evp/e_aes.c

ok kettenis@

> Index: Makefile
> ===
> RCS file: /cvs/ports/security/openssl/3.1/Makefile,v
> diff -u -p -r1.21 Makefile
> --- Makefile  22 Feb 2024 13:47:11 -  1.21
> +++ Makefile  24 Feb 2024 16:51:43 -
> @@ -10,7 +10,7 @@ V=  3.1.5
>  PKGNAME= openssl-${V}
>  PKGSPEC= openssl->=3.1v0,<3.2v0
>  EPOCH=   0
> -REVISION=1
> +REVISION=2
>  
>  SHLIBVER=15.1
>  SHARED_LIBS= crypto ${SHLIBVER} \
> Index: patches/patch-crypto_aes_asm_bsaes-x86_64_pl
> ===
> RCS file: 
> /cvs/ports/security/openssl/3.1/patches/patch-crypto_aes_asm_bsaes-x86_64_pl,v
> diff -u -p -r1.1.1.1 patch-crypto_aes_asm_bsaes-x86_64_pl
> --- patches/patch-crypto_aes_asm_bsaes-x86_64_pl  14 Mar 2023 18:54:42 
> -  1.1.1.1
> +++ patches/patch-crypto_aes_asm_bsaes-x86_64_pl  24 Feb 2024 16:50:24 
> -
> @@ -1,7 +1,23 @@
>  Index: crypto/aes/asm/bsaes-x86_64.pl
>  --- crypto/aes/asm/bsaes-x86_64.pl.orig
>  +++ crypto/aes/asm/bsaes-x86_64.pl
> -@@ -3003,6 +3003,7 @@ ___
> +@@ -2182,6 +2182,7 @@ $code.=<<___;
> + .align  16
> + ossl_bsaes_xts_encrypt:
> + .cfi_startproc
> ++endbranch
> + mov %rsp, %rax
> + .Lxts_enc_prologue:
> + push%rbp
> +@@ -2581,6 +2582,7 @@ $code.=<<___;
> + .align  16
> + ossl_bsaes_xts_decrypt:
> + .cfi_startproc
> ++endbranch
> + mov %rsp, %rax
> + .Lxts_dec_prologue:
> + push%rbp
> +@@ -3003,6 +3005,7 @@ ___
>   }
>   $code.=<<___;
>   .type   _bsaes_const,\@object
> @@ -9,7 +25,7 @@ Index: crypto/aes/asm/bsaes-x86_64.pl
>   .align  64
>   _bsaes_const:
>   .LM0ISR:# InvShiftRows constants
> -@@ -3054,9 +3055,9 @@ _bsaes_const:
> +@@ -3054,9 +3057,9 @@ _bsaes_const:
>   .quad   0x02060a0e03070b0f, 0x0004080c0105090d
>   .L63:
>   .quad   0x6363636363636363, 0x6363636363636363
> 



openssl/3.1: missing endbr64 in bsaes_xts

2024-02-24 Thread Theo Buehler
Two more endbr64 were missed in 3.1. I'll sync the diff to quictls.

Index: Makefile
===
RCS file: /cvs/ports/security/openssl/3.1/Makefile,v
diff -u -p -r1.21 Makefile
--- Makefile22 Feb 2024 13:47:11 -  1.21
+++ Makefile24 Feb 2024 16:51:43 -
@@ -10,7 +10,7 @@ V=3.1.5
 PKGNAME=   openssl-${V}
 PKGSPEC=   openssl->=3.1v0,<3.2v0
 EPOCH= 0
-REVISION=  1
+REVISION=  2
 
 SHLIBVER=  15.1
 SHARED_LIBS=   crypto ${SHLIBVER} \
Index: patches/patch-crypto_aes_asm_bsaes-x86_64_pl
===
RCS file: 
/cvs/ports/security/openssl/3.1/patches/patch-crypto_aes_asm_bsaes-x86_64_pl,v
diff -u -p -r1.1.1.1 patch-crypto_aes_asm_bsaes-x86_64_pl
--- patches/patch-crypto_aes_asm_bsaes-x86_64_pl14 Mar 2023 18:54:42 
-  1.1.1.1
+++ patches/patch-crypto_aes_asm_bsaes-x86_64_pl24 Feb 2024 16:50:24 
-
@@ -1,7 +1,23 @@
 Index: crypto/aes/asm/bsaes-x86_64.pl
 --- crypto/aes/asm/bsaes-x86_64.pl.orig
 +++ crypto/aes/asm/bsaes-x86_64.pl
-@@ -3003,6 +3003,7 @@ ___
+@@ -2182,6 +2182,7 @@ $code.=<<___;
+ .align16
+ ossl_bsaes_xts_encrypt:
+ .cfi_startproc
++  endbranch
+   mov %rsp, %rax
+ .Lxts_enc_prologue:
+   push%rbp
+@@ -2581,6 +2582,7 @@ $code.=<<___;
+ .align16
+ ossl_bsaes_xts_decrypt:
+ .cfi_startproc
++  endbranch
+   mov %rsp, %rax
+ .Lxts_dec_prologue:
+   push%rbp
+@@ -3003,6 +3005,7 @@ ___
  }
  $code.=<<___;
  .type _bsaes_const,\@object
@@ -9,7 +25,7 @@ Index: crypto/aes/asm/bsaes-x86_64.pl
  .align64
  _bsaes_const:
  .LM0ISR:  # InvShiftRows constants
-@@ -3054,9 +3055,9 @@ _bsaes_const:
+@@ -3054,9 +3057,9 @@ _bsaes_const:
.quad   0x02060a0e03070b0f, 0x0004080c0105090d
  .L63:
.quad   0x6363636363636363, 0x6363636363636363



Re: openssl/1.1: missing endbr64 for padlock engine

2024-02-24 Thread Theo Buehler
On Sat, Feb 24, 2024 at 05:39:23PM +0100, Mark Kettenis wrote:
> > Date: Sat, 24 Feb 2024 17:33:10 +0100
> > From: Theo Buehler 
> > 
> > This adds missing endbr64 to the padlock engine in openssl/1.1:
> > 
> > ld: warning: padlock_capability: missing endbr64
> > ld: warning: padlock_key_bswap: missing endbr64
> > ld: warning: padlock_verify_context: missing endbr64
> > ld: warning: padlock_reload_key: missing endbr64
> > ld: warning: padlock_aes_block: missing endbr64
> > ld: warning: padlock_xstore: missing endbr64
> > ld: warning: padlock_sha1_oneshot: missing endbr64
> > ld: warning: padlock_sha1_blocks: missing endbr64
> > ld: warning: padlock_sha256_oneshot: missing endbr64
> > ld: warning: padlock_sha256_blocks: missing endbr64
> > ld: warning: padlock_sha512_blocks: missing endbr64
> > ld: warning: padlock_ecb_encrypt: missing endbr64
> > ld: warning: padlock_cbc_encrypt: missing endbr64
> > ld: warning: padlock_cfb_encrypt: missing endbr64
> > ld: warning: padlock_ofb_encrypt: missing endbr64
> > ld: warning: padlock_ctr32_encrypt: missing endbr64
> 
> Not opposed to fixing these, but I doubt we'll ever see a CPU that has
> both the VIA PadLock instructions and IBT ;).
> 
> (Sorry, didn't realize this until after I sent out that diff)

Me neither until deraadt pointed it out off-list.

> ok kettenis@ (but also fine if you decide to drop this)

Let's not do it then.

> Is this code still there in openssl 3.x?

Yes, it is there and it does not have endbr64 annotations unlike most
of the other code.



Re: openssl/1.1: missing endbr64 for padlock engine

2024-02-24 Thread Mark Kettenis
> Date: Sat, 24 Feb 2024 17:33:10 +0100
> From: Theo Buehler 
> 
> This adds missing endbr64 to the padlock engine in openssl/1.1:
> 
> ld: warning: padlock_capability: missing endbr64
> ld: warning: padlock_key_bswap: missing endbr64
> ld: warning: padlock_verify_context: missing endbr64
> ld: warning: padlock_reload_key: missing endbr64
> ld: warning: padlock_aes_block: missing endbr64
> ld: warning: padlock_xstore: missing endbr64
> ld: warning: padlock_sha1_oneshot: missing endbr64
> ld: warning: padlock_sha1_blocks: missing endbr64
> ld: warning: padlock_sha256_oneshot: missing endbr64
> ld: warning: padlock_sha256_blocks: missing endbr64
> ld: warning: padlock_sha512_blocks: missing endbr64
> ld: warning: padlock_ecb_encrypt: missing endbr64
> ld: warning: padlock_cbc_encrypt: missing endbr64
> ld: warning: padlock_cfb_encrypt: missing endbr64
> ld: warning: padlock_ofb_encrypt: missing endbr64
> ld: warning: padlock_ctr32_encrypt: missing endbr64

Not opposed to fixing these, but I doubt we'll ever see a CPU that has
both the VIA PadLock instructions and IBT ;).

(Sorry, didn't realize this until after I sent out that diff)

ok kettenis@ (but also fine if you decide to drop this)

Is this code still there in openssl 3.x?


> Index: Makefile
> ===
> RCS file: /cvs/ports/security/openssl/1.1/Makefile,v
> diff -u -p -r1.67 Makefile
> --- Makefile  18 Feb 2024 22:36:59 -  1.67
> +++ Makefile  24 Feb 2024 16:29:35 -
> @@ -8,7 +8,7 @@ PORTROACH=limit:^1\.1\.[0-9][a-z] skipb
>  V=   1.1.1w
>  PKGSPEC= openssl->=1.1.0v0,<1.2v0
>  EPOCH=   0
> -REVISION=1
> +REVISION=2
>  
>  SHLIBVER=11.6
>  SHARED_LIBS= crypto ${SHLIBVER} \
> Index: patches/patch-engines_asm_e_padlock-x86_64_pl
> ===
> RCS file: patches/patch-engines_asm_e_padlock-x86_64_pl
> diff -N patches/patch-engines_asm_e_padlock-x86_64_pl
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-engines_asm_e_padlock-x86_64_pl 24 Feb 2024 16:23:50 
> -
> @@ -0,0 +1,99 @@
> +Index: engines/asm/e_padlock-x86_64.pl
> +--- engines/asm/e_padlock-x86_64.pl.orig
>  engines/asm/e_padlock-x86_64.pl
> +@@ -52,6 +52,7 @@ $code.=<<___;
> + .type   padlock_capability,\@abi-omnipotent
> + .align  16
> + padlock_capability:
> ++endbranch;
> + mov %rbx,%r8
> + xor %eax,%eax
> + cpuid
> +@@ -91,6 +92,7 @@ padlock_capability:
> + .type   padlock_key_bswap,\@abi-omnipotent,0
> + .align  16
> + padlock_key_bswap:
> ++endbranch;
> + mov 240($arg1),%edx
> + inc %edx
> + shl \$2,%edx
> +@@ -108,6 +110,7 @@ padlock_key_bswap:
> + .type   padlock_verify_context,\@abi-omnipotent
> + .align  16
> + padlock_verify_context:
> ++endbranch;
> + mov $arg1,$ctx
> + pushf
> + lea .Lpadlock_saved_context(%rip),%rax
> +@@ -135,6 +138,7 @@ _padlock_verify_ctx:
> + .type   padlock_reload_key,\@abi-omnipotent
> + .align  16
> + padlock_reload_key:
> ++endbranch;
> + pushf
> + popf
> + ret
> +@@ -144,6 +148,7 @@ padlock_reload_key:
> + .type   padlock_aes_block,\@function,3
> + .align  16
> + padlock_aes_block:
> ++endbranch;
> + mov %rbx,%r8
> + mov \$1,$len
> + lea 32($ctx),%rbx   # key
> +@@ -157,6 +162,7 @@ padlock_aes_block:
> + .type   padlock_xstore,\@function,2
> + .align  16
> + padlock_xstore:
> ++endbranch;
> + mov %esi,%edx
> + .byte   0x0f,0xa7,0xc0  # xstore
> + ret
> +@@ -166,6 +172,7 @@ padlock_xstore:
> + .type   padlock_sha1_oneshot,\@function,3
> + .align  16
> + padlock_sha1_oneshot:
> ++endbranch;
> + mov %rdx,%rcx
> + mov %rdi,%rdx   # put aside %rdi
> + movups  (%rdi),%xmm0# copy-in context
> +@@ -188,6 +195,7 @@ padlock_sha1_oneshot:
> + .type   padlock_sha1_blocks,\@function,3
> + .align  16
> + padlock_sha1_blocks:
> ++endbranch;
> + mov %rdx,%rcx
> + mov %rdi,%rdx   # put aside %rdi
> + movups  (%rdi),%xmm0# copy-in context
> +@@ -210,6 +218,7 @@ padlock_sha1_blocks:
> + .type   padlock_sha256_oneshot,\@function,3
> + .align  16
> + padlock_sha256_oneshot:
> ++endbranch;
> + mov %rdx,%rcx
> + mov %rdi,%rdx   # put aside %rdi
> + movups  (%rdi),%xmm0# copy-in context
> +@@ -232,6 +241,7 @@ padlock_sha256_oneshot:
> + .type   padlock

openssl/1.1: missing endbr64 for padlock engine

2024-02-24 Thread Theo Buehler
This adds missing endbr64 to the padlock engine in openssl/1.1:

ld: warning: padlock_capability: missing endbr64
ld: warning: padlock_key_bswap: missing endbr64
ld: warning: padlock_verify_context: missing endbr64
ld: warning: padlock_reload_key: missing endbr64
ld: warning: padlock_aes_block: missing endbr64
ld: warning: padlock_xstore: missing endbr64
ld: warning: padlock_sha1_oneshot: missing endbr64
ld: warning: padlock_sha1_blocks: missing endbr64
ld: warning: padlock_sha256_oneshot: missing endbr64
ld: warning: padlock_sha256_blocks: missing endbr64
ld: warning: padlock_sha512_blocks: missing endbr64
ld: warning: padlock_ecb_encrypt: missing endbr64
ld: warning: padlock_cbc_encrypt: missing endbr64
ld: warning: padlock_cfb_encrypt: missing endbr64
ld: warning: padlock_ofb_encrypt: missing endbr64
ld: warning: padlock_ctr32_encrypt: missing endbr64

Index: Makefile
===
RCS file: /cvs/ports/security/openssl/1.1/Makefile,v
diff -u -p -r1.67 Makefile
--- Makefile18 Feb 2024 22:36:59 -  1.67
+++ Makefile24 Feb 2024 16:29:35 -
@@ -8,7 +8,7 @@ PORTROACH=  limit:^1\.1\.[0-9][a-z] skipb
 V= 1.1.1w
 PKGSPEC=   openssl->=1.1.0v0,<1.2v0
 EPOCH= 0
-REVISION=  1
+REVISION=  2
 
 SHLIBVER=  11.6
 SHARED_LIBS=   crypto ${SHLIBVER} \
Index: patches/patch-engines_asm_e_padlock-x86_64_pl
===
RCS file: patches/patch-engines_asm_e_padlock-x86_64_pl
diff -N patches/patch-engines_asm_e_padlock-x86_64_pl
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-engines_asm_e_padlock-x86_64_pl   24 Feb 2024 16:23:50 
-
@@ -0,0 +1,99 @@
+Index: engines/asm/e_padlock-x86_64.pl
+--- engines/asm/e_padlock-x86_64.pl.orig
 engines/asm/e_padlock-x86_64.pl
+@@ -52,6 +52,7 @@ $code.=<<___;
+ .type padlock_capability,\@abi-omnipotent
+ .align16
+ padlock_capability:
++  endbranch;
+   mov %rbx,%r8
+   xor %eax,%eax
+   cpuid
+@@ -91,6 +92,7 @@ padlock_capability:
+ .type padlock_key_bswap,\@abi-omnipotent,0
+ .align16
+ padlock_key_bswap:
++  endbranch;
+   mov 240($arg1),%edx
+   inc %edx
+   shl \$2,%edx
+@@ -108,6 +110,7 @@ padlock_key_bswap:
+ .type padlock_verify_context,\@abi-omnipotent
+ .align16
+ padlock_verify_context:
++  endbranch;
+   mov $arg1,$ctx
+   pushf
+   lea .Lpadlock_saved_context(%rip),%rax
+@@ -135,6 +138,7 @@ _padlock_verify_ctx:
+ .type padlock_reload_key,\@abi-omnipotent
+ .align16
+ padlock_reload_key:
++  endbranch;
+   pushf
+   popf
+   ret
+@@ -144,6 +148,7 @@ padlock_reload_key:
+ .type padlock_aes_block,\@function,3
+ .align16
+ padlock_aes_block:
++  endbranch;
+   mov %rbx,%r8
+   mov \$1,$len
+   lea 32($ctx),%rbx   # key
+@@ -157,6 +162,7 @@ padlock_aes_block:
+ .type padlock_xstore,\@function,2
+ .align16
+ padlock_xstore:
++  endbranch;
+   mov %esi,%edx
+   .byte   0x0f,0xa7,0xc0  # xstore
+   ret
+@@ -166,6 +172,7 @@ padlock_xstore:
+ .type padlock_sha1_oneshot,\@function,3
+ .align16
+ padlock_sha1_oneshot:
++  endbranch;
+   mov %rdx,%rcx
+   mov %rdi,%rdx   # put aside %rdi
+   movups  (%rdi),%xmm0# copy-in context
+@@ -188,6 +195,7 @@ padlock_sha1_oneshot:
+ .type padlock_sha1_blocks,\@function,3
+ .align16
+ padlock_sha1_blocks:
++  endbranch;
+   mov %rdx,%rcx
+   mov %rdi,%rdx   # put aside %rdi
+   movups  (%rdi),%xmm0# copy-in context
+@@ -210,6 +218,7 @@ padlock_sha1_blocks:
+ .type padlock_sha256_oneshot,\@function,3
+ .align16
+ padlock_sha256_oneshot:
++  endbranch;
+   mov %rdx,%rcx
+   mov %rdi,%rdx   # put aside %rdi
+   movups  (%rdi),%xmm0# copy-in context
+@@ -232,6 +241,7 @@ padlock_sha256_oneshot:
+ .type padlock_sha256_blocks,\@function,3
+ .align16
+ padlock_sha256_blocks:
++  endbranch;
+   mov %rdx,%rcx
+   mov %rdi,%rdx   # put aside %rdi
+   movups  (%rdi),%xmm0# copy-in context
+@@ -254,6 +264,7 @@ padlock_sha256_blocks:
+ .type padlock_sha512_blocks,\@function,3
+ .align16
+ padlock_sha512_blocks:
++  endbranch;
+   mov %rdx,%rcx
+   mov %rdi,%rdx   # put aside %rdi
+   movups  (%rdi),%xmm0# copy-in context
+@@ -289,6 +300,7 @@ $code.=<<___;
+ .type padlock_${mode}_encrypt,\@function,4
+ .align16
+ padlock_${mode}_encrypt:
++  endbranch;
+   push%rbp
+   push%rbx
+