[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] Changing semantics of ioperm() on Xen x86-64?


  • To: "Anthony Liguori" <aliguori@xxxxxxxxxx>, "xen-devel" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
  • Date: Tue, 18 Apr 2006 23:53:39 +0100
  • Delivery-date: Tue, 18 Apr 2006 15:53:56 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcZjMjq8c7PeCN7aQMq6c5cylp+PZwACCsxQ
  • Thread-topic: [Xen-devel] Changing semantics of ioperm() on Xen x86-64?

> As part of the Xen x86-64 Linux port, we've changed the 
> ioperm() syscall to always modify the IOPL instead of 
> actually modifying the IO bitmap in the TSS like we do on 
> x86-32.  Is there a particular reason for doing this?

I don't believe so. io bitmap support was added to the hypervisor and
the corresponding ioperm support got added on i386, but was never
carried across to x86_64.

We would definitely benefit from someone doing a code review of x86_64
with a view to unifying as many of the xen patches with i386 as
possible. There's certainly some needless/unhelpful divergence.

Ian 
 
> I'm completely guessing here that this may allow us to avoid 
> changing the TR when changing from user/kernel mode but that 
> doesn't seem like that huge of a gain.
> 
> I don't expect that there are many apps that would rely on 
> using ioperm to restrict access to only certain ranges of 
> ports so I don't think this is a security problem but it 
> still is a little discomforting.
> 
> Comments?
> 
> Regards,
> 
> Anthony Liguori
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.