From: Kees Cook <keescook@chromium.org>
To: Alexander Popov <alex.popov@linux.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org, notify@kernel.org
Subject: Re: [PATCH v1 1/1] lkdtm/stackleak: Make the stack erasing test more verbose
Date: Thu, 2 Jan 2020 14:03:03 -0800 [thread overview]
Message-ID: <202001021402.EDBC5114D@keescook> (raw)
In-Reply-To: <aae20dfa-4a55-9aaf-d2f9-3c83ed905f2e@linux.com>
On Thu, Jan 02, 2020 at 02:26:39AM +0300, Alexander Popov wrote:
> On 31.12.2019 01:46, Kees Cook wrote:
> > On Tue, Dec 31, 2019 at 01:20:24AM +0300, Alexander Popov wrote:
> >> On 30.12.2019 21:37, Kees Cook wrote:
> >>> Hi! I try to keep the "success" conditions for LKDTM tests to be a
> >>> system exception, so doing "BUG" on a failure is actually against the
> >>> design. So, really, a test harness needs to know to check dmesg for the
> >>> results here. It almost looks like this check shouldn't live in LKDTM,
> >>> but since it feels like other LKDTM tests, I'm happy to keep it there
> >>> for now.
> >>
> >> Do you mean that you will apply this patch?
> >
> > Sorry for my confusing reply! I meant that I don't want to apply the
> > patch, but I'm find to leave the stackleak check in LKDTM.
>
> Kees, I think I see a solution.
>
> Would you agree if I use dump_stack() instead of BUG() in case of test failure?
> That would provide enough info for debugging and would NOT break your design.
I would be fine with that, yes! :)
--
Kees Cook
next prev parent reply other threads:[~2020-01-02 22:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-19 14:54 [PATCH v1 1/1] lkdtm/stackleak: Make the stack erasing test more verbose Alexander Popov
2019-12-28 20:20 ` Alexander Popov
2019-12-30 18:37 ` Kees Cook
2019-12-30 22:20 ` Alexander Popov
2019-12-30 22:46 ` Kees Cook
2020-01-01 23:26 ` Alexander Popov
2020-01-02 22:03 ` Kees Cook [this message]
2020-01-02 22:37 ` 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=202001021402.EDBC5114D@keescook \
--to=keescook@chromium.org \
--cc=alex.popov@linux.com \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=notify@kernel.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.