Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 4 Jun 2020 17:44:33 +0300
From: Alexander Popov <>
To: Jann Horn <>
Cc: Will Deacon <>, Kees Cook <>,
 Emese Revfy <>,
 Miguel Ojeda <>,
 Masahiro Yamada <>,
 Michal Marek <>,
 Andrew Morton <>,
 Masahiro Yamada <>,
 Thiago Jung Bauermann <>,
 Luis Chamberlain <>, Jessica Yu <>,
 Sven Schnelle <>, Iurii Zaikin <>,
 Catalin Marinas <>,
 Vincenzo Frascino <>,
 Thomas Gleixner <>, Peter Collingbourne <>,
 Naohiro Aota <>, Alexander Monakov <>,
 Mathias Krause <>, PaX Team <>,
 Brad Spengler <>, Laura Abbott <>,
 Florian Weimer <>,
 Kernel Hardening <>,, the arch/x86 maintainers <>,
 Linux ARM <>,
 kernel list <>,,
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 <> wrote:
>> On 04.06.2020 17:14, Jann Horn wrote:
>>> Maybe at some point we should replace exclusions based on
>>> 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,

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.