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:03:43 +0530 Message-ID: <5540CFA7.6080203@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5540CCB7.7050105@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 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. Do you have any other security concern ? > Regards,