[PATCH 1/2] kvm: Insist on a reason when injecting a #GP into a guest

[PATCH 1/2] kvm: Insist on a reason when injecting a #GP into a guest

[Rusty Russell]

Insist on a reason when injecting a #GP into a guest

All places but one already do a printk before injecting a #GP: just
formalize it a little.

Signed-off-by: Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>

diff -r f75b0a5fc387 drivers/kvm/kvm_main.c
--- a/drivers/kvm/kvm_main.c	Mon Jul 23 11:16:12 2007 +1000
+++ b/drivers/kvm/kvm_main.c	Mon Jul 23 16:59:56 2007 +1000
@@ -419,8 +419,15 @@ static int kvm_vm_release(struct inode *
 	return 0;
 }
 
-static void inject_gp(struct kvm_vcpu *vcpu)
-{
+static void __attribute__((format(printf, 2, 3)))
+inject_gp(struct kvm_vcpu *vcpu, const char *why_fmt, ...)
+{
+	va_list args;
+
+	va_start(args, why_fmt);
+	printk(KERN_DEBUG "kvm: #GP ");
+	vprintk(why_fmt, args);
+	va_end(args);
 	kvm_arch_ops->inject_gp(vcpu, 0);
 }
 
@@ -464,22 +471,21 @@ void set_cr0(struct kvm_vcpu *vcpu, unsi
 void set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0)
 {
 	if (cr0 & CR0_RESERVED_BITS) {
-		printk(KERN_DEBUG "set_cr0: 0x%lx #GP, reserved bits 0x%lx\n",
-		       cr0, vcpu->cr0);
-		inject_gp(vcpu);
+		inject_gp(vcpu,
+			  "set_cr0: 0x%lx reserved bits 0x%lx\n",
+			  cr0, vcpu->cr0);
 		return;
 	}
 
 	if ((cr0 & X86_CR0_NW) && !(cr0 & X86_CR0_CD)) {
-		printk(KERN_DEBUG "set_cr0: #GP, CD == 0 && NW == 1\n");
-		inject_gp(vcpu);
+		inject_gp(vcpu,
+			  "set_cr0: CD == 0 && NW == 1\n");
 		return;
 	}
 
 	if ((cr0 & X86_CR0_PG) && !(cr0 & X86_CR0_PE)) {
-		printk(KERN_DEBUG "set_cr0: #GP, set PG flag "
-		       "and a clear PE flag\n");
-		inject_gp(vcpu);
+		inject_gp(vcpu,
+			  "set_cr0: set PG flag and a clear PE flag\n");
 		return;
 	}
 
@@ -489,25 +495,23 @@ void set_cr0(struct kvm_vcpu *vcpu, unsi
 			int cs_db, cs_l;
 
 			if (!is_pae(vcpu)) {
-				printk(KERN_DEBUG "set_cr0: #GP, start paging "
-				       "in long mode while PAE is disabled\n");
-				inject_gp(vcpu);
+				inject_gp(vcpu,
+					  "set_cr0: start paging in long"
+					  " mode while PAE is disabled\n");
 				return;
 			}
 			kvm_arch_ops->get_cs_db_l_bits(vcpu, &cs_db, &cs_l);
 			if (cs_l) {
-				printk(KERN_DEBUG "set_cr0: #GP, start paging "
-				       "in long mode while CS.L == 1\n");
-				inject_gp(vcpu);
+				inject_gp(vcpu,
+					  "set_cr0: start paging "
+					  "in long mode while CS.L == 1\n");
 				return;
 
 			}
 		} else
 #endif
 		if (is_pae(vcpu) && !load_pdptrs(vcpu, vcpu->cr3)) {
-			printk(KERN_DEBUG "set_cr0: #GP, pdptrs "
-			       "reserved bits\n");
-			inject_gp(vcpu);
+			inject_gp(vcpu, "set_cr0: pdptrs reserved bits\n");
 			return;
 		}
 
@@ -532,28 +536,24 @@ void set_cr4(struct kvm_vcpu *vcpu, unsi
 void set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
 {
 	if (cr4 & CR4_RESERVED_BITS) {
-		printk(KERN_DEBUG "set_cr4: #GP, reserved bits\n");
-		inject_gp(vcpu);
+		inject_gp(vcpu, "set_cr4: reserved bits\n");
 		return;
 	}
 
 	if (is_long_mode(vcpu)) {
 		if (!(cr4 & X86_CR4_PAE)) {
-			printk(KERN_DEBUG "set_cr4: #GP, clearing PAE while "
-			       "in long mode\n");
-			inject_gp(vcpu);
+			inject_gp(vcpu, "set_cr4: clearing PAE while "
+				  "in long mode\n");
 			return;
 		}
 	} else if (is_paging(vcpu) && !is_pae(vcpu) && (cr4 & X86_CR4_PAE)
 		   && !load_pdptrs(vcpu, vcpu->cr3)) {
-		printk(KERN_DEBUG "set_cr4: #GP, pdptrs reserved bits\n");
-		inject_gp(vcpu);
+		inject_gp(vcpu, "set_cr4: pdptrs reserved bits\n");
 		return;
 	}
 
 	if (cr4 & X86_CR4_VMXE) {
-		printk(KERN_DEBUG "set_cr4: #GP, setting VMXE\n");
-		inject_gp(vcpu);
+		inject_gp(vcpu, "set_cr4: setting VMXE\n");
 		return;
 	}
 	kvm_arch_ops->set_cr4(vcpu, cr4);
@@ -566,29 +566,24 @@ void set_cr3(struct kvm_vcpu *vcpu, unsi
 {
 	if (is_long_mode(vcpu)) {
 		if (cr3 & CR3_L_MODE_RESERVED_BITS) {
-			printk(KERN_DEBUG "set_cr3: #GP, reserved bits\n");
-			inject_gp(vcpu);
+			inject_gp(vcpu, "set_cr3: reserved bits\n");
 			return;
 		}
 	} else {
 		if (is_pae(vcpu)) {
 			if (cr3 & CR3_PAE_RESERVED_BITS) {
-				printk(KERN_DEBUG
-				       "set_cr3: #GP, reserved bits\n");
-				inject_gp(vcpu);
+				inject_gp(vcpu, "set_cr3: reserved bits\n");
 				return;
 			}
 			if (is_paging(vcpu) && !load_pdptrs(vcpu, cr3)) {
-				printk(KERN_DEBUG "set_cr3: #GP, pdptrs "
+				inject_gp(vcpu, "set_cr3: pdptrs "
 				       "reserved bits\n");
-				inject_gp(vcpu);
 				return;
 			}
 		} else {
 			if (cr3 & CR3_NONPAE_RESERVED_BITS) {
-				printk(KERN_DEBUG
-				       "set_cr3: #GP, reserved bits\n");
-				inject_gp(vcpu);
+				inject_gp(vcpu, "set_cr3: reserved bits\n");
+
 				return;
 			}
 		}
@@ -606,7 +601,7 @@ void set_cr3(struct kvm_vcpu *vcpu, unsi
 	 * to debug) behavior on the guest side.
 	 */
 	if (unlikely(!gfn_to_memslot(vcpu->kvm, cr3 >> PAGE_SHIFT)))
-		inject_gp(vcpu);
+		inject_gp(vcpu, "set_cr3: 0x%lx not valid guest phys", cr3);
 	else
 		vcpu->mmu.new_cr3(vcpu);
 	spin_unlock(&vcpu->kvm->lock);
@@ -616,8 +611,7 @@ void set_cr8(struct kvm_vcpu *vcpu, unsi
 void set_cr8(struct kvm_vcpu *vcpu, unsigned long cr8)
 {
 	if (cr8 & CR8_RESERVED_BITS) {
-		printk(KERN_DEBUG "set_cr8: #GP, reserved bits 0x%lx\n", cr8);
-		inject_gp(vcpu);
+		inject_gp(vcpu, "set_cr8: reserved bits 0x%lx\n", cr8);
 		return;
 	}
 	vcpu->cr8 = cr8;
@@ -1533,16 +1527,13 @@ static void set_efer(struct kvm_vcpu *vc
 static void set_efer(struct kvm_vcpu *vcpu, u64 efer)
 {
 	if (efer & EFER_RESERVED_BITS) {
-		printk(KERN_DEBUG "set_efer: 0x%llx #GP, reserved bits\n",
-		       efer);
-		inject_gp(vcpu);
+		inject_gp(vcpu, "set_efer: 0x%llx reserved bits\n", efer);
 		return;
 	}
 
 	if (is_paging(vcpu)
 	    && (vcpu->shadow_efer & EFER_LME) != (efer & EFER_LME)) {
-		printk(KERN_DEBUG "set_efer: #GP, change LME while paging\n");
-		inject_gp(vcpu);
+		inject_gp(vcpu, "set_efer: change LME while paging\n");
 		return;
 	}
 
@@ -1843,8 +1834,7 @@ int kvm_setup_pio(struct kvm_vcpu *vcpu,
 		/*
 		 * String I/O in reverse.  Yuck.  Kill the guest, fix later.
 		 */
-		printk(KERN_ERR "kvm: guest string pio down\n");
-		inject_gp(vcpu);
+		inject_gp(vcpu, "guest string pio down\n");
 		return 1;
 	}
 	vcpu->run->io.count = now;
@@ -1858,7 +1848,8 @@ int kvm_setup_pio(struct kvm_vcpu *vcpu,
 		vcpu->pio.guest_pages[i] = page;
 		spin_unlock(&vcpu->kvm->lock);
 		if (!page) {
-			inject_gp(vcpu);
+			inject_gp(vcpu, "pio: invalid address %#lx\n",
+				  address + i * PAGE_SIZE);
 			free_pio_guest_pages(vcpu);
 			return 1;
 		}



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[PATCH 2/2] kvm: pr_guest: don't let guest invoke printk() on host

[Rusty Russell]

If the guest can invoke a printk(), it can potentially flood the logs,
causing a host DoS.  We should also indicate *which* guest we're
talking about.

This patch adds pr_guest (analogous to pr_debug) which ratelimits.
Not all printk's were replaced: some are only printed once and others
should probably be replaced by BUG().  I removed the kvm_printf in
init_rmode_tss: it says nothing that the return value doesn't say.

Coders should be aware that printing in the logs is not particularly
useful except to give feedback to developers. ie. "should not be used
for chit-chat".

Signed-off-by: Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>

diff -r 3f158ee9df43 drivers/kvm/kvm.h
--- a/drivers/kvm/kvm.h	Tue Jul 24 16:22:39 2007 +1000
+++ b/drivers/kvm/kvm.h	Tue Jul 24 17:01:15 2007 +1000
@@ -503,8 +503,18 @@ struct kvm_arch_ops {
 
 extern struct kvm_arch_ops *kvm_arch_ops;
 
-#define kvm_printf(kvm, fmt ...) printk(KERN_DEBUG fmt)
-#define vcpu_printf(vcpu, fmt...) kvm_printf(vcpu->kvm, fmt)
+/* The guest did something wrong/strange.  Returns true if printed. */
+#define pr_guest(vcpu, fmt, ...)					\
+	({								\
+		int __r = 0;						\
+		if (printk_ratelimit()) {				\
+			printk(KERN_WARNING "kvm: %i: cpu%i " fmt,	\
+			       current->tgid, (vcpu)->vcpu_id		\
+			       , ## __VA_ARGS__);			\
+			__r = 1;					\
+		}							\
+		__r;							\
+	})
 
 int kvm_init_arch(struct kvm_arch_ops *ops, struct module *module);
 void kvm_exit_arch(void);
diff -r 3f158ee9df43 drivers/kvm/kvm_main.c
--- a/drivers/kvm/kvm_main.c	Tue Jul 24 16:22:39 2007 +1000
+++ b/drivers/kvm/kvm_main.c	Tue Jul 24 16:28:33 2007 +1000
@@ -425,8 +425,8 @@ inject_gp(struct kvm_vcpu *vcpu, const c
 	va_list args;
 
 	va_start(args, why_fmt);
-	printk(KERN_DEBUG "kvm: #GP ");
-	vprintk(why_fmt, args);
+	if (pr_guest(vcpu, "#GP "))
+		vprintk(why_fmt, args);
 	va_end(args);
 	kvm_arch_ops->inject_gp(vcpu, 0);
 }
@@ -995,8 +995,8 @@ static int emulator_write_std(unsigned l
 			      unsigned int bytes,
 			      struct x86_emulate_ctxt *ctxt)
 {
-	printk(KERN_ERR "emulator_write_std: addr %lx n %d\n",
-	       addr, bytes);
+	pr_guest(ctxt->vcpu,
+		 "emulator_write_std: addr %lx n %d\n", addr, bytes);
 	return X86EMUL_UNHANDLEABLE;
 }
 
@@ -1173,7 +1173,7 @@ int emulator_get_dr(struct x86_emulate_c
 		*dest = kvm_arch_ops->get_dr(vcpu, dr);
 		return X86EMUL_CONTINUE;
 	default:
-		printk(KERN_DEBUG "%s: unexpected dr %u\n",
+		pr_guest(vcpu, "%s: unexpected dr %u\n",
 		       __FUNCTION__, dr);
 		return X86EMUL_UNHANDLEABLE;
 	}
@@ -1386,7 +1386,7 @@ unsigned long realmode_get_cr(struct kvm
 	case 4:
 		return vcpu->cr4;
 	default:
-		vcpu_printf(vcpu, "%s: unexpected cr %u\n", __FUNCTION__, cr);
+		pr_guest(vcpu, "%s: unexpected cr %u\n", __FUNCTION__, cr);
 		return 0;
 	}
 }
@@ -1409,7 +1409,7 @@ void realmode_set_cr(struct kvm_vcpu *vc
 		set_cr4(vcpu, mk_cr_64(vcpu->cr4, val));
 		break;
 	default:
-		vcpu_printf(vcpu, "%s: unexpected cr %u\n", __FUNCTION__, cr);
+		pr_guest(vcpu, "%s: unexpected cr %u\n", __FUNCTION__, cr);
 	}
 }
 
@@ -1523,7 +1523,7 @@ int kvm_get_msr_common(struct kvm_vcpu *
 		break;
 #endif
 	default:
-		printk(KERN_ERR "kvm: unhandled rdmsr: 0x%x\n", msr);
+		pr_guest(vcpu, "unhandled rdmsr: 0x%x\n", msr);
 		return 1;
 	}
 	*pdata = data;
@@ -1575,11 +1575,11 @@ int kvm_set_msr_common(struct kvm_vcpu *
 		break;
 #endif
 	case MSR_IA32_MC0_STATUS:
-		printk(KERN_WARNING "%s: MSR_IA32_MC0_STATUS 0x%llx, nop\n",
+		pr_guest(vcpu, "%s: MSR_IA32_MC0_STATUS 0x%llx, nop\n",
 		       __FUNCTION__, data);
 		break;
 	case MSR_IA32_MCG_STATUS:
-		printk(KERN_WARNING "%s: MSR_IA32_MCG_STATUS 0x%llx, nop\n",
+		pr_guest(vcpu, "%s: MSR_IA32_MCG_STATUS 0x%llx, nop\n",
 			__FUNCTION__, data);
 		break;
 	case MSR_IA32_UCODE_REV:
@@ -1599,7 +1599,7 @@ int kvm_set_msr_common(struct kvm_vcpu *
 		return vcpu_register_para(vcpu, data);
 
 	default:
-		printk(KERN_ERR "kvm: unhandled wrmsr: 0x%x\n", msr);
+		pr_guest(vcpu, "unhandled wrmsr: 0x%x\n", msr);
 		return 1;
 	}
 	return 0;
@@ -1884,7 +1884,7 @@ int kvm_setup_pio(struct kvm_vcpu *vcpu,
 				ret = 1;
 		}
 	} else if (pio_dev)
-		printk(KERN_ERR "no string pio read support yet, "
+		pr_guest(vcpu, "no string pio read support yet, "
 		       "port %x size %d count %ld\n",
 			port, size, count);
 
diff -r 3f158ee9df43 drivers/kvm/svm.c
--- a/drivers/kvm/svm.c	Tue Jul 24 16:22:39 2007 +1000
+++ b/drivers/kvm/svm.c	Tue Jul 24 16:30:26 2007 +1000
@@ -229,11 +229,11 @@ static void skip_emulated_instruction(st
 static void skip_emulated_instruction(struct kvm_vcpu *vcpu)
 {
 	if (!vcpu->svm->next_rip) {
-		printk(KERN_DEBUG "%s: NOP\n", __FUNCTION__);
+		pr_guest(vcpu, "%s: NOP\n", __FUNCTION__);
 		return;
 	}
 	if (vcpu->svm->next_rip - vcpu->svm->vmcb->save.rip > 15) {
-		printk(KERN_ERR "%s: ip 0x%llx next 0x%llx\n",
+		pr_guest(vcpu, "%s: ip 0x%llx next 0x%llx\n",
 		       __FUNCTION__,
 		       vcpu->svm->vmcb->save.rip,
 		       vcpu->svm->next_rip);
@@ -889,7 +889,7 @@ static void svm_set_dr(struct kvm_vcpu *
 		return;
 	}
 	default:
-		printk(KERN_DEBUG "%s: unexpected dr %u\n",
+		pr_guest(vcpu, "%s: unexpected dr %u\n",
 		       __FUNCTION__, dr);
 		*exception = UD_VECTOR;
 		return;
@@ -930,7 +930,7 @@ static int pf_interception(struct kvm_vc
 		++vcpu->stat.mmio_exits;
 		return 0;
 	case EMULATE_FAIL:
-		vcpu_printf(vcpu, "%s: emulate fail\n", __FUNCTION__);
+		pr_guest(vcpu, "%s: emulate fail\n", __FUNCTION__);
 		break;
 	default:
 		BUG();
@@ -977,7 +977,7 @@ static int io_get_override(struct kvm_vc
 	rip += vcpu->svm->vmcb->save.cs.base;
 
 	if (ins_length > MAX_INST_SIZE)
-		printk(KERN_DEBUG
+		pr_guest(vcpu,
 		       "%s: inst length err, cs base 0x%llx rip 0x%llx "
 		       "next rip 0x%llx ins_length %u\n",
 		       __FUNCTION__,
@@ -1093,7 +1093,7 @@ static int io_interception(struct kvm_vc
 
 		addr_mask = io_adress(vcpu, in, &address);
 		if (!addr_mask) {
-			printk(KERN_DEBUG "%s: get io address failed\n",
+			pr_guest(vcpu, "%s: get io address failed\n",
 			       __FUNCTION__);
 			return 1;
 		}
@@ -1132,7 +1132,7 @@ static int invalid_op_interception(struc
 
 static int task_switch_interception(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
 {
-	printk(KERN_DEBUG "%s: task swiche is unsupported\n", __FUNCTION__);
+	pr_guest(vcpu, "%s: task swiche is unsupported\n", __FUNCTION__);
 	kvm_run->exit_reason = KVM_EXIT_UNKNOWN;
 	return 0;
 }
@@ -1147,7 +1147,7 @@ static int emulate_on_interception(struc
 static int emulate_on_interception(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
 {
 	if (emulate_instruction(vcpu, NULL, 0, 0) != EMULATE_DONE)
-		printk(KERN_ERR "%s: failed\n", __FUNCTION__);
+		pr_guest(vcpu, "%s: failed\n", __FUNCTION__);
 	return 1;
 }
 
diff -r 3f158ee9df43 drivers/kvm/vmx.c
--- a/drivers/kvm/vmx.c	Tue Jul 24 16:22:39 2007 +1000
+++ b/drivers/kvm/vmx.c	Tue Jul 24 16:22:51 2007 +1000
@@ -488,7 +488,7 @@ static void skip_emulated_instruction(st
 
 static void vmx_inject_gp(struct kvm_vcpu *vcpu, unsigned error_code)
 {
-	printk(KERN_DEBUG "inject_general_protection: rip 0x%lx\n",
+	pr_guest(vcpu, "inject_general_protection: rip 0x%lx\n",
 	       vmcs_readl(GUEST_RIP));
 	vmcs_write32(VM_ENTRY_EXCEPTION_ERROR_CODE, error_code);
 	vmcs_write32(VM_ENTRY_INTR_INFO_FIELD,
@@ -966,7 +966,7 @@ static void enter_lmode(struct kvm_vcpu 
 
 	guest_tr_ar = vmcs_read32(GUEST_TR_AR_BYTES);
 	if ((guest_tr_ar & AR_TYPE_MASK) != AR_TYPE_BUSY_64_TSS) {
-		printk(KERN_DEBUG "%s: tss fixup for long mode. \n",
+		pr_guest(vcpu, "%s: tss fixup for long mode.\n",
 		       __FUNCTION__);
 		vmcs_write32(GUEST_TR_AR_BYTES,
 			     (guest_tr_ar & ~AR_TYPE_MASK)
@@ -1188,10 +1188,8 @@ static int init_rmode_tss(struct kvm* kv
 	p2 = gfn_to_page(kvm, fn++);
 	p3 = gfn_to_page(kvm, fn);
 
-	if (!p1 || !p2 || !p3) {
-		kvm_printf(kvm,"%s: gfn_to_page failed\n", __FUNCTION__);
+	if (!p1 || !p2 || !p3)
 		return 0;
-	}
 
 	page = kmap_atomic(p1, KM_USER0);
 	clear_page(page);
@@ -1435,7 +1433,7 @@ static void inject_rmode_irq(struct kvm_
 	u32 ss_limit = vmcs_read32(GUEST_SS_LIMIT);
 
 	if (sp > ss_limit || sp < 6 ) {
-		vcpu_printf(vcpu, "%s: #SS, rsp 0x%lx ss 0x%lx limit 0x%x\n",
+		pr_guest(vcpu, "%s: #SS, rsp 0x%lx ss 0x%lx limit 0x%x\n",
 			    __FUNCTION__,
 			    vmcs_readl(GUEST_RSP),
 			    vmcs_readl(GUEST_SS_BASE),
@@ -1445,7 +1443,7 @@ static void inject_rmode_irq(struct kvm_
 
 	if (kvm_read_guest(vcpu, irq * sizeof(ent), sizeof(ent), &ent) !=
 								sizeof(ent)) {
-		vcpu_printf(vcpu, "%s: read guest err\n", __FUNCTION__);
+		pr_guest(vcpu, "%s: read guest err\n", __FUNCTION__);
 		return;
 	}
 
@@ -1457,7 +1455,7 @@ static void inject_rmode_irq(struct kvm_
 	if (kvm_write_guest(vcpu, ss_base + sp - 2, 2, &flags) != 2 ||
 	    kvm_write_guest(vcpu, ss_base + sp - 4, 2, &cs) != 2 ||
 	    kvm_write_guest(vcpu, ss_base + sp - 6, 2, &ip) != 2) {
-		vcpu_printf(vcpu, "%s: write guest err\n", __FUNCTION__);
+		pr_guest(vcpu, "%s: write guest err\n", __FUNCTION__);
 		return;
 	}
 
@@ -1612,7 +1610,7 @@ static int handle_exception(struct kvm_v
 			++vcpu->stat.mmio_exits;
 			return 0;
 		 case EMULATE_FAIL:
-			vcpu_printf(vcpu, "%s: emulate fail\n", __FUNCTION__);
+			pr_guest(vcpu, "%s: emulate fail\n", __FUNCTION__);
 			break;
 		default:
 			BUG();
@@ -1807,7 +1805,7 @@ static int handle_cr(struct kvm_vcpu *vc
 		break;
 	}
 	kvm_run->exit_reason = 0;
-	printk(KERN_ERR "kvm: unhandled control register: op %d cr %d\n",
+	pr_guest(vcpu, "unhandled control register: op %d cr %d\n",
 	       (int)(exit_qualification >> 4) & 3, cr);
 	return 0;
 }
@@ -2201,7 +2199,7 @@ static void vmx_inject_page_fault(struct
 	++vcpu->stat.pf_guest;
 
 	if (is_page_fault(vect_info)) {
-		printk(KERN_DEBUG "inject_page_fault: "
+		pr_guest(vcpu, "inject_page_fault: "
 		       "double fault 0x%lx @ 0x%lx\n",
 		       addr, vmcs_readl(GUEST_RIP));
 		vmcs_write32(VM_ENTRY_EXCEPTION_ERROR_CODE, 0);



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: [PATCH 1/2] kvm: Insist on a reason when injecting a #GP into a guest

[Avi Kivity]

Rusty Russell wrote:
> Insist on a reason when injecting a #GP into a guest
>
> All places but one already do a printk before injecting a #GP: just
> formalize it a little.
>
> Signed-off-by: Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
>
> diff -r f75b0a5fc387 drivers/kvm/kvm_main.c
> --- a/drivers/kvm/kvm_main.c	Mon Jul 23 11:16:12 2007 +1000
> +++ b/drivers/kvm/kvm_main.c	Mon Jul 23 16:59:56 2007 +1000
> @@ -419,8 +419,15 @@ static int kvm_vm_release(struct inode *
>  	return 0;
>  }
>  
> -static void inject_gp(struct kvm_vcpu *vcpu)
> -{
> +static void __attribute__((format(printf, 2, 3)))
> +inject_gp(struct kvm_vcpu *vcpu, const char *why_fmt, ...)
> +{
> +	va_list args;
> +
> +	va_start(args, why_fmt);
> +	printk(KERN_DEBUG "kvm: #GP ");
> +	vprintk(why_fmt, args);
> +	va_end(args);
>  	kvm_arch_ops->inject_gp(vcpu, 0);
>  }
>   

Some guests (non hardware accelerated hypervisors, mostly) will generate 
#gp.  We'll want to inject exceptions without noise then.  I don't think 
we have such an exception today, but it's an excuse to have a clean 
__inject_gp() and a varargs-infested inject_gp().

>  
> @@ -464,22 +471,21 @@ void set_cr0(struct kvm_vcpu *vcpu, unsi
>  void set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0)
>  {
>  	if (cr0 & CR0_RESERVED_BITS) {
> -		printk(KERN_DEBUG "set_cr0: 0x%lx #GP, reserved bits 0x%lx\n",
> -		       cr0, vcpu->cr0);
> -		inject_gp(vcpu);
> +		inject_gp(vcpu,
> +			  "set_cr0: 0x%lx reserved bits 0x%lx\n",
> +			  cr0, vcpu->cr0);
>   

Why three lines?

>  		return;
>  	}
>  
>  	if ((cr0 & X86_CR0_NW) && !(cr0 & X86_CR0_CD)) {
> -		printk(KERN_DEBUG "set_cr0: #GP, CD == 0 && NW == 1\n");
> -		inject_gp(vcpu);
> +		inject_gp(vcpu,
> +			  "set_cr0: CD == 0 && NW == 1\n");
>  		return;
>   

Are you deliberately ignoring an opportunity to reduce our line count?!

> @@ -1843,8 +1834,7 @@ int kvm_setup_pio(struct kvm_vcpu *vcpu,
>  		/*
>  		 * String I/O in reverse.  Yuck.  Kill the guest, fix later.
>  		 */
> -		printk(KERN_ERR "kvm: guest string pio down\n");
> -		inject_gp(vcpu);
> +		inject_gp(vcpu, "guest string pio down\n");
>  		return 1;
>  	}
>  	vcpu->run->io.count = now;
>   

This one really wants to be a KERN_ERR.  It's not a guest exception, 
it's a kvm unimplemented feature for which the guest pays the price.  I 
guess a good place for __inject_gp().

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: [PATCH 2/2] kvm: pr_guest: don't let guest invoke printk() on host

[Avi Kivity]

Rusty Russell wrote:
> If the guest can invoke a printk(), it can potentially flood the logs,
> causing a host DoS.  We should also indicate *which* guest we're
> talking about.
>
> This patch adds pr_guest (analogous to pr_debug) which ratelimits.
> Not all printk's were replaced: some are only printed once and others
> should probably be replaced by BUG().  I removed the kvm_printf in
> init_rmode_tss: it says nothing that the return value doesn't say.
>
> Coders should be aware that printing in the logs is not particularly
> useful except to give feedback to developers. ie. "should not be used
> for chit-chat".
>
>  int kvm_init_arch(struct kvm_arch_ops *ops, struct module *module);
>  void kvm_exit_arch(void);
> diff -r 3f158ee9df43 drivers/kvm/kvm_main.c
> --- a/drivers/kvm/kvm_main.c	Tue Jul 24 16:22:39 2007 +1000
> +++ b/drivers/kvm/kvm_main.c	Tue Jul 24 16:28:33 2007 +1000
> @@ -425,8 +425,8 @@ inject_gp(struct kvm_vcpu *vcpu, const c
>  	va_list args;
>  
>  	va_start(args, why_fmt);
> -	printk(KERN_DEBUG "kvm: #GP ");
> -	vprintk(why_fmt, args);
> +	if (pr_guest(vcpu, "#GP "))
> +		vprintk(why_fmt, args);
>  	va_end(args);
>  	kvm_arch_ops->inject_gp(vcpu, 0);
>  }
>   

Why go through this optimization?  If it happens frequently, we can just 
remove the printk().  The printk()s are mostly on not-expected-to-happen 
exceptions, and should just be removed if guests do exercise them.


-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: [PATCH 1/2] kvm: Insist on a reason when injecting a #GP into a guest

[Rusty Russell]

On Tue, 2007-07-24 at 13:15 +0300, Avi Kivity wrote:
> Rusty Russell wrote:
> > +static void __attribute__((format(printf, 2, 3)))
> > +inject_gp(struct kvm_vcpu *vcpu, const char *why_fmt, ...)
...
> >  	kvm_arch_ops->inject_gp(vcpu, 0);
> >  }
> >   
> 
> Some guests (non hardware accelerated hypervisors, mostly) will generate 
> #gp.  We'll want to inject exceptions without noise then.  I don't think 
> we have such an exception today, but it's an excuse to have a clean 
> __inject_gp() and a varargs-infested inject_gp().

I agree, except I never saw the point of a this wrapper anyway.  Is
there a good reason not to call kvm_arch_ops->inject_gp directly?

> > @@ -464,22 +471,21 @@ void set_cr0(struct kvm_vcpu *vcpu, unsi
> >  void set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0)
> >  {
> >  	if (cr0 & CR0_RESERVED_BITS) {
> > -		printk(KERN_DEBUG "set_cr0: 0x%lx #GP, reserved bits 0x%lx\n",
> > -		       cr0, vcpu->cr0);
> > -		inject_gp(vcpu);
> > +		inject_gp(vcpu,
> > +			  "set_cr0: 0x%lx reserved bits 0x%lx\n",
> > +			  cr0, vcpu->cr0);
> >   
> 
> Why three lines?

Erk, I deleted the #GP from these messages later.  Will fix.

> > -		printk(KERN_ERR "kvm: guest string pio down\n");
> > -		inject_gp(vcpu);
> > +		inject_gp(vcpu, "guest string pio down\n");
> >  		return 1;
> >  	}
> >  	vcpu->run->io.count = now;
> 
> This one really wants to be a KERN_ERR.  It's not a guest exception, 
> it's a kvm unimplemented feature for which the guest pays the price.  I 
> guess a good place for __inject_gp().

Good point, by itself this patch is bad.  See 2/2.

Thanks,
Rusty.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: [PATCH 1/2] kvm: Insist on a reason when injecting a #GP into a guest

[Avi Kivity]

Rusty Russell wrote:
> On Tue, 2007-07-24 at 13:15 +0300, Avi Kivity wrote:
>   
>> Rusty Russell wrote:
>>     
>>> +static void __attribute__((format(printf, 2, 3)))
>>> +inject_gp(struct kvm_vcpu *vcpu, const char *why_fmt, ...)
>>>       
> ...
>   
>>>  	kvm_arch_ops->inject_gp(vcpu, 0);
>>>  }
>>>   
>>>       
>> Some guests (non hardware accelerated hypervisors, mostly) will generate 
>> #gp.  We'll want to inject exceptions without noise then.  I don't think 
>> we have such an exception today, but it's an excuse to have a clean 
>> __inject_gp() and a varargs-infested inject_gp().
>>     
>
> I agree, except I never saw the point of a this wrapper anyway.  Is
> there a good reason not to call kvm_arch_ops->inject_gp directly?
>
>   

No.

>>> @@ -464,22 +471,21 @@ void set_cr0(struct kvm_vcpu *vcpu, unsi
>>>  void set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0)
>>>  {
>>>  	if (cr0 & CR0_RESERVED_BITS) {
>>> -		printk(KERN_DEBUG "set_cr0: 0x%lx #GP, reserved bits 0x%lx\n",
>>> -		       cr0, vcpu->cr0);
>>> -		inject_gp(vcpu);
>>> +		inject_gp(vcpu,
>>> +			  "set_cr0: 0x%lx reserved bits 0x%lx\n",
>>> +			  cr0, vcpu->cr0);
>>>   
>>>       
>> Why three lines?
>>     
>
> Erk, I deleted the #GP from these messages later.  Will fix.
>
>   

No, inject_gp() adds that.



-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: [PATCH 2/2] kvm: pr_guest: don't let guest invoke printk() on host

[Rusty Russell]

On Tue, 2007-07-24 at 13:19 +0300, Avi Kivity wrote:
> Rusty Russell wrote:
> > diff -r 3f158ee9df43 drivers/kvm/kvm_main.c
> > --- a/drivers/kvm/kvm_main.c	Tue Jul 24 16:22:39 2007 +1000
> > +++ b/drivers/kvm/kvm_main.c	Tue Jul 24 16:28:33 2007 +1000
> > @@ -425,8 +425,8 @@ inject_gp(struct kvm_vcpu *vcpu, const c
> >  	va_list args;
> >  
> >  	va_start(args, why_fmt);
> > -	printk(KERN_DEBUG "kvm: #GP ");
> > -	vprintk(why_fmt, args);
> > +	if (pr_guest(vcpu, "#GP "))
> > +		vprintk(why_fmt, args);
> >  	va_end(args);
> >  	kvm_arch_ops->inject_gp(vcpu, 0);
> >  }
> >   
> 
> Why go through this optimization?  If it happens frequently, we can just 
> remove the printk().  The printk()s are mostly on not-expected-to-happen 
> exceptions, and should just be removed if guests do exercise them.

It's not an optimization, just being thorough.  It raises it to
KERN_WARN and makes it a common format.  Importantly there should be no
unlimited printks which can be triggered by the guest.

KVM *will* be used to run malicious guests.  That's going to be hard to
lock down later, so I figure we should start now.

Thanks,
Rusty.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: [PATCH 2/2] kvm: pr_guest: don't let guest invoke printk() on host

[Avi Kivity]

Rusty Russell wrote:
> On Tue, 2007-07-24 at 13:19 +0300, Avi Kivity wrote:
>   
>> Rusty Russell wrote:
>>     
>>> diff -r 3f158ee9df43 drivers/kvm/kvm_main.c
>>> --- a/drivers/kvm/kvm_main.c	Tue Jul 24 16:22:39 2007 +1000
>>> +++ b/drivers/kvm/kvm_main.c	Tue Jul 24 16:28:33 2007 +1000
>>> @@ -425,8 +425,8 @@ inject_gp(struct kvm_vcpu *vcpu, const c
>>>  	va_list args;
>>>  
>>>  	va_start(args, why_fmt);
>>> -	printk(KERN_DEBUG "kvm: #GP ");
>>> -	vprintk(why_fmt, args);
>>> +	if (pr_guest(vcpu, "#GP "))
>>> +		vprintk(why_fmt, args);
>>>  	va_end(args);
>>>  	kvm_arch_ops->inject_gp(vcpu, 0);
>>>  }
>>>   
>>>       
>> Why go through this optimization?  If it happens frequently, we can just 
>> remove the printk().  The printk()s are mostly on not-expected-to-happen 
>> exceptions, and should just be removed if guests do exercise them.
>>     
>
> It's not an optimization, just being thorough.  It raises it to
> KERN_WARN and makes it a common format.  Importantly there should be no
> unlimited printks which can be triggered by the guest.
>
> KVM *will* be used to run malicious guests.  That's going to be hard to
> lock down later, so I figure we should start now.

There's no reason to make this KERN_WARN.  There's nothing wrong with 
the host, and there may not be anything wrong with the guest.  These are 
only used to see if the guest did something unexpected, which may or may 
not be a problem (a kvm test suite would certainly trigger them).

Perhaps we should make them conditional on a debug flag, or remove them 
completely.  Most of them don't ever trigger, and i don't expect we can 
bring up a new guest solely using these printks.


-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: [PATCH 2/2] kvm: pr_guest: don't let guest invoke printk() on host

[Rusty Russell]

On Tue, 2007-07-24 at 14:01 +0300, Avi Kivity wrote:
> Rusty Russell wrote:
> > KVM *will* be used to run malicious guests.  That's going to be hard to
> > lock down later, so I figure we should start now.
> 
> There's no reason to make this KERN_WARN.  There's nothing wrong with 
> the host, and there may not be anything wrong with the guest.  These are 
> only used to see if the guest did something unexpected, which may or may 
> not be a problem (a kvm test suite would certainly trigger them).
> 
> Perhaps we should make them conditional on a debug flag, or remove them 
> completely.  Most of them don't ever trigger, and i don't expect we can 
> bring up a new guest solely using these printks.

So should there be two routines?  pr_unimpl() (KERN_ERR) and
pr_unexpected() (KERN_DEBUG) maybe.  Both ratelimited, with nice
formatting to tell user which machine & cpu for reporting when there's a
problem...

Turning them off is your call: have they proven useful?

Thanks,
Rusty.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: [PATCH 2/2] kvm: pr_guest: don't let guest invoke printk() on host

[Avi Kivity]

Rusty Russell wrote:
> On Tue, 2007-07-24 at 14:01 +0300, Avi Kivity wrote:
>   
>> Rusty Russell wrote:
>>     
>>> KVM *will* be used to run malicious guests.  That's going to be hard to
>>> lock down later, so I figure we should start now.
>>>       
>> There's no reason to make this KERN_WARN.  There's nothing wrong with 
>> the host, and there may not be anything wrong with the guest.  These are 
>> only used to see if the guest did something unexpected, which may or may 
>> not be a problem (a kvm test suite would certainly trigger them).
>>
>> Perhaps we should make them conditional on a debug flag, or remove them 
>> completely.  Most of them don't ever trigger, and i don't expect we can 
>> bring up a new guest solely using these printks.
>>     
>
> So should there be two routines?  pr_unimpl() (KERN_ERR) and
> pr_unexpected() (KERN_DEBUG) maybe.  Both ratelimited, with nice
> formatting to tell user which machine & cpu for reporting when there's a
> problem...
>
> Turning them off is your call: have they proven useful?
>   

Unimplemented has certainly proven useful, mostly with msrs (which we 
implement on demand).

The unexpected ones are usually badly implemented (as you discovered 
with the set_cr4() bug), so if something goes wrong and they show up, 
that's a hint.  However, that was useful during initial bringup, and 
these things don't happen anymore, so it's probably better to remove 
them than to introduce a new kernel subsystem after a 400-message thread 
on kvm-devel.  They don't rhyme anyway.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: [PATCH 2/2] kvm: pr_guest: don't let guest invoke printk() on host

[Rusty Russell]

On Tue, 2007-07-24 at 15:19 +0300, Avi Kivity wrote:
> They don't rhyme anyway.

Let's NOT start that here.

Is this patch now clear?  It's less ambitious I fear. 

Cheer,
Rusty.
===
Add and use pr_unimpl for standard formatting of unimplemented features.

All guest-invokable printks should be ratelimited to prevent malicious
guests from flooding logs.  This is a start.

Signed-off-by: Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>

diff -r 5266830ac99d drivers/kvm/kvm.h
--- a/drivers/kvm/kvm.h	Tue Jul 24 16:22:15 2007 +1000
+++ b/drivers/kvm/kvm.h	Wed Jul 25 09:52:33 2007 +1000
@@ -503,6 +503,14 @@ struct kvm_arch_ops {
 
 extern struct kvm_arch_ops *kvm_arch_ops;
 
+/* The guest did something we don't support. */
+#define pr_unimpl(vcpu, fmt, ...)					\
+ do {									\
+	if (printk_ratelimit())						\
+		printk(KERN_ERR "kvm: %i: cpu%i " fmt,			\
+		       current->tgid, (vcpu)->vcpu_id , ## __VA_ARGS__); \
+ } while(0)
+
 #define kvm_printf(kvm, fmt ...) printk(KERN_DEBUG fmt)
 #define vcpu_printf(vcpu, fmt...) kvm_printf(vcpu->kvm, fmt)
 
diff -r 5266830ac99d drivers/kvm/kvm_main.c
--- a/drivers/kvm/kvm_main.c	Tue Jul 24 16:22:15 2007 +1000
+++ b/drivers/kvm/kvm_main.c	Wed Jul 25 09:55:26 2007 +1000
@@ -1001,8 +1001,8 @@ static int emulator_write_std(unsigned l
 			      unsigned int bytes,
 			      struct x86_emulate_ctxt *ctxt)
 {
-	printk(KERN_ERR "emulator_write_std: addr %lx n %d\n",
-	       addr, bytes);
+	pr_unimpl(ctxt->vcpu, "emulator_write_std: addr %lx n %d\n",
+		  addr, bytes);
 	return X86EMUL_UNHANDLEABLE;
 }
 
@@ -1529,7 +1529,7 @@ int kvm_get_msr_common(struct kvm_vcpu *
 		break;
 #endif
 	default:
-		printk(KERN_ERR "kvm: unhandled rdmsr: 0x%x\n", msr);
+		pr_unimpl(vcpu, "unhandled rdmsr: 0x%x\n", msr);
 		return 1;
 	}
 	*pdata = data;
@@ -1608,7 +1608,7 @@ int kvm_set_msr_common(struct kvm_vcpu *
 		return vcpu_register_para(vcpu, data);
 
 	default:
-		printk(KERN_ERR "kvm: unhandled wrmsr: 0x%x\n", msr);
+		pr_unimpl(vcpu, "unhandled wrmsr: 0x%x\n", msr);
 		return 1;
 	}
 	return 0;
@@ -1862,7 +1862,7 @@ int kvm_setup_pio(struct kvm_vcpu *vcpu,
 		/*
 		 * String I/O in reverse.  Yuck.  Kill the guest, fix later.
 		 */
-		printk(KERN_ERR "kvm: guest string pio down\n");
+		pr_unimpl(vcpu, "guest string pio down\n");
 		inject_gp(vcpu);
 		return 1;
 	}
@@ -1893,7 +1893,7 @@ int kvm_setup_pio(struct kvm_vcpu *vcpu,
 				ret = 1;
 		}
 	} else if (pio_dev)
-		printk(KERN_ERR "no string pio read support yet, "
+		pr_unimpl(vcpu, "no string pio read support yet, "
 		       "port %x size %d count %ld\n",
 			port, size, count);
 
diff -r 5266830ac99d drivers/kvm/svm.c
--- a/drivers/kvm/svm.c	Tue Jul 24 16:22:15 2007 +1000
+++ b/drivers/kvm/svm.c	Wed Jul 25 10:16:11 2007 +1000
@@ -1132,7 +1132,7 @@ static int invalid_op_interception(struc
 
 static int task_switch_interception(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
 {
-	printk(KERN_DEBUG "%s: task swiche is unsupported\n", __FUNCTION__);
+	pr_unimpl(vcpu, "%s: task swiche is unsupported\n", __FUNCTION__);
 	kvm_run->exit_reason = KVM_EXIT_UNKNOWN;
 	return 0;
 }
diff -r 5266830ac99d drivers/kvm/vmx.c
--- a/drivers/kvm/vmx.c	Tue Jul 24 16:22:15 2007 +1000
+++ b/drivers/kvm/vmx.c	Wed Jul 25 09:59:50 2007 +1000
@@ -1807,7 +1807,7 @@ static int handle_cr(struct kvm_vcpu *vc
 		break;
 	}
 	kvm_run->exit_reason = 0;
-	printk(KERN_ERR "kvm: unhandled control register: op %d cr %d\n",
+	pr_unimpl(vcpu, "unhandled control register: op %d cr %d\n",
 	       (int)(exit_qualification >> 4) & 3, cr);
 	return 0;
 }




-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: [PATCH 2/2] kvm: pr_guest: don't let guest invoke printk() on host

[Avi Kivity]

Rusty Russell wrote:
> On Tue, 2007-07-24 at 15:19 +0300, Avi Kivity wrote:
>   
>> They don't rhyme anyway.
>>     
>
> Let's NOT start that here.
>
> Is this patch now clear?  It's less ambitious I fear. 
>
>   

Patch applied, Rusty dear.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

Re: [PATCH 2/2] kvm: pr_guest: don't let guest invoke printk() on host

[Avi Kivity]

Avi Kivity wrote:
> Rusty Russell wrote:
>   
>> On Tue, 2007-07-24 at 15:19 +0300, Avi Kivity wrote:
>>   
>>     
>>> They don't rhyme anyway.
>>>     
>>>       
>> Let's NOT start that here.
>>
>> Is this patch now clear?  It's less ambitious I fear. 
>>
>>   
>>     
>
> Patch applied, Rusty dear.
>
>   
printk: 203734 messages suppressed.  And so is this patch.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/