[Qemu-devel] [resent] [Patch] darwin-user: revert host_info patch and don't fail if sysctl is unknown when we are on the same host/target

2007-02-22 Thread Pierre d'Herbemont

Hi,

This fix x86-on-x86 and ppc-on-ppc.

Pierre.

ChangeLog:
Revert host_info changes and don't fail if sysctl is unknown when we  
are on the same host/target.


Index: darwin-user/syscall.c
===
RCS file: /sources/qemu/qemu/darwin-user/syscall.c,v
retrieving revision 1.2
diff -u -r1.2 syscall.c
--- darwin-user/syscall.c   5 Feb 2007 19:47:42 -   1.2
+++ darwin-user/syscall.c   16 Feb 2007 09:36:54 -
@@ -367,7 +367,14 @@
 case 200: /* host_info */
 {
 mig_reply_error_t *err = (mig_reply_error_t *)hdr;
-struct host_basic_info *data = (void *)(err+1);
+struct {
+uint32_t unknow1;
+uint32_t max_cpus;
+uint32_t avail_cpus;
+uint32_t memory_size;
+uint32_t cpu_type;
+uint32_t cpu_subtype;
+} *data = (void *)(err+1);
 
 DPRINTF(maxcpu = 0x%x\n,   data-max_cpus);
 DPRINTF(numcpu = 0x%x\n,   data-avail_cpus);
@@ -1342,9 +1349,12 @@
 if(name) /* Sometimes sysctl is called with no arg1, ignore */
 ret = get_errno(sysctl(name, namelen, oldp, oldlenp, newp, newlen));
 
+#if defined(TARGET_I386) ^ defined(__i386__) || defined(TARGET_PPC) ^ 
defined(__ppc__)
 if (!is_error(ret)  bswap_syctl(name, namelen, oldp, *oldlenp) != 0) {
 return -ENOTDIR;
 }
+#endif
+
 if(name) {
 //bswap_syctl(name, namelen, newp, newlen);
 tswap32s((uint32_t*)oldlenp);
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] QEMU: VNC

2007-02-22 Thread Johannes Schindelin
Hi,

On Thu, 22 Feb 2007, Luke-Jr wrote:

 Is there a reason to not use the semi-standard -rfbauth filename 
 argument?

Yes. The authentication is not really secure. It only uses 16 bits if I 
remember correctly, so even without access to filename, it can be easily 
broken.

The common practice is to block after 3 attempts, but there are ways 
around that, too.

Ciao,
Dscho



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] QEMU: VNC

2007-02-22 Thread Anthony Liguori

Johannes Schindelin wrote:

Hi,

On Thu, 22 Feb 2007, Luke-Jr wrote:

  
Is there a reason to not use the semi-standard -rfbauth filename 
argument?


I would be happy with a patch that allowed a password to be set from the 
monitor.  Storing a password in a file on disk is, IMHO, ugly.  If no 
one beats me to it, I'll probably write something up this weekend.


Yes. The authentication is not really secure. It only uses 16 bits if I 
remember correctly, so even without access to filename, it can be easily 
broken.


The common practice is to block after 3 attempts, but there are ways 
around that, too.



RFB authentication is not secure for a few reasons.  The first is that 
passwords are limited to 8 characters and constant padding for passwords 
shorter than 8.  Furthermore, the challenge/response mechanism is prone 
to man-in-the-middle attacks and replay attacks.  Triple DES is not a 
very good encryption method either by modern standards.


For all practical purposes, it's a plain-text equivalent authentication 
mechanism.  However, it's widely supported, and provides a useful 
feature so it's worth supporting.


For real security, TLS integration is most certainly the way to go.  I 
want to make sure anything we do though doesn't violate the RFB spec so 
we have to validate the the authentication ids are reserved and the 
protocol isn't violated in anyway (realizing there's no absolutely 
secure way to do RFB and still be compatible to the spec).


Regards,

Anthony Liguori


Ciao,
Dscho



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel






___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


RE: [Qemu-devel] QEMU: VNC

2007-02-22 Thread Christopher Olsen
Anthony,

I have a patch to do the vnc standard challenge-reponse method.. With the
pass passed in as a flag (for now)

-Christopher



Christopher Olsen
88B Toledo Street
Farmingdale, NY 11735




-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Behalf Of Anthony Liguori
Sent: Thursday, February 22, 2007 11:36 AM
To: qemu-devel@nongnu.org
Cc: Luke-Jr
Subject: Re: [Qemu-devel] QEMU: VNC


