In xen/arch/x86/x86_32/traps.c, if supervisor_mode_kernel is true, the hypercall_page will be initialized by hypercall_page_initialise_ring0_kernel. my question is, does supervisor_mode_kernel mean that the guest kernel is also running in ring0, the same privilege level as Xen hypervisor? The book "the definitive guide to the xen hypervisor" (in page 30) says hypercall through int82 is now deprecated, and replaced by hypercall_page. but int82 can still be found in hypercall_page_initialise_ring1_kernel. In what situation it will be used? Thanks. -Yanjun _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
pradeep singh rautela
2008-Oct-20 10:20 UTC
Re: [Xen-devel] supervisor_mode_kernel and hypercall
On Mon, Oct 20, 2008 at 3:44 PM, Yanjun Wu <yanjun.wu@gmail.com> wrote:> > In xen/arch/x86/x86_32/traps.c, if supervisor_mode_kernel is true, the > hypercall_page will be initialized by > hypercall_page_initialise_ring0_kernel. > my question is, does supervisor_mode_kernel mean that the guest kernel is > also running in ring0, the same privilege level as Xen hypervisor?Yes but in non-root mode. This is possible because some new hardware extensions added to x86 archtiture by Intel/AMD to facilitate virtualization.> The book "the definitive guide to the xen hypervisor" (in page 30) says > hypercall through int82 is now deprecated, and replaced by hypercall_page. > but int82 can still be found in hypercall_page_initialise_ring1_kernel. In > what situation it will be used?If the new method of hypercall invocation is not supported by the CPU. I think this should be similar to the way int 0x80 and SYSENTER/SYSEXIT are differentiated in linux kernel. HTH, Thanks, --Pradeep> > Thanks. > > -Yanjun > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > >-- Pradeep Singh Rautela http://eagain.wordpress.com http://emptydomain.googlepages.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 20/10/08 11:14, "Yanjun Wu" <yanjun.wu@gmail.com> wrote:> In xen/arch/x86/x86_32/traps.c, if supervisor_mode_kernel is true, the > hypercall_page will be initialized by hypercall_page_initialise_ring0_kernel. > my question is, does supervisor_mode_kernel mean that the guest kernel is also > running in ring0, the same privilege level as Xen hypervisor? > > The book "the definitive guide to the xen hypervisor" (in page 30) says > hypercall through int82 is now deprecated, and replaced by hypercall_page. > but int82 can still be found in hypercall_page_initialise_ring1_kernel. In > what situation it will be used?Yes, supervisor_mode_kernel means that the dom0 kernel runs in ring 0. It also means that other guests cannot be run. It¹s not really very useful these days. To your other question: guests are supposed to call into the hypervisor via the hypercall page, but actually the underlying mechanism is still int 0x82 for 32-bit PV guests. It¹s just hidden in the hypervisor-provided hypercall page now. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hello all, Similarly its mentioned in the same book that now fast system call handlers are used and control does not go to hypervisor.... Does it mean that there is no interception by the hypervisor at alll during system call??? You all must be wondering why do i wish to go to a method where system call would go to guest OS via hypervisor... But actually I am implementing a security system as a part of my project and i need this... Can anyone please help me more with it that is it possible in xen 3.x to make a system call be intercepted by hypervisor before going to guest kernel? Or do i need to switch to an older xen? Thanking you all, Furquan On 10/20/08, Yanjun Wu <yanjun.wu@gmail.com> wrote:> In xen/arch/x86/x86_32/traps.c, if supervisor_mode_kernel is true, the > hypercall_page will be initialized by > hypercall_page_initialise_ring0_kernel. > my question is, does supervisor_mode_kernel mean that the guest kernel is > also running in ring0, the same privilege level as Xen hypervisor? > > The book "the definitive guide to the xen hypervisor" (in page 30) says > hypercall through int82 is now deprecated, and replaced by hypercall_page. > but int82 can still be found in hypercall_page_initialise_ring1_kernel. In > what situation it will be used? > > Thanks. > > -Yanjun >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, As part of my research I''m trying to monitor how various LKM''s within a guest kernel interact with each other and the base kernel. For this and some other reasons I would like to set page permissions to non-executable depending on who''s code is running. I have a few areas I''m having difficulty with. I''d appreciate any help or pointers. I''m running a x86_64 HVM guest on Xen 3.2.2. For each LKM (guest kernel), I have a list of pages that belong to the LKM. I pass this information to Xen with the pfn''s of the pages. So in Xen context these should be gfn''s I guess. Is there an easy way to find the pte in the shadow page table associated with this guest page and modify it? Is there an easy way to tell whether a virtual address is in guest kernel or user space? It seems like guest_kernel_mode(v,r) in include/asm-x86/x86_64/regs.h is meant for PV guests and not for HVM. Is it possible to change permissions at lvl 2 page tables while keeping the lvl 1''s intact? Do the permissions propagate from lvl 2 to lvl 1? Finally, what''s the lowest level I can set permissions on? Does the hardware check for permissions at lvl 4 or lvl 3? Thanks in advance, John _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, At 17:38 -0400 on 20 Oct (1224524336), Emre Can Sezer wrote:> For each LKM (guest kernel), I have a list of pages that belong to the > LKM. I pass this information to Xen with the pfn''s of the pages. So in > Xen context these should be gfn''s I guess. Is there an easy way to find > the pte in the shadow page table associated with this guest page and > modify it?In general, no. The shadow code uses some heuristics to guess at the locations of PTEs for similar reasons but: - they are mostly based on the virtual address of a page fault; and - even if they work they only find _one_ such PTE. You would probably need to add some further mechanism for tracking these frames, because the fallback (brute-force search of all shadow L1 tables) is expensive. In addition, unless you modify the typecounting mechanism or add some other reference count, you can''t tell how many executable mappings there are (except that the total number of all mappings is an upper bound). Isn''t this something that could be done more easily inside the guest kernel, where you have more information available?> Is there an easy way to tell whether a virtual address is in guest kernel > or user space? It seems like guest_kernel_mode(v,r) in > include/asm-x86/x86_64/regs.h is meant for PV guests and not for HVM.guest_kernel_mode() doesn''t even take an address. :) The easiest way in the shadow code is probably to call guest_walk_tables() with a pfec argument of PFEC_page_present|PFEC_user_mode.> Is it possible to change permissions at lvl 2 page tables while keeping > the lvl 1''s intact? > > Do the permissions propagate from lvl 2 to lvl 1? > > Finally, what''s the lowest level I can set permissions on? Does the > hardware check for permissions at lvl 4 or lvl 3?Yes; yes; only in 64 bit mode. You should probably read the relevant bits of the Intel PRMs (vol 3A, chapters 3 and 4) or the AMD APMs (vol 2, chaper 5) before delving too deep into shadow pagetables. Cheers, Tim. -- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Citrix Systems (R&D) Ltd. [Company #02300071, SL9 0DZ, UK.] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Hi, > > At 17:38 -0400 on 20 Oct (1224524336), Emre Can Sezer wrote: >> For each LKM (guest kernel), I have a list of pages that belong to the >> LKM. I pass this information to Xen with the pfn''s of the pages. So in >> Xen context these should be gfn''s I guess. Is there an easy way to find >> the pte in the shadow page table associated with this guest page and >> modify it? > > In general, no. The shadow code uses some heuristics to guess at the > locations of PTEs for similar reasons but: > - they are mostly based on the virtual address of a page fault; and > - even if they work they only find _one_ such PTE. > You would probably need to add some further mechanism for tracking these > frames, because the fallback (brute-force search of all shadow L1 > tables) is expensive. > > In addition, unless you modify the typecounting mechanism or add some > other reference count, you can''t tell how many executable mappings there > are (except that the total number of all mappings is an upper bound).Ok, I see the problem. There can be many virtual addresses mapped to a page and we don''t have an easy way of finding all these mappings. The pages I''m dealing with are module code+data and some dynamically allocated memory regions (pages + caches). I''ll take a look at their ref count, which I think must be 2, one for the module and the other because the memory is also directly mapped from ffff810000000000. Hopefully, the modules aren''t doing anything crazy in terms of sharing pages.> > Isn''t this something that could be done more easily inside the guest > kernel, where you have more information available?I keep thinking that also but there are other things that I have to do in Xen so having everything on one side seemed like a better approach. I''m also trying to minimize the necessary changes to the guest side.> >> Is there an easy way to tell whether a virtual address is in guest >> kernel >> or user space? It seems like guest_kernel_mode(v,r) in >> include/asm-x86/x86_64/regs.h is meant for PV guests and not for HVM. > > guest_kernel_mode() doesn''t even take an address. :)DUH! Quite embarrassing :) I blame the late hour of 5pm.> The easiest way in > the shadow code is probably to call guest_walk_tables() with a pfec > argument of PFEC_page_present|PFEC_user_mode. > >> Is it possible to change permissions at lvl 2 page tables while keeping >> the lvl 1''s intact? >> >> Do the permissions propagate from lvl 2 to lvl 1? >> >> Finally, what''s the lowest level I can set permissions on? Does the >> hardware check for permissions at lvl 4 or lvl 3? > > Yes; yes; only in 64 bit mode. You should probably read the relevant > bits of the Intel PRMs (vol 3A, chapters 3 and 4) or the AMD APMs (vol > 2, chaper 5) before delving too deep into shadow pagetables.Thanks, John> > Cheers, > > Tim. > > -- > Tim Deegan <Tim.Deegan@citrix.com> > Principal Software Engineer, Citrix Systems (R&D) Ltd. > [Company #02300071, SL9 0DZ, UK.] >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel