Mark Kettenis wrote:
> I'm not sure to what extent this makes IBT less effective. Can the
> retpolines be used as gadgets to bypass IBT? Should we stop enabling
> retpolines by default?
>
> What *is* obvious is that retpolines are incompatible wuth shadow
> stacks. Is there an alternative tha
> Date: Tue, 25 Jul 2023 16:51:18 +0200
> From: Christian Weisgerber
>
> Christian Weisgerber:
>
> > Because amd64 should suffer from the same problem:
> >
> > fr->cpu_opts.the_dct36 = dct36_avx;
> > ...
> > fr->cpu_opts.the_dct36 = dct36_x86_64;
> >
> >
Christian Weisgerber:
> Because amd64 should suffer from the same problem:
>
> fr->cpu_opts.the_dct36 = dct36_avx;
> ...
> fr->cpu_opts.the_dct36 = dct36_x86_64;
>
> dct36_avx and dct36_x86_64 are assembly routines that lack the
> endbr64 landing pad. And
> From: "Theo de Raadt"
> Date: Tue, 25 Jul 2023 08:23:14 -0600
>
> Christian Weisgerber wrote:
>
> > Mark Kettenis:
> >
> > > This port has some infrastructure to use an optimized function that
> > > uses a function pointer. Not sure why for arm64 it actually uses that
> > > infrastructure,
Christian Weisgerber wrote:
> Mark Kettenis:
>
> > This port has some infrastructure to use an optimized function that
> > uses a function pointer. Not sure why for arm64 it actually uses that
> > infrastructure, since the only alternative is the generic C
> > implementation. But adding a BTI
Mark Kettenis:
> This port has some infrastructure to use an optimized function that
> uses a function pointer. Not sure why for arm64 it actually uses that
> infrastructure, since the only alternative is the generic C
> implementation. But adding a BTI instruction is the easiest fix.
ok naddy@
This port has some infrastructure to use an optimized function that
uses a function pointer. Not sure why for arm64 it actually uses that
infrastructure, since the only alternative is the generic C
implementation. But adding a BTI instruction is the easiest fix.
ok?
Index: audio/mpg123/Makefil
