From: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
To: Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org>
Cc: Paul Gortmaker
<paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org>,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] drivers/iommu: don't select DEBUG_FS for AMD_IOMMU_STATS
Date: Wed, 6 Apr 2016 00:41:52 +0200 [thread overview]
Message-ID: <20160405224152.GK17838@8bytes.org> (raw)
In-Reply-To: <20160405123754.30786ede-2kNGR76GQU9OHLTnHDQRgA@public.gmane.org>
On Tue, Apr 05, 2016 at 12:37:54PM -0400, Steven Rostedt wrote:
> I will argue that people have asked me to move tracing out of debugfs
> (which is why I created tracefs) because the problem with debugfs is
> that it opens up a entire system that is not well scrutinized, and
> holds lots of possible ways to crack the kernel.
>
> Disabling debugfs does help with the "security" point you mentioned
> above.
Yes, that reasoning makes more sense than "debug features are bad for
production". It should've been part of the commit message.
The AMD_IOMMU_STATS feature is on my list of things to remove anyway, it
is mostly disabled and should be done differently (via per-device sysfs
stats). So I am just going to remove it for now.
Joerg
WARNING: multiple messages have this Message-ID (diff)
From: Joerg Roedel <joro@8bytes.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>,
linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org
Subject: Re: [PATCH] drivers/iommu: don't select DEBUG_FS for AMD_IOMMU_STATS
Date: Wed, 6 Apr 2016 00:41:52 +0200 [thread overview]
Message-ID: <20160405224152.GK17838@8bytes.org> (raw)
In-Reply-To: <20160405123754.30786ede@grimm.local.home>
On Tue, Apr 05, 2016 at 12:37:54PM -0400, Steven Rostedt wrote:
> I will argue that people have asked me to move tracing out of debugfs
> (which is why I created tracefs) because the problem with debugfs is
> that it opens up a entire system that is not well scrutinized, and
> holds lots of possible ways to crack the kernel.
>
> Disabling debugfs does help with the "security" point you mentioned
> above.
Yes, that reasoning makes more sense than "debug features are bad for
production". It should've been part of the commit message.
The AMD_IOMMU_STATS feature is on my list of things to remove anyway, it
is mostly disabled and should be done differently (via per-device sysfs
stats). So I am just going to remove it for now.
Joerg
next prev parent reply other threads:[~2016-04-05 22:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-27 1:18 [PATCH] drivers/iommu: don't select DEBUG_FS for AMD_IOMMU_STATS Paul Gortmaker
2016-03-27 1:18 ` Paul Gortmaker
[not found] ` <1459041524-30929-1-git-send-email-paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org>
2016-04-05 15:19 ` Joerg Roedel
2016-04-05 15:19 ` Joerg Roedel
2016-04-05 16:37 ` Steven Rostedt
[not found] ` <20160405123754.30786ede-2kNGR76GQU9OHLTnHDQRgA@public.gmane.org>
2016-04-05 22:41 ` Joerg Roedel [this message]
2016-04-05 22:41 ` Joerg Roedel
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=20160405224152.GK17838@8bytes.org \
--to=joro-zlv9swrftaidnm+yrofe0a@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org \
--cc=rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.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.