Johannes Schindelin wrote:
 Hi,

 On Thu, 22 Feb 2007, Luke-Jr wrote:


 Is there a reason to not use the semi-standard -rfbauth filename
 argument?

I would be happy with a patch that allowed a password to be set from the
monitor.  Storing a password in a file on disk is, IMHO, ugly.  If no
one beats me to it, I'll probably write something up this weekend.

 Yes. The authentication is not really secure. It only uses 16 bits if I
 remember correctly, so even without access to filename, it can be
easily
 broken.

 The common practice is to block after 3 attempts, but there are ways
 around that, too.


RFB authentication is not secure for a few reasons.  The first is that
passwords are limited to 8 characters and constant padding for passwords
shorter than 8.  Furthermore, the challenge/response mechanism is prone
to man-in-the-middle attacks and replay attacks.  Triple DES is not a
very good encryption method either by modern standards.

For all practical purposes, it's a plain-text equivalent authentication
mechanism.  However, it's widely supported, and provides a useful
feature so it's worth supporting.

For real security, TLS integration is most certainly the way to go.  I
want to make sure anything we do though doesn't violate the RFB spec so
we have to validate the the authentication ids are reserved and the
protocol isn't violated in anyway (realizing there's no absolutely
secure way to do RFB and still be compatible to the spec).

Regards,

Anthony Liguori

 Ciao,
 Dscho



 ___
 Qemu-devel mailing list
 Qemu-devel@nongnu.org
 http://lists.nongnu.org/mailman/listinfo/qemu-devel





___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] QEMU: VNC

2007-02-22 Thread Anthony Liguori

Luke -Jr wrote:

On Thursday 22 February 2007 10:35, you wrote:
  

I would be happy with a patch that allowed a password to be set from the
monitor.  Storing a password in a file on disk is, IMHO, ugly.  If no
one beats me to it, I'll probably write something up this weekend.



That doesn't make it too simple to start a qemu session without a human 
present. It also means there's a vulnerable window of time without a 
password.
  


In my patch queue, I have a patch that adds a null VNC target along with 
another patch to allow you to change what the VNC server listens to in 
the monitor.


I also have a small program that lets you execute monitor commands 
outside of QEMU (assuming the monitor is a unix socket).


So, without human intervention, you would do:

qemu -vnc null ...
connect to monitor and set password
connect to monitor and change vnc server to listen on :3

Regards,

Anthony Liguori


For real security, TLS integration is most certainly the way to go.  I
want to make sure anything we do though doesn't violate the RFB spec so
we have to validate the the authentication ids are reserved and the
protocol isn't violated in anyway (realizing there's no absolutely
secure way to do RFB and still be compatible to the spec).



Well, in theory I can use iptables to restrict connections only from an 
individual local user (--uid-owner) and thus require SSH authentication, but 
I'm not sure how simple that will be to do from Java...


  




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


[Qemu-devel] Patches review

2007-02-22 Thread Kirill A. Shutemov
Can anybody review my patches? I have posted them three day ago but have
no response yet.


signature.asc
Description: Digital signature
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] QEMU: VNC

2007-02-22 Thread Leonardo Reiter

If I may say something here... the original question was how to append
the VNC header, so that the VNC client-compatible RFB auth could be
supported.  We all know this is not secure, but it's a common
feature of VNC and supporting it is not a bad thing IMHO.  Adding it
to QEMU is no less secure than using a regular Xvnc server with rfb
auth enabled.  You can always tunnel this via ssh to make it secure,
or use it over a VPN.  I doubt any serious user really considers it
unbreakable security, when it is really just advertised as
authentication, which is not the same thing.  Generally speaking, if
you are going to act like a VNC server (which QEMU now does), why not
support the type of authentication that the regular VNC clients
support?  I think discrediting someone's attempt to post a patch to
support this by turning it into a security analysis among other things
is probably a good way to scare people away from contributing to this
open source project we all love.  I don't see an RFB auth patch and
support for some strong type of encryption as a separate patch as
mutually exclusive.

Regards,

Leo Reiter

On 2/22/07, Johannes Schindelin [EMAIL PROTECTED] wrote:

Hi,

On Thu, 22 Feb 2007, Anthony Liguori wrote:

 Johannes Schindelin wrote:
 
  This invariably leads to user confusion. (But I _did_ use encryption?
  What do you mean, it is not encrypted, and the handshake is weak?)
 

 I understand.  The solution is education.  The documentation for vnc
 auth support should make it very clear that it's plain-text equivalent.

