[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a3b35021-9ebd-3113-398d-6832d26ea219@linux.com>
Date: Thu, 4 Jun 2020 17:44:33 +0300
From: Alexander Popov <alex.popov@...ux.com>
To: Jann Horn <jannh@...gle.com>
Cc: Will Deacon <will@...nel.org>, Kees Cook <keescook@...omium.org>,
Emese Revfy <re.emese@...il.com>,
Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
Masahiro Yamada <masahiroy@...nel.org>,
Michal Marek <michal.lkml@...kovi.net>,
Andrew Morton <akpm@...ux-foundation.org>,
Masahiro Yamada <yamada.masahiro@...ionext.com>,
Thiago Jung Bauermann <bauerman@...ux.ibm.com>,
Luis Chamberlain <mcgrof@...nel.org>, Jessica Yu <jeyu@...nel.org>,
Sven Schnelle <svens@...ckframe.org>, Iurii Zaikin <yzaikin@...gle.com>,
Catalin Marinas <catalin.marinas@....com>,
Vincenzo Frascino <vincenzo.frascino@....com>,
Thomas Gleixner <tglx@...utronix.de>, Peter Collingbourne <pcc@...gle.com>,
Naohiro Aota <naohiro.aota@....com>, Alexander Monakov <amonakov@...ras.ru>,
Mathias Krause <minipli@...glemail.com>, PaX Team <pageexec@...email.hu>,
Brad Spengler <spender@...ecurity.net>, Laura Abbott <labbott@...hat.com>,
Florian Weimer <fweimer@...hat.com>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>,
linux-kbuild@...r.kernel.org, the arch/x86 maintainers <x86@...nel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
kernel list <linux-kernel@...r.kernel.org>, gcc@....gnu.org,
notify@...nel.org
Subject: Re: [PATCH 5/5] gcc-plugins/stackleak: Don't instrument
vgettimeofday.c in arm64 VDSO
On 04.06.2020 17:25, Jann Horn wrote:
> On Thu, Jun 4, 2020 at 4:21 PM Alexander Popov <alex.popov@...ux.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
