linux-kernel - Re: [PATCH v1 0/7] tools: add linker table userspace sandbox

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 22 Aug 2016 11:59:46 +0200
From:   Vegard Nossum <vegard.nossum@...il.com>
To:     "Luis R. Rodriguez" <mcgrof@...nel.org>
Cc:     linux-arch@...r.kernel.org, kbuild <linux-kbuild@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 0/7] tools: add linker table userspace sandbox

(trimmed Ccs... jeez)

On 19 August 2016 at 23:41,  <mcgrof@...nel.org> wrote:
> From: "Luis R. Rodriguez" <mcgrof@...nel.org>
>
> The original v3 series for linker tables made reference only to
> an external repository userspace sandbox application, however
> Boris noted it'd be difficult ot keep this in sync with the
> kernel so advised to consider integrate with the kernel. I've
> taken steps in this direction.
[...]
> Please let me know if there are any issue or questions.

+#define __VMLINUX_SYMBOL(x) x

+#define VMLINUX_SYMBOL(x) __VMLINUX_SYMBOL(x)

+#define LINUX_SECTION_START(name)      VMLINUX_SYMBOL(name)

+#define DECLARE_LINUX_SECTION(type, name)                              \
+        extern type VMLINUX_SYMBOL(name)[], \
+                    VMLINUX_SYMBOL(name##__end)[]

+#define DECLARE_LINKTABLE(type, name)                                  \
+       DECLARE_LINUX_SECTION(type, name)

+#define LINKTABLE_FOR_EACH(pointer, tbl)                               \
+       for (pointer = LINUX_SECTION_START(tbl);                        \
+            pointer < LINUX_SECTION_END(tbl);                          \
+            pointer++)

I think this is subject to getting optimised out by newer gccs, since
it sees the START(tbl) and END(tbl) symbols as two completely
different arrays. See the short discussion here:

https://lkml.org/lkml/2016/6/26/73 (the first attempt is wrong, so
don't look at that)

It is possible that < is different from != and always does the right
thing, but I haven't checked.

I have a WIP branch that converts most of the existing tables in the
kernel to use the external_array() macro which makes gcc throw away
any knowledge it had about a pointer being part of an array.


Vegard