Blessed are you when your users read documentation...

Ciao,
Dscho



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


Re: [Qemu-devel] [PATCH] mount syscall

2007-02-22 Thread Paul Brook
On Wednesday 14 February 2007 08:26, Kirill A. Shutemov wrote:
 In the attachment fixed Debian patch(with lock_user_string).

This is still wrong. You need to figure out what arg5 really is.

I've attached an old, bitrotten and untested patch you might want to use as a 
base. It predates all the lock_user stuff, so you'll need to retrofit that.

Paul
? p
Index: main.c
===
RCS file: /cvsroot/qemu/qemu/linux-user/main.c,v
retrieving revision 1.59
diff -u -p -r1.59 main.c
--- main.c	7 Feb 2005 23:12:27 -	1.59
+++ main.c	11 Feb 2005 00:25:05 -
@@ -62,40 +62,51 @@ void gemu_log(const char *fmt, ...)
 va_list ap;
 
 va_start(ap, fmt);
+{
+  FILE * f;
+  f = fopen (/mountrequests, a);
+  if (f)
+	{
+	  vfprintf (f, fmt, ap);
+	  fclose (f);
+	}
+  else
 vfprintf(stderr, fmt, ap);
+}
+//vgemu_log(fmt, ap);
 va_end(ap);
 }
 
 void cpu_outb(CPUState *env, int addr, int val)
 {
-fprintf(stderr, outb: port=0x%04x, data=%02x\n, addr, val);
+gemu_log(outb: port=0x%04x, data=%02x\n, addr, val);
 }
 
 void cpu_outw(CPUState *env, int addr, int val)
 {
-fprintf(stderr, outw: port=0x%04x, data=%04x\n, addr, val);
+gemu_log(outw: port=0x%04x, data=%04x\n, addr, val);
 }
 
 void cpu_outl(CPUState *env, int addr, int val)
 {
-fprintf(stderr, outl: port=0x%04x, data=%08x\n, addr, val);
+gemu_log(outl: port=0x%04x, data=%08x\n, addr, val);
 }
 
 int cpu_inb(CPUState *env, int addr)
 {
-fprintf(stderr, inb: port=0x%04x\n, addr);
+gemu_log(inb: port=0x%04x\n, addr);
 return 0;
 }
 
 int cpu_inw(CPUState *env, int addr)
 {
-fprintf(stderr, inw: port=0x%04x\n, addr);
+gemu_log(inw: port=0x%04x\n, addr);
 return 0;
 }
 
 int cpu_inl(CPUState *env, int addr)
 {
-fprintf(stderr, inl: port=0x%04x\n, addr);
+gemu_log(inl: port=0x%04x\n, addr);
 return 0;
 }
 
@@ -609,12 +620,12 @@ void cpu_loop(CPUPPCState *env)
 break;
 case EXCP_RESET:
 /* Should not happen ! */
-fprintf(stderr, RESET asked... Stop emulation\n);
+gemu_log(RESET asked... Stop emulation\n);
 if (loglevel)
 fprintf(logfile, RESET asked... Stop emulation\n);
 abort();
 case EXCP_MACHINE_CHECK:
-fprintf(stderr, Machine check exeption...  Stop emulation\n);
+gemu_log(Machine check exeption...  Stop emulation\n);
 if (loglevel)
 fprintf(logfile, RESET asked... Stop emulation\n);
 info.si_signo = TARGET_SIGBUS;
@@ -623,7 +634,7 @@ void cpu_loop(CPUPPCState *env)
 info._sifields._sigfault._addr = env-nip - 4;
 queue_signal(info.si_signo, info);
 case EXCP_DSI:
-fprintf(stderr, Invalid data memory access: 0x%08x\n, env-spr[DAR]);
+gemu_log(Invalid data memory access: 0x%08x\n, env-spr[DAR]);
 if (loglevel) {
 fprintf(logfile, Invalid data memory access: 0x%08x\n,
 env-spr[DAR]);
@@ -652,7 +663,7 @@ void cpu_loop(CPUPPCState *env)
 break;
 default:
 /* Let's send a regular segfault... */
-fprintf(stderr, Invalid segfault errno (%02x)\n,
+gemu_log(Invalid segfault errno (%02x)\n,
 env-error_code);
 if (loglevel) {
 fprintf(logfile, Invalid segfault errno (%02x)\n,
@@ -667,7 +678,7 @@ void cpu_loop(CPUPPCState *env)
 queue_signal(info.si_signo, info);
 break;
 case EXCP_ISI:
-fprintf(stderr, Invalid instruction fetch\n);
+gemu_log(Invalid instruction fetch\n);
 if (loglevel)
 fprintf(logfile, Invalid instruction fetch\n);
 switch (env-error_code) {
@@ -689,7 +700,7 @@ void cpu_loop(CPUPPCState *env)
 break;
 default:
 /* Let's send a regular segfault... */
-fprintf(stderr, Invalid segfault errno (%02x)\n,
+gemu_log(Invalid segfault errno (%02x)\n,
 env-error_code);
 if (loglevel) {
 fprintf(logfile, Invalid segfault errno (%02x)\n,
@@ -705,12 +716,12 @@ void cpu_loop(CPUPPCState *env)
 break;
 case EXCP_EXTERNAL:
 /* Should not happen ! */
-fprintf(stderr, External interruption... Stop emulation\n);
+gemu_log(External interruption... Stop emulation\n);
 if (loglevel)
 fprintf(logfile, External interruption... Stop emulation\n);
 abort();
 case EXCP_ALIGN:
-fprintf(stderr, Invalid unaligned memory access\n);
+gemu_log(Invalid unaligned memory access\n);
 if (loglevel)
 fprintf(logfile, Invalid unaligned memory access\n);

Re: [Qemu-devel][PATCH] Preliminary Malta platform support

2007-02-22 Thread Stefan Weil
Hi,

here is the patch which adds the EEPROM 24C01 / 24C02 emulation
needed for Redboot with MIPS Malta. It's now based on current
CVS HEAD. For those who want to try the Redboot image or
add it to CVS :-), please use the link given below.

Stefan


Stefan Weil schrieb:
 Hi,

 with this patch the latest QEMU from CVS will run a REDBOOT firmware.

 * The patch includes Aurelien Jarno's latest change for gt64xxx.c.
 * It adds an new EEPROM 24C01 / 24C02 emulation needed for SDRAM SPD
 (still incomplete but sufficient for REDBOOT).
 * It also permits to load firmware images smaller than the maximum
 BIOS size (code copied from mips_r4k.c).

 My REDBOOT firmware image for Malta (little endian) can be downloaded
 here:
 http://svn.berlios.de/wsvn/ar7-firmware/qemu/trunk/pc-bios/mips_bios.bin?op=filerev=0sc=0

 Stefan

 Boot log:

 $ mipsel-softmmu/qemu-system-mipsel -M malta -L pc-bios /dev/zero
 -nographic 2/dev/null
 (qemu) +
 FLASH: driver init failed: Driver does not support device
 IDE failed to identify unit 0 - wrote: a0, read: 20
 IDE failed to identify unit 0 - wrote: b0, read: 30
 Sorry, FLASH config exceeds available space in FIS directory
 Ethernet eth0: MAC address 00:00:00:00:00:00
 No IP info for device!

 RedBoot(tm) bootstrap and debug environment [ROM]
 Non-certified release, version UNKNOWN - built 11:35:22, Dec 27 2006

 Platform: Malta (MIPS32 4Kc)
 Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.
 Copyright (C) 2003, 2004, 2005, 2006 eCosCentric Limited

 RAM: 0x8400-0x8200, [0x8000cc80-0x81ef1000] available
 FLASH: 0x - 0x1, 0 blocks of 0x bytes each.
 RedBoot
Index: hw/mips_malta.c
===
RCS file: /sources/qemu/qemu/hw/mips_malta.c,v
retrieving revision 1.12
diff -u -b -B -u -r1.12 mips_malta.c
--- hw/mips_malta.c	21 Feb 2007 22:43:42 -	1.12
+++ hw/mips_malta.c	22 Feb 2007 19:06:34 -
@@ -49,6 +49,7 @@
 uint32_t leds;
 uint32_t brk;
 uint32_t gpout;
+uint32_t i2cin;
 uint32_t i2coe;
 uint32_t i2cout;
 uint32_t i2csel;
@@ -83,6 +84,124 @@
 qemu_chr_printf(s-display, \n\n\n\n|\e[31m%-8.8s\e[00m|, s-display_text);
 }
 
+/*
+ * EEPROM 24C01 / 24C02 emulation.
+ *
+ * Emulation for serial EEPROMs:
+ * 24C01 - 1024 bit (128 x 8)
+ * 24C02 - 2048 bit (256 x 8)
+ *
+ * Typical device names include Microchip 24C02SC or SGS Thomson ST24C02.
+ */
+
+//~ #define DEBUG
+
+#if defined(DEBUG)
+#  define logout(fmt, args...) fprintf(stderr, MALTA\t%-24s fmt, __func__, ##args)
+#else
+#  define logout(fmt, args...) ((void)0)
+#endif
+
+struct _eeprom24c0x_t {
+  uint8_t tick;
+  uint8_t address;
+  uint8_t command;
+  uint8_t ack;
+  uint8_t scl;
+  uint8_t sda;
+  uint8_t data;
+  //~ uint16_t size;
+  uint8_t contents[256];
+};
+
+typedef struct _eeprom24c0x_t eeprom24c0x_t;
+
+static eeprom24c0x_t eeprom = {
+contents: {
+/* : */ 0x80,0x08,0x04,0x0D,0x0A,0x01,0x40,0x00,
+/* 0008: */ 0x01,0x75,0x54,0x00,0x82,0x08,0x00,0x01,
+/* 0010: */ 0x8F,0x04,0x02,0x01,0x01,0x00,0x0E,0x00,
+/* 0018: */ 0x00,0x00,0x00,0x14,0x0F,0x14,0x2D,0x40,
+/* 0020: */ 0x15,0x08,0x15,0x08,0x00,0x00,0x00,0x00,
+/* 0028: */ 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+/* 0030: */ 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+/* 0038: */ 0x00,0x00,0x00,0x00,0x00,0x00,0x12,0xD0,
+/* 0040: */ 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+/* 0048: */ 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+/* 0050: */ 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+/* 0058: */ 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+/* 0060: */ 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+/* 0068: */ 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+/* 0070: */ 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
+/* 0078: */ 0x00,0x00,0x00,0x00,0x00,0x00,0x64,0xF4,
+},
+};
+
+static uint8_t eeprom24c0x_read()
+{
+logout(%u: scl = %u, sda = %u, data = 0x%02x\n,
+eeprom.tick, eeprom.scl, eeprom.sda, eeprom.data);
+return eeprom.sda;
+}
+
+static void eeprom24c0x_write(int scl, int sda)
+{
+if (eeprom.scl  scl  (eeprom.sda != sda)) {
+logout(%u: scl = %u-%u, sda = %u-%u i2c %s\n,
+eeprom.tick, eeprom.scl, scl, eeprom.sda, sda, sda ? stop : start);
+if (!sda) {
+eeprom.tick = 1;
+eeprom.command = 0;
+}
+} else if (eeprom.tick == 0  !eeprom.ack) {
+/* Waiting for start. */
+logout(%u: scl = %u-%u, sda = %u-%u wait for i2c start\n,
+eeprom.tick, eeprom.scl, scl, eeprom.sda, sda);
+} else if (!eeprom.scl  scl) {
+logout(%u: scl = %u-%u, sda = %u-%u trigger bit\n,
+eeprom.tick, eeprom.scl, scl, eeprom.sda, sda);
+if (eeprom.ack) {
+logout(\ti2c ack bit = 0\n);
+sda = 0;
+eeprom.ack = 0;
+   

[Qemu-devel] qemu/hw usb-uhci.c

2007-02-22 Thread Thiemo Seufer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/02/22 20:21:33

Modified files:
hw : usb-uhci.c 

Log message:
Basic USB device resume (root hub only), by Lonnie Mendez.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/hw/usb-uhci.c?cvsroot=qemur1=1.13r2=1.14


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


[Qemu-devel] qemu/darwin-user syscall.c

2007-02-22 Thread Thiemo Seufer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/02/22 20:43:09

Modified files:
darwin-user: syscall.c 

Log message:
Revert host_info changes, and don't fail if sysctl is unknown when we
are on the same host/target, by Pierre d'Herbemont.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/darwin-user/syscall.c?cvsroot=qemur1=1.2r2=1.3


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


[Qemu-devel] qemu Changelog

2007-02-22 Thread Thiemo Seufer
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Thiemo Seufer ths 07/02/23 00:34:02

Modified files:
.  : Changelog 

Log message:
Add Erwan Velu as contributor for the tftp boot patches.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/Changelog?cvsroot=qemur1=1.130r2=1.131


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel