On Thu, Sep 24, 2020 at 10:28 PM YiFei Zhu wrote:
> Ah. Makes sense.
>
> > Ironicailly, that's the only place I actually know for sure where people
> > using x32 because it shows measurable (10%) speed-up for builders:
> >
On Thu, Sep 24, 2020 at 10:09 PM Kees Cook wrote:
> Right, sorry, I may not have been clear. When building my RFC I noticed
> that I couldn't use NR_syscall very "early" in the header file include
> stack on arm64, which complicated things. So I guess what I mean is
> something like "it's
On Thu, Sep 24, 2020 at 08:27:40PM -0500, YiFei Zhu wrote:
> [resending this too]
>
> On Thu, Sep 24, 2020 at 6:01 PM Kees Cook wrote:
> > Disregarding the "how" of this, yeah, we'll certainly need something to
> > tell seccomp about the arrangement of syscall tables and how to find
> > them.
>
[resending this too]
On Thu, Sep 24, 2020 at 6:01 PM Kees Cook wrote:
> Disregarding the "how" of this, yeah, we'll certainly need something to
> tell seccomp about the arrangement of syscall tables and how to find
> them.
>
> However, I'd still prefer to do this on a per-arch basis, and include
On Fri, Sep 25, 2020 at 2:18 AM Al Viro wrote:
> On Fri, Sep 25, 2020 at 02:15:50AM +0200, Jann Horn wrote:
> > On Fri, Sep 25, 2020 at 2:01 AM Kees Cook wrote:
> > > 2) seccomp needs to handle "multiplexed" tables like x86_x32 (distros
> > >haven't removed CONFIG_X86_X32 widely yet, so it
On Fri, Sep 25, 2020 at 02:15:50AM +0200, Jann Horn wrote:
> On Fri, Sep 25, 2020 at 2:01 AM Kees Cook wrote:
> > 2) seccomp needs to handle "multiplexed" tables like x86_x32 (distros
> >haven't removed CONFIG_X86_X32 widely yet, so it is a reality that
> >it must be dealt with), which
On Fri, Sep 25, 2020 at 2:01 AM Kees Cook wrote:
> 2) seccomp needs to handle "multiplexed" tables like x86_x32 (distros
>haven't removed CONFIG_X86_X32 widely yet, so it is a reality that
>it must be dealt with), which means seccomp's idea of the arch
>"number" can't be the same as
[resend, argh, I didn't reply-all, sorry for the noise]
On Thu, Sep 24, 2020 at 07:44:17AM -0500, YiFei Zhu wrote:
> From: YiFei Zhu
>
> Seccomp cache emulator needs to know all the architecture numbers
> that syscall_get_arch() could return for the kernel build in order
> to generate a cache
On Thu, Sep 24, 2020 at 9:37 AM YiFei Zhu wrote:
> > Try with a slghtly older gcc.
> > I think that entire optimisation (discarding const arrays)
> > is very recent.
>
> Will try, will take a while to get an old GCC to run, however :/
Possibly one of the oldest I can easily get to work is GCC
On Thu, Sep 24, 2020 at 9:20 AM David Laight wrote:
> > Granted, I have CC_OPTIMIZE_FOR_PERFORMANCE rather than
> > CC_OPTIMIZE_FOR_SIZE, but this patch itself is trying to sacrifice
> > some of the memory for speed.
>
> Don't both CC_OPTIMIZE_FOR_PERFORMANCE (-??) and CC_OPTIMIZE_FOR_SIZE (-s)
>
From: YiFei Zhu
> Sent: 24 September 2020 15:17
>
> On Thu, Sep 24, 2020 at 8:47 AM David Laight wrote:
> > I doubt the compiler will do what you want.
> > Looking at it, in most cases there are one or two entries.
> > I think only MIPS has three.
>
> It does ;) GCC 10.2.0:
>
> $ objdump -d
On Thu, Sep 24, 2020 at 8:47 AM David Laight wrote:
> I doubt the compiler will do what you want.
> Looking at it, in most cases there are one or two entries.
> I think only MIPS has three.
It does ;) GCC 10.2.0:
$ objdump -d kernel/seccomp.o | less
[...]
1520 <__seccomp_filter>:
From: YiFei Zhu
> Sent: 24 September 2020 13:44
>
> Seccomp cache emulator needs to know all the architecture numbers
> that syscall_get_arch() could return for the kernel build in order
> to generate a cache for all of them.
>
> The array is declared in header as static __maybe_unused const
>
From: YiFei Zhu
Seccomp cache emulator needs to know all the architecture numbers
that syscall_get_arch() could return for the kernel build in order
to generate a cache for all of them.
The array is declared in header as static __maybe_unused const
to maximize compiler optimiation opportunities
14 matches
Mail list logo
