lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 24 Sep 2020 14:20:09 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'YiFei Zhu' <zhuyifei1999@...il.com>
CC:     "containers@...ts.linux-foundation.org" 
        <containers@...ts.linux-foundation.org>,
        YiFei Zhu <yifeifz2@...inois.edu>,
        "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Aleksa Sarai <cyphar@...har.com>,
        "Andrea Arcangeli" <aarcange@...hat.com>,
        Andy Lutomirski <luto@...capital.net>,
        Dimitrios Skarlatos <dskarlat@...cmu.edu>,
        Giuseppe Scrivano <gscrivan@...hat.com>,
        Hubertus Franke <frankeh@...ibm.com>,
        Jack Chen <jianyan2@...inois.edu>,
        Jann Horn <jannh@...gle.com>,
        Josep Torrellas <torrella@...inois.edu>,
        Kees Cook <keescook@...omium.org>,
        Tianyin Xu <tyxu@...inois.edu>,
        Tobin Feldman-Fitzthum <tobin@....com>,
        Tycho Andersen <tycho@...ho.pizza>,
        Valentin Rothberg <vrothber@...hat.com>,
        Will Drewry <wad@...omium.org>
Subject: RE: [PATCH v2 seccomp 2/6] asm/syscall.h: Add syscall_arches[] array

From: YiFei Zhu
> Sent: 24 September 2020 15:17
> 
> On Thu, Sep 24, 2020 at 8:47 AM David Laight <David.Laight@...lab.com> 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
> [...]
> 0000000000001520 <__seccomp_filter>:
> [...]
>     1587:       41 8b 54 24 04          mov    0x4(%r12),%edx
>     158c:       b9 08 01 00 00          mov    $0x108,%ecx
>     1591:       81 fa 3e 00 00 c0       cmp    $0xc000003e,%edx
>     1597:       75 2e                   jne    15c7 <__seccomp_filter+0xa7>
> [...]
>     15c7:       81 fa 03 00 00 40       cmp    $0x40000003,%edx
>     15cd:       b9 40 01 00 00          mov    $0x140,%ecx
>     15d2:       74 c5                   je     1599 <__seccomp_filter+0x79>
>     15d4:       0f 0b                   ud2
> [...]
> 0000000000001cb0 <seccomp_cache_prepare>:
> [...]
>     1cc4:       41 b9 3e 00 00 c0       mov    $0xc000003e,%r9d
> [...]
>     1dba:       41 b9 03 00 00 40       mov    $0x40000003,%r9d
> [...]
> 0000000000002e30 <proc_pid_seccomp_cache>:
> [...]
>     2e72:       ba 3e 00 00 c0          mov    $0xc000003e,%edx
> [...]
>     2eb5:       ba 03 00 00 40          mov    $0x40000003,%edx
> 
> 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)
generate terrible code?

Try with a slghtly older gcc.
I think that entire optimisation (discarding const arrays)
is very recent.

	David
 

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