All of lore.kernel.org
 help / color / mirror / Atom feed
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] kernel: add kcov code coverage
Date: Fri, 22 Jan 2016 12:52:11 +0000	[thread overview]
Message-ID: <20160122125210.GA10802@leverpostej> (raw)
In-Reply-To: <CACT4Y+bvReSkPa5mtb4+Uy6GsoDiuawLzfzMPoJF++1X=H06aA@mail.gmail.com>

On Fri, Jan 22, 2016 at 01:15:27PM +0100, Dmitry Vyukov wrote:
> On Fri, Jan 22, 2016 at 12:55 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Mon, Jan 18, 2016 at 09:09:43PM +0100, Dmitry Vyukov wrote:
> >> On Mon, Jan 18, 2016 at 8:44 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
> >> > Regarding KASLR and dynamically loaded modules. I've looked at my
> >> > use-case and concluded
> >> > that most of the time I can work with "non-stable" PCs within a single
> >> > VM. Whenever I need to
> >> > store PCs persistently or send to another machine, I think I can
> >> > "canonicalize" PCs using
> >> > /proc/modules and /proc/kallsyms to something like (module hash,
> >> > module offset). So kernel does
> >> > not need to do this during coverage collection.
> >>
> >> On second though, maybe it's better to just always export unsigned long PCs...
> >> Need to measure how much memory coverage information consumes,
> >> and how much slower it is with uint64 PCs. Maybe I can live with large PCs,
> >> or maybe I can make syzkaller require !KASLR and compress PCs in user-space...
> >> Need to think about this more.
> >
> > I can imagine we might keep the expanded module range even in the
> > absence of full KASLR, though I don't know how realistic that thought
> > is.
> 
> The last version of the patch just exposes PCs as unsigned longs
> without any compression. So it should not be a problem (at least for
> kernel, now it's user responsibility to make sense out of the PCs).

Ah, ok. Sorry for the noise!

Mark.

WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: syzkaller <syzkaller@googlegroups.com>,
	Vegard Nossum <vegard.nossum@oracle.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Tavis Ormandy <taviso@google.com>,
	Will Deacon <will.deacon@arm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Quentin Casasnovas <quentin.casasnovas@oracle.com>,
	Kostya Serebryany <kcc@google.com>,
	Eric Dumazet <edumazet@google.com>,
	Alexander Potapenko <glider@google.com>,
	Kees Cook <keescook@google.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Sasha Levin <sasha.levin@oracle.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	David Drysdale <drysdale@google.com>,
	linux-arm-kernel@lists.infradead.org,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [PATCH v2] kernel: add kcov code coverage
Date: Fri, 22 Jan 2016 12:52:11 +0000	[thread overview]
Message-ID: <20160122125210.GA10802@leverpostej> (raw)
In-Reply-To: <CACT4Y+bvReSkPa5mtb4+Uy6GsoDiuawLzfzMPoJF++1X=H06aA@mail.gmail.com>

On Fri, Jan 22, 2016 at 01:15:27PM +0100, Dmitry Vyukov wrote:
> On Fri, Jan 22, 2016 at 12:55 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Mon, Jan 18, 2016 at 09:09:43PM +0100, Dmitry Vyukov wrote:
> >> On Mon, Jan 18, 2016 at 8:44 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
> >> > Regarding KASLR and dynamically loaded modules. I've looked at my
> >> > use-case and concluded
> >> > that most of the time I can work with "non-stable" PCs within a single
> >> > VM. Whenever I need to
> >> > store PCs persistently or send to another machine, I think I can
> >> > "canonicalize" PCs using
> >> > /proc/modules and /proc/kallsyms to something like (module hash,
> >> > module offset). So kernel does
> >> > not need to do this during coverage collection.
> >>
> >> On second though, maybe it's better to just always export unsigned long PCs...
> >> Need to measure how much memory coverage information consumes,
> >> and how much slower it is with uint64 PCs. Maybe I can live with large PCs,
> >> or maybe I can make syzkaller require !KASLR and compress PCs in user-space...
> >> Need to think about this more.
> >
> > I can imagine we might keep the expanded module range even in the
> > absence of full KASLR, though I don't know how realistic that thought
> > is.
> 
> The last version of the patch just exposes PCs as unsigned longs
> without any compression. So it should not be a problem (at least for
> kernel, now it's user responsibility to make sense out of the PCs).

Ah, ok. Sorry for the noise!

Mark.

  reply	other threads:[~2016-01-22 12:52 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-13 12:48 [PATCH v2] kernel: add kcov code coverage Dmitry Vyukov
2016-01-13 22:31 ` kbuild test robot
2016-01-14  9:03 ` Kirill A. Shutemov
2016-01-14  9:10   ` Dmitry Vyukov
2016-01-14  9:23     ` Kirill A. Shutemov
2016-01-14 12:21       ` Dmitry Vyukov
2016-01-14 12:35         ` Kirill A. Shutemov
2016-01-14 12:49         ` Kirill A. Shutemov
2016-01-14 14:24           ` Dmitry Vyukov
2016-01-14 10:50 ` Andrey Ryabinin
2016-01-14 14:30   ` Dmitry Vyukov
2016-01-15 13:05     ` Andrey Ryabinin
2016-01-15 13:05       ` Andrey Ryabinin
2016-01-15 13:42       ` Will Deacon
2016-01-15 13:42         ` Will Deacon
2016-01-15 14:07       ` Dmitry Vyukov
2016-01-15 14:07         ` Dmitry Vyukov
2016-01-18 13:34         ` Andrey Ryabinin
2016-01-18 13:34           ` Andrey Ryabinin
2016-01-18 19:31           ` Dmitry Vyukov
2016-01-18 19:31             ` Dmitry Vyukov
2016-01-18 14:13         ` Mark Rutland
2016-01-18 14:13           ` Mark Rutland
2016-01-18 19:44           ` Dmitry Vyukov
2016-01-18 19:44             ` Dmitry Vyukov
2016-01-18 20:09             ` Dmitry Vyukov
2016-01-18 20:09               ` Dmitry Vyukov
2016-01-22 11:55               ` Mark Rutland
2016-01-22 11:55                 ` Mark Rutland
2016-01-22 12:15                 ` Dmitry Vyukov
2016-01-22 12:15                   ` Dmitry Vyukov
2016-01-22 12:52                   ` Mark Rutland [this message]
2016-01-22 12:52                     ` Mark Rutland

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=20160122125210.GA10802@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.