linux-kernel - Re: [RFC v3 17/21] iommu/smmuv3: Report non recoverable faults

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <93599256-947f-d267-6b72-0759e17b4df1@redhat.com>
Date:   Wed, 16 Jan 2019 13:49:48 +0100
From:   Auger Eric <eric.auger@...hat.com>
To:     Jean-Philippe Brucker <jean-philippe.brucker@....com>,
        "eric.auger.pro@...il.com" <eric.auger.pro@...il.com>,
        "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "kvmarm@...ts.cs.columbia.edu" <kvmarm@...ts.cs.columbia.edu>,
        "joro@...tes.org" <joro@...tes.org>,
        "alex.williamson@...hat.com" <alex.williamson@...hat.com>,
        "jacob.jun.pan@...ux.intel.com" <jacob.jun.pan@...ux.intel.com>,
        "yi.l.liu@...ux.intel.com" <yi.l.liu@...ux.intel.com>,
        Will Deacon <Will.Deacon@....com>,
        Robin Murphy <Robin.Murphy@....com>
Cc:     Marc Zyngier <Marc.Zyngier@....com>,
        "peter.maydell@...aro.org" <peter.maydell@...aro.org>,
        "kevin.tian@...el.com" <kevin.tian@...el.com>,
        "ashok.raj@...el.com" <ashok.raj@...el.com>,
        Christoffer Dall <Christoffer.Dall@....com>
Subject: Re: [RFC v3 17/21] iommu/smmuv3: Report non recoverable faults

Hi Jean,

On 1/16/19 1:25 PM, Jean-Philippe Brucker wrote:
> On 15/01/2019 21:06, Auger Eric wrote:
>>>> +		iommu_report_device_fault(master->dev, &event);
>>>
>>> We should return here if the fault is successfully injected
>>
>> Even if the fault gets injected in the guest can't it be still useful to
>> get the message below on host side?
> 
> I don't think we should let the guest flood the host log by issuing
> invalid DMA (or are there other cases where the guest can freely print
> stuff in the host?) We do print all errors at the moment, but we should
> tighten this once there is an upstream solution to let the guest control
> DMA mappings.
OK thank you for the clarification. Yes it makes sense to skip those
traces then.

Thanks

Eric
> 
> Thanks,
> Jean
>