Hi Kevin. Thanks for your comment.
Please note that I listed these ideas for discussion.
I don't necessary have concreate implementation idea about them.
Some might be good, some might be bad.
On Tue, Mar 28, 2006 at 03:23:54PM +0800, Tian, Kevin wrote:
> >* grant table API proposal
> >The current grant table API depends on xen/x86 deeply.
> >There are four kind of addresses related to grant table.
> >user virtual address, kernel virtual address, pseudo physical address and
> >machine address.
> >xen/x86 grant table uses user virtual address, kernel virtual address and
> >machine address.
>
> If possible, I suggest you to use terms defined in include/public/xen.h from
> now on:
> Gpfn/gmfn/mfn/pfn,
> with clear explanation in head of that file. :-)
Thanks.
I should have used gpfn instead of pfn.
> Also XENFEAT_auto_translated_physmap is one mode you may be interested to
> take it as reference. Within that mode, gpfn equals to gmfn with p2m table
> managed
> by xen hypervisor, which is exactly like your case for ia64 dom0. Grant table
> has
> been changed a lot to accommodate that mode, and so do para-drivers.
>
> Yes, it's possible that ia64 dom0 may need more interface abstraction to make
> it
> working, but I think it would be easier/quicker/cleaner for you to reuse code
> path for
> that mode.
>
> >grant table mapping
> >grant_entry_t::frame should be architecture specific.
> > - xen/x86: mfn
> > - xen/IA64: pfn
>
> Then in this case:
> - Normal x86: gmfn (gmfn == mfn)
> - Translated x86/IA64: gmfn (gmfn != mfn)
>
> >define a arch-specific macro like virt_to_gnttab_mapaddr().
> >define a arch-specific function which allocates a mapping area.
>
> Since frame within grant table entry is gmfn and xen is aware whether this
> gmfn
> equals to mfn or not, there's no need to change concept of host_addr and you
> can
> just deliver a dummy va address.
I agree. I had a vague similar model in my mind.
You made it very clear.
I guess that grant table on translate x86 isn't supported yet, right?
> >* grant table read-only mapping
> >Current it is not implemented on xen/IA64 yet.
> >Xen/IA64 software address translation page table entry has unused bits.
> >In fact only present bit and ppn entry is only used. So other unused
> >bits can be used to record read-only.
> >Perhaps translate_domain_pte() needs modification.
>
> I assume you're talking about vTLB, instead of mTLB. vTLB entry may not be
> suitable
> to contain that information. Since the read-only limitation may be imposed to
> part of a
> large vTLB entry, then save read-only bit in large vTLB entry is incorrect.
>
> More important from your design, xenlinux will allocate virtual address to
> that shared
> frame later after grant table operation, and then grant table handler within
> Xen
> doesn't know which vTLB to record yet.
>
> How about record read-only property in the p2m table of that domain? Later
> when
> inserting entry into VHPT table and mTLB, p2m entry can be checked to set
> read-only
> flag.
I meant the P2M table by
'Xen/IA64 software address translation page table'
so that you and I reached the same conclusion.
> >- read only grant table mapping
> > When unmapping of read only grant table mapping, tlb won't be flushed.
> > A malicious domain might be able to read a unmapped page, but it
> > can't modify a page.
> > A granting domain must not use a granted page for important data.
>
> Just be curious about last sentence. :-) How do you define the "important"
> here? It
> may not be important to crash the granting domain, which however may reveal
> user
> "important" information since that page may keep content of files.
In fact I don't know. This was just an idea.
It seems that this idea isn't very good.
> >- trust privileged domains
> > Xen/IA64 trust privileged domain(dom0) to flush tlb cache.
>
> What do you mean by "trust"? Purge instruction still traps to xen since
> xenlinux is
> running as less privilege level. Maybe I didn't understand your point here.
When a granted page is unmapped or a page is disassociated
from pseudo physical address, xen/IA64 must flush tlb/VHPT.
Otherwise it might be possible for a malicious domain to read/write
the page using unflushed virtual address after the page is recyecled
and used for other purpose.
If we assume that dom0 isn't malicious so that it issues
appropriate tlb flush after unmapping/disassociating and doesn't read/write
a unmapped/disassociated page, then we can skip tlb/VHPT flush in xen/IA64
when unmapping/disassociating.
This is a trade-off between performance and security so this
should be the last one which is evaluated.
--
yamahata
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home