From: Alexander Popov <alex.popov@linux.com>
To: Jann Horn <jannh@google.com>
Cc: Will Deacon <will@kernel.org>, Kees Cook <keescook@chromium.org>,
Emese Revfy <re.emese@gmail.com>,
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
Masahiro Yamada <masahiroy@kernel.org>,
Michal Marek <michal.lkml@markovi.net>,
Andrew Morton <akpm@linux-foundation.org>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
Thiago Jung Bauermann <bauerman@linux.ibm.com>,
Luis Chamberlain <mcgrof@kernel.org>,
Jessica Yu <jeyu@kernel.org>,
Sven Schnelle <svens@stackframe.org>,
Iurii Zaikin <yzaikin@google.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Collingbourne <pcc@google.com>,
Naohiro Aota <naohiro.aota@wdc.com>,
Alexander Monakov <amonakov@ispras.ru>,
Mathias Krause <minipli@googlemail.com>,
PaX Team <pageexec@freemail.hu>,
Brad Spengler <spender@grsecurity.net>,
Laura Abbott <labbott@redhat.com>,
Florian Weimer <fweimer@redhat.com>,
Kernel Hardening <kernel-hardening@lists.openwall.com>,
linux-kbuild@vger.kernel.org,
the arch/x86 maintainers <x86@kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
kernel list <linux-kernel@vger.kernel.org>,
gcc@gcc.gnu.org, notify@kernel.org
Subject: Re: [PATCH 5/5] gcc-plugins/stackleak: Don't instrument vgettimeofday.c in arm64 VDSO
Date: Thu, 4 Jun 2020 17:44:33 +0300 [thread overview]
Message-ID: <a3b35021-9ebd-3113-398d-6832d26ea219@linux.com> (raw)
In-Reply-To: <CAG48ez3LZ1xzAYHm23JOXTFBZqaHkVVZXwSe+VmmCBTwxKOdUQ@mail.gmail.com>
On 04.06.2020 17:25, Jann Horn wrote:
> On Thu, Jun 4, 2020 at 4:21 PM Alexander Popov <alex.popov@linux.com> wrote:
>> On 04.06.2020 17:14, Jann Horn wrote:
>>> Maybe at some point we should replace exclusions based on
>>> GCC_PLUGINS_CFLAGS and KASAN_SANITIZE and UBSAN_SANITIZE and
>>> OBJECT_FILES_NON_STANDARD and so on with something more generic...
>>> something that says "this file will not be built into the normal
>>> kernel, it contains code that runs in realmode / userspace / some
>>> similarly weird context, and none of our instrumentation
>>> infrastructure is available there"...
>>
>> Good idea. I would also add 'notrace' to that list.
>
> Hm? notrace code should definitely still be subject to sanitizer
> instrumentation.
I mean ftrace is sometimes disabled for functions that are executed in those
weird contexts. As well as kcov instrumentation.
It would be nice if that generic mechanism could help with choosing which kernel
code instrumentation technologies should be disabled in the given context.
Best regards,
Alexander
next prev parent reply other threads:[~2020-06-04 14:44 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-04 13:49 [PATCH 0/5] Improvements of the stackleak gcc plugin Alexander Popov
2020-06-04 13:49 ` [PATCH 1/5] gcc-plugins/stackleak: Exclude alloca() from the instrumentation logic Alexander Popov
2020-06-04 14:01 ` Jann Horn
2020-06-04 15:23 ` Alexander Popov
2020-06-09 18:39 ` Kees Cook
2020-06-10 15:24 ` Alexander Popov
2020-06-04 13:49 ` [PATCH 2/5] gcc-plugins/stackleak: Use asm instrumentation to avoid useless register saving Alexander Popov
2020-06-04 15:05 ` Miguel Ojeda
2020-06-09 18:46 ` Kees Cook
2020-06-10 15:47 ` Alexander Popov
2020-06-10 20:03 ` Kees Cook
2020-06-11 23:45 ` Alexander Popov
2020-06-04 13:49 ` [PATCH 3/5] gcc-plugins/stackleak: Add 'verbose' plugin parameter Alexander Popov
2020-06-09 18:47 ` Kees Cook
2020-06-10 15:52 ` Alexander Popov
2020-06-10 20:04 ` Kees Cook
2020-06-04 13:49 ` [PATCH 4/5] gcc-plugins/stackleak: Don't instrument itself Alexander Popov
2020-06-09 18:48 ` Kees Cook
2020-06-04 13:49 ` [PATCH 5/5] gcc-plugins/stackleak: Don't instrument vgettimeofday.c in arm64 VDSO Alexander Popov
2020-06-04 13:58 ` Will Deacon
2020-06-04 14:14 ` Jann Horn
2020-06-04 14:20 ` Alexander Popov
2020-06-04 14:25 ` Jann Horn
2020-06-04 14:44 ` Alexander Popov [this message]
2020-06-09 19:09 ` Kees Cook
2020-06-10 7:30 ` Will Deacon
2020-06-10 15:18 ` Alexander Popov
2020-06-23 10:16 ` Alexander Popov
2020-06-04 21:39 ` [PATCH 0/5] Improvements of the stackleak gcc plugin Kees Cook
2020-06-09 19:15 ` Kees Cook
2020-06-10 15:14 ` Alexander Popov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a3b35021-9ebd-3113-398d-6832d26ea219@linux.com \
--to=alex.popov@linux.com \
--cc=akpm@linux-foundation.org \
--cc=amonakov@ispras.ru \
--cc=bauerman@linux.ibm.com \
--cc=catalin.marinas@arm.com \
--cc=fweimer@redhat.com \
--cc=gcc@gcc.gnu.org \
--cc=jannh@google.com \
--cc=jeyu@kernel.org \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=labbott@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=mcgrof@kernel.org \
--cc=michal.lkml@markovi.net \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=minipli@googlemail.com \
--cc=naohiro.aota@wdc.com \
--cc=notify@kernel.org \
--cc=pageexec@freemail.hu \
--cc=pcc@google.com \
--cc=re.emese@gmail.com \
--cc=spender@grsecurity.net \
--cc=svens@stackframe.org \
--cc=tglx@linutronix.de \
--cc=vincenzo.frascino@arm.com \
--cc=will@kernel.org \
--cc=x86@kernel.org \
--cc=yamada.masahiro@socionext.com \
--cc=yzaikin@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).