linux-kernel - Re: [PATCH v10 06/17] Xen: ARM: Add support for mapping platform device mmio

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: <57063752.4020805@arm.com>
Date:	Thu, 7 Apr 2016 11:32:50 +0100
From:	Julien Grall <julien.grall@....com>
To:	Shannon Zhao <zhaoshenglong@...wei.com>,
	Shannon Zhao <shannon.zhao@...aro.org>,
	linux-arm-kernel@...ts.infradead.org, sstabellini@...nel.org
Cc:	david.vrabel@...rix.com, devicetree@...r.kernel.org,
	linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org,
	catalin.marinas@....com, will.deacon@....com,
	peter.huangpeng@...wei.com, xen-devel@...ts.xen.org
Subject: Re: [PATCH v10 06/17] Xen: ARM: Add support for mapping platform
 device mmio

Hi Shannon,

On 07/04/16 02:37, Shannon Zhao wrote:
>
>
> On 2016/4/6 20:16, Julien Grall wrote:
>>> +            gpfns[j] = XEN_PFN_DOWN(r->start) + j;
>>> +            idxs[j] = XEN_PFN_DOWN(r->start) + j;
>>> +        }
>>> +
>>> +        xatp.domid = DOMID_SELF;
>>> +        xatp.size = nr;
>>> +        xatp.space = XENMAPSPACE_dev_mmio;
>>> +
>>> +        set_xen_guest_handle(xatp.gpfns, gpfns);
>>> +        set_xen_guest_handle(xatp.idxs, idxs);
>>> +        set_xen_guest_handle(xatp.errs, errs);
>>> +
>>> +        rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, &xatp);
>>> +        kfree(gpfns);
>>> +        kfree(idxs);
>>> +        kfree(errs);
>>> +        if (rc)
>>> +            return rc;
>>
>> Shouldn't we redo the mapping if the hypercall fails?
> Hmm, why? If it fails again when we redo the mapping, what should we do
> then? Redo again?

Because the device MMIO region is left half mapped in DOM0 address space.

After having another look to your patch, if an error occurs, the 
notifier will still return NOTIFY_OK. This will lead to random data 
abort when the driver is accessing the MMIO regions as the device will 
be considered fully functional.

However, even if the notifier return NOTIFY_BAD, the function device_add 
doesn't care about the return value of blocking_notifier_call_chain. I 
think this need to be fixed.

> I think if it fails at the first time it will always fail no matter how
> many times we do.

I was speaking about the mappings that succeeded. They will unlikely 
fail during removal. If they ever fail you can just ignore the error.

Regards,

-- 
Julien Grall