| Message ID | 50C5A747.1020105@linux.vnet.ibm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Dec 10, 2012 at 05:11:35PM +0800, Xiao Guangrong wrote: > Changelog: > There are some changes from Marcelo and Gleb's review, thank you all! > - access indirect_shadow_pages in the protection of mmu-lock > - fix the issue when unhandleable instruction access on large page > - add a new test case for large page > > The current reexecute_instruction can not well detect the failed instruction > emulation. It allows guest to retry all the instructions except it accesses > on error pfn. > > For example, these cases can not be detected: > - for tdp used > currently, it refused to retry all instructions. If nested npt is used, the > emulation may be caused by shadow page, it can be fixed by unshadow the > shadow page. > > - for shadow mmu > some cases are nested-write-protect, for example, if the page we want to > write is used as PDE but it chains to itself. Under this case, we should > stop the emulation and report the case to userspace. > > There are two test cases based on kvm-unit-test can trigger a infinite loop on > current code (ept = 0), after this patchset, it can report the error to Qemu. > > Subject: [PATCH] access test: test unhandleable instruction > > Test the instruction which can not be handled by kvm > > Signed-off-by: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com> Please submit the test for inclusion. There should be some way to make it fail.. program a timer interrupt and #GP? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/12/2012 07:36 AM, Marcelo Tosatti wrote: > On Mon, Dec 10, 2012 at 05:11:35PM +0800, Xiao Guangrong wrote: >> Changelog: >> There are some changes from Marcelo and Gleb's review, thank you all! >> - access indirect_shadow_pages in the protection of mmu-lock >> - fix the issue when unhandleable instruction access on large page >> - add a new test case for large page >> >> The current reexecute_instruction can not well detect the failed instruction >> emulation. It allows guest to retry all the instructions except it accesses >> on error pfn. >> >> For example, these cases can not be detected: >> - for tdp used >> currently, it refused to retry all instructions. If nested npt is used, the >> emulation may be caused by shadow page, it can be fixed by unshadow the >> shadow page. >> >> - for shadow mmu >> some cases are nested-write-protect, for example, if the page we want to >> write is used as PDE but it chains to itself. Under this case, we should >> stop the emulation and report the case to userspace. >> >> There are two test cases based on kvm-unit-test can trigger a infinite loop on >> current code (ept = 0), after this patchset, it can report the error to Qemu. >> >> Subject: [PATCH] access test: test unhandleable instruction >> >> Test the instruction which can not be handled by kvm >> >> Signed-off-by: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com> > > Please submit the test for inclusion. There should be some way to make > it fail.. Yes. But it is not easy. If the test cases run normally, kvm will report a error to Qemu then Qemu will exit the vcpu thread after dumping the vcpu state. We need to do something to let guest can be aware that the error report is triggered. I guess we can add a option in Qemu, say '-notify-guest' and allow Qemu to inject #GP to guest with a special ERROR_CODE if error is reported. > program a timer interrupt and #GP? Could you please explain the detail? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Dec 13, 2012 at 04:05:55AM +0800, Xiao Guangrong wrote: > On 12/12/2012 07:36 AM, Marcelo Tosatti wrote: > > On Mon, Dec 10, 2012 at 05:11:35PM +0800, Xiao Guangrong wrote: > >> Changelog: > >> There are some changes from Marcelo and Gleb's review, thank you all! > >> - access indirect_shadow_pages in the protection of mmu-lock > >> - fix the issue when unhandleable instruction access on large page > >> - add a new test case for large page > >> > >> The current reexecute_instruction can not well detect the failed instruction > >> emulation. It allows guest to retry all the instructions except it accesses > >> on error pfn. > >> > >> For example, these cases can not be detected: > >> - for tdp used > >> currently, it refused to retry all instructions. If nested npt is used, the > >> emulation may be caused by shadow page, it can be fixed by unshadow the > >> shadow page. > >> > >> - for shadow mmu > >> some cases are nested-write-protect, for example, if the page we want to > >> write is used as PDE but it chains to itself. Under this case, we should > >> stop the emulation and report the case to userspace. > >> > >> There are two test cases based on kvm-unit-test can trigger a infinite loop on > >> current code (ept = 0), after this patchset, it can report the error to Qemu. > >> > >> Subject: [PATCH] access test: test unhandleable instruction > >> > >> Test the instruction which can not be handled by kvm > >> > >> Signed-off-by: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com> > > > > Please submit the test for inclusion. There should be some way to make > > it fail.. > > Yes. > > But it is not easy. If the test cases run normally, kvm will report a error to Qemu > then Qemu will exit the vcpu thread after dumping the vcpu state. > > We need to do something to let guest can be aware that the error report is triggered. > I guess we can add a option in Qemu, say '-notify-guest' and allow Qemu to inject #GP > to guest with a special ERROR_CODE if error is reported. > > > program a timer interrupt and #GP? > > Could you please explain the detail? Before the instruction which writes continuously to the pagetable, arm say lapic timer. #GP on the interrupt handler and test with failure. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/14/2012 06:54 AM, Marcelo Tosatti wrote: > On Thu, Dec 13, 2012 at 04:05:55AM +0800, Xiao Guangrong wrote: >> On 12/12/2012 07:36 AM, Marcelo Tosatti wrote: >>> On Mon, Dec 10, 2012 at 05:11:35PM +0800, Xiao Guangrong wrote: >>>> Changelog: >>>> There are some changes from Marcelo and Gleb's review, thank you all! >>>> - access indirect_shadow_pages in the protection of mmu-lock >>>> - fix the issue when unhandleable instruction access on large page >>>> - add a new test case for large page >>>> >>>> The current reexecute_instruction can not well detect the failed instruction >>>> emulation. It allows guest to retry all the instructions except it accesses >>>> on error pfn. >>>> >>>> For example, these cases can not be detected: >>>> - for tdp used >>>> currently, it refused to retry all instructions. If nested npt is used, the >>>> emulation may be caused by shadow page, it can be fixed by unshadow the >>>> shadow page. >>>> >>>> - for shadow mmu >>>> some cases are nested-write-protect, for example, if the page we want to >>>> write is used as PDE but it chains to itself. Under this case, we should >>>> stop the emulation and report the case to userspace. >>>> >>>> There are two test cases based on kvm-unit-test can trigger a infinite loop on >>>> current code (ept = 0), after this patchset, it can report the error to Qemu. >>>> >>>> Subject: [PATCH] access test: test unhandleable instruction >>>> >>>> Test the instruction which can not be handled by kvm >>>> >>>> Signed-off-by: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com> >>> >>> Please submit the test for inclusion. There should be some way to make >>> it fail.. >> >> Yes. >> >> But it is not easy. If the test cases run normally, kvm will report a error to Qemu >> then Qemu will exit the vcpu thread after dumping the vcpu state. >> >> We need to do something to let guest can be aware that the error report is triggered. >> I guess we can add a option in Qemu, say '-notify-guest' and allow Qemu to inject #GP >> to guest with a special ERROR_CODE if error is reported. >> >>> program a timer interrupt and #GP? >> >> Could you please explain the detail? > > Before the instruction which writes continuously to the pagetable, arm > say lapic timer. #GP on the interrupt handler and test with failure. Sorry, I am confused about this. After Qemu exits due to KVM_EXIT_INTERNAL_ERROR, the vm is stopped then interrupt can not be injected to guest. Or i missed something? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Dec 14, 2012 at 12:50:09PM +0800, Xiao Guangrong wrote: > >>> program a timer interrupt and #GP? > >> > >> Could you please explain the detail? > > > > Before the instruction which writes continuously to the pagetable, arm > > say lapic timer. #GP on the interrupt handler and test with failure. > > Sorry, I am confused about this. After Qemu exits due to KVM_EXIT_INTERNAL_ERROR, > the vm is stopped then interrupt can not be injected to guest. Or i missed something? Yes, but without fixed kernel kvm-unit test executable loops continuously. Perhaps its more appropriate to fix generically, nevermind. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Dec 14, 2012 at 11:05:46PM -0200, Marcelo Tosatti wrote: > On Fri, Dec 14, 2012 at 12:50:09PM +0800, Xiao Guangrong wrote: > > >>> program a timer interrupt and #GP? > > >> > > >> Could you please explain the detail? > > > > > > Before the instruction which writes continuously to the pagetable, arm > > > say lapic timer. #GP on the interrupt handler and test with failure. > > > > Sorry, I am confused about this. After Qemu exits due to KVM_EXIT_INTERNAL_ERROR, > > the vm is stopped then interrupt can not be injected to guest. Or i missed something? > > Yes, but without fixed kernel kvm-unit test executable loops continuously. > Perhaps its more appropriate to fix generically, nevermind. This will not be the first test that makes kvm-unit-test hang on non fixed kernels. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/x86/access.c b/x86/access.c index 23a5995..9141c70 100644 --- a/x86/access.c +++ b/x86/access.c @@ -2,6 +2,7 @@ #include "libcflat.h" #include "desc.h" #include "processor.h" +#include "vm.h" #define smp_id() 0 @@ -739,6 +740,54 @@ err: return 0; } +static int check_retry_unhandleable_ins(ac_pool_t *pool) +{ + unsigned long mem = 30 * 1024 * 1024; + unsigned long esp; + ac_test_t at; + + ac_test_init(&at, (void *)(0x123406003000)); + at.flags[AC_PDE_PRESENT] = at.flags[AC_PDE_WRITABLE] = 1; + at.flags[AC_PTE_PRESENT] = at.flags[AC_PTE_WRITABLE] = 1; + at.flags[AC_CPU_CR0_WP] = 1; + + at.phys = mem; + ac_setup_specific_pages(&at, pool, mem, 0); + + asm volatile("mov %%rsp, %%rax \n\t" : "=a"(esp)); + asm volatile("mov %%rax, %%rsp \n\t" : : "a"(0x123406003000 + 0xf0)); + asm volatile ("int $0x3 \n\t"); + asm volatile("mov %%rax, %%rsp \n\t" : : "a"(esp)); + + return 1; +} + +static int check_large_mapping_write_page_table(ac_pool_t *pool) +{ + unsigned long mem = 0x1000000; + unsigned long esp; + ac_test_t at; + ulong cr3; + + ac_test_init(&at, (void *)(0x123400000000)); + at.flags[AC_PDE_PRESENT] = at.flags[AC_PDE_WRITABLE] = 1; + at.flags[AC_PDE_PSE] = 1; + at.flags[AC_CPU_CR0_WP] = 1; + + at.phys = mem; + ac_setup_specific_pages(&at, pool, mem, 0); + + cr3 = read_cr3(); + write_cr3(cr3); + + asm volatile("mov %%rsp, %%rax \n\t" : "=a"(esp)); + asm volatile("mov %%rax, %%rsp \n\t" : : "a"(0x123400000000 + 0x6f0)); + asm volatile ("int $0x3 \n\t"); + asm volatile("mov %%rax, %%rsp \n\t" : : "a"(esp)); + + return 1; +} + int ac_test_exec(ac_test_t *at, ac_pool_t *pool) { int r; @@ -756,7 +805,9 @@ const ac_test_fn ac_test_cases[] = { corrupt_hugepage_triger, check_pfec_on_prefetch_pte, - check_smep_andnot_wp + check_smep_andnot_wp, + check_retry_unhandleable_ins, + check_large_mapping_write_page_table }; int ac_test_run(void) @@ -770,6 +821,7 @@ int ac_test_run(void) tests = successes = 0; ac_env_int(&pool); ac_test_init(&at, (void *)(0x123400000000 + 16 * smp_id())); + do { if (at.flags[AC_CPU_CR4_SMEP] && (ptl2[2] & 0x4)) ptl2[2] -= 0x4;
Changelog: There are some changes from Marcelo and Gleb's review, thank you all! - access indirect_shadow_pages in the protection of mmu-lock - fix the issue when unhandleable instruction access on large page - add a new test case for large page The current reexecute_instruction can not well detect the failed instruction emulation. It allows guest to retry all the instructions except it accesses on error pfn. For example, these cases can not be detected: - for tdp used currently, it refused to retry all instructions. If nested npt is used, the emulation may be caused by shadow page, it can be fixed by unshadow the shadow page. - for shadow mmu some cases are nested-write-protect, for example, if the page we want to write is used as PDE but it chains to itself. Under this case, we should stop the emulation and report the case to userspace. There are two test cases based on kvm-unit-test can trigger a infinite loop on current code (ept = 0), after this patchset, it can report the error to Qemu. Subject: [PATCH] access test: test unhandleable instruction Test the instruction which can not be handled by kvm Signed-off-by: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com> --- x86/access.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 53 insertions(+), 1 deletions(-)