From mboxrd@z Thu Jan 1 00:00:00 1970 From: Manish Jaggi Subject: Re: [RFC PATCH v2 13/22] xen/arm: its: Add virtual ITS command support Date: Wed, 29 Apr 2015 18:38:22 +0530 Message-ID: <5540D7C6.1030009@caviumnetworks.com> References: <1426775889-29442-1-git-send-email-vijay.kilari@gmail.com> <1426775889-29442-14-git-send-email-vijay.kilari@gmail.com> <55114EFA.9050304@linaro.org> <55197005.7090408@linaro.org> <1427888815.2115.279.camel@citrix.com> <551BDE4C.9030109@citrix.com> <1427966007.4037.14.camel@citrix.com> <551D2298.2060302@citrix.com> <1427973539.4037.52.camel@citrix.com> <551D4888.1020309@gmail.com> <553F6271.4010308@citrix.com> <553FB23F.7090200@citrix.com> <5540C6D 5.9020400@citrix.com> <5540CA9B.6020102@caviumnetworks.com> <5540CCB7.7050105@citrix.com> <5540CFA7.6080203@caviumnetworks.com> <5540D624.9030200@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5540D624.9030200@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Julien Grall , Vijay Kilari Cc: Ian Campbell , Stefano Stabellini , Prasun Kapoor , Vijaya Kumar K , Julien Grall , Tim Deegan , "xen-devel@lists.xen.org" , Stefano Stabellini , manish.jaggi@caviumnetworks.com List-Id: xen-devel@lists.xenproject.org On Wednesday 29 April 2015 06:31 PM, Julien Grall wrote: > On 29/04/15 13:33, Manish Jaggi wrote: >> On Wednesday 29 April 2015 05:51 PM, Julien Grall wrote: >>> On 29/04/15 13:12, Manish Jaggi wrote: >>>>>> and that too ITS is not in critical path. It is only used when >>>>>> configuring interrupts of the device? >>>>> You need to think about security... Even though the ITS should only >>>>> be used for configuring interrupts, a malicious guest could try to >>>>> exploit weakness in the emulation. >>>> Can you describe the scenario ? >>> I already wrote several times the possible security impacts of the >>> polling solution... Please read again the previous mails. >> I see your comment "The vITS emulates hardware for a specific domain. A >> malicious guest could send request to a not own device" >> This scenario cannot happen as guest sbdf is converted to physical sbdf >> based on the domain. So if it does not own a device it would be treated >> as invalid command. > Can you point the code in this patch series that implement what you > said? From what I read, you just forward the command to the physical ITS > as long as the guest called MAPD to the device. > >> Do you have any other security concern ? > Yes. The one we talked in every mail since the beginning of this thread > "polling in EL2". We got several XSA because the hypervisor code wasn't > preemptible (see [1]) > We are removing polling using command processing completion which is signalled using INT interrupt. > [1] http://xenbits.xen.org/xsa/advisory-97.html >