Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH v3 0/5] Add debugfs info for the AMD IOMMU
To:     Joerg Roedel <joro@8bytes.org>, Gary R Hook <gary.hook@amd.com>
Cc:     iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
References: <152106836233.67212.15861879210675477690.stgit@sosxen2.amd.com>
 <20180315135838.GB5259@8bytes.org>
From:   Gary R Hook <ghook@amd.com>
Message-ID: <29b998bf-c942-39e3-0e78-f1505492ac4b@amd.com>
Date:   Mon, 26 Mar 2018 18:33:41 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <20180315135838.GB5259@8bytes.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Received-SPF: None (protection.outlook.com: amd.com does not designate
 permitted sender hosts)
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Mar 2018 23:33:46.7869 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3ce765c2-6799-4b71-0d2d-08d5937205a7
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR12MB0698
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 03/15/2018 08:58 AM, Joerg Roedel wrote:
> On Wed, Mar 14, 2018 at 06:04:44PM -0500, Gary R Hook wrote:
>> Gary R Hook (5):
>>        iommu/amd - Add debugfs support
>>        iommu/amd - Add a 'verbose' switch for IOMMU debugfs
>>        iommu/amd - Add a README variable for the IOMMU debugfs
>>        iommu/amd - Expose the active IOMMU device table entries
>>        iommu/amd - Add a debugfs entry to specify a IOMMU device table entry
> 
> Same problem here as with the Intel patches, I don't think it's a good
> idea to reveal internal iommu data structures to user-space in this way.

I'm afraid I'm not following the line of thought here. AFAIK, if we 
restrict access of any debugfs info to root, then only root can see any 
of that information. If root is compromised, the whole system is 
compromised. Which seems to me to make all of debugfs suspect from a 
security perspective. Therefore, I'm likely not understanding the 
security concerns as they relate specifically to the IOMMU.

As for stability, you mention on the Intel IOMMU thread issues 
surrounding kABI, which I appreciate. But I'm exposing well-documented 
device structures in my patches, not kernel structures. There's nothing 
there that is going to change underneath me without my knowledge, if 
ever (I vote for never). And I'm likely ignorant about policy nuances 
surrounding the kernel ABI.

> I've debugged iommu issues for around 10 years now and never had the
> need for an interface that reveals those internals. How exactly are you
> planning to use this information?

Well, I've already had to dig into the DTEs and page tables for a couple 
of reasons (both debug and development), and it made life easier (for 
me) to make the live data available this way. Then I thought that others 
might be interested as well. Admittedly, I could be wrong.

Finally, I'm no guru, and likely am unaware of other techniques in which 
I should develop skills. I'm always open to input.