All of lore.kernel.org
 help / color / mirror / Atom feed
* [Qemu-devel] QEMU: VNC
@ 2007-02-16 19:02 Christopher Olsen
  2007-02-16 20:57 ` Anthony Liguori
  2007-02-18 20:36 ` Christopher Olsen
  0 siblings, 2 replies; 49+ messages in thread
From: Christopher Olsen @ 2007-02-16 19:02 UTC (permalink / raw)
  To: qemu-devel

Anyone here know if there is a way to append to the VNC display header?

-Christopher


-- 
Christopher Olsen
cwolsen@domainatlantic.com
Tel: 631-676-4877
Fax: 631-249-3036

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-16 19:02 [Qemu-devel] QEMU: VNC Christopher Olsen
@ 2007-02-16 20:57 ` Anthony Liguori
  2007-02-18 20:36 ` Christopher Olsen
  1 sibling, 0 replies; 49+ messages in thread
From: Anthony Liguori @ 2007-02-16 20:57 UTC (permalink / raw)
  To: qemu-devel

Christopher Olsen wrote:
> Anyone here know if there is a way to append to the VNC display header?
>   

I'm not sure I understand what you're asking.  What is the VNC display 
header?

Regards,

Anthony Liguori

> -Christopher
>
>
>   

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-16 19:02 [Qemu-devel] QEMU: VNC Christopher Olsen
  2007-02-16 20:57 ` Anthony Liguori
@ 2007-02-18 20:36 ` Christopher Olsen
  2007-02-18 23:08   ` Anthony Liguori
  2007-02-19  0:11   ` Johannes Schindelin
  1 sibling, 2 replies; 49+ messages in thread
From: Christopher Olsen @ 2007-02-18 20:36 UTC (permalink / raw)
  To: qemu-devel

[-- Attachment #1: Type: text/plain, Size: 310 bytes --]

I didn't see a way so here is a patch for it work on 0.9.0

-Christopher

On Friday 16 February 2007 14:02, Christopher Olsen wrote:
> Anyone here know if there is a way to append to the VNC display header?
>
> -Christopher

-- 
Christopher Olsen
cwolsen@domainatlantic.com
Tel: 631-676-4877
Fax: 631-249-3036

[-- Attachment #2: qemu.patch --]
[-- Type: text/x-diff, Size: 14944 bytes --]

*** vl.c	Fri Feb 16 13:27:06 2007
--- /home/reddawg/qemu/work/qemu-0.9.0/vl.c	Fri Feb 16 13:30:09 2007
***************
*** 1,9 ****
--- 1,10 ----
  /*
   * QEMU System Emulator
   * 
   * Copyright (c) 2003-2007 Fabrice Bellard
+  * Copyright (C) 2007 Christopher Olsen <cwolsen@ubixos.com>
   * 
   * Permission is hereby granted, free of charge, to any person obtaining a copy
   * of this software and associated documentation files (the "Software"), to deal
   * in the Software without restriction, including without limitation the rights
   * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
***************
*** 45,54 ****
--- 46,60 ----
  #ifdef _BSD
  #include <sys/stat.h>
  #ifndef __APPLE__
  #include <libutil.h>
  #endif
+ #ifdef __FreeBSD__
+ #include <sys/module.h>
+ #include <dev/ppbus/ppi.h>
+ #include <dev/ppbus/ppbconf.h>
+ #endif
  #else
  #ifndef __sun__
  #include <linux/if.h>
  #include <linux/if_tun.h>
  #include <pty.h>
***************
*** 87,101 ****
--- 93,109 ----
  #include "disas.h"
  
  #include "exec-all.h"
  
  #define DEFAULT_NETWORK_SCRIPT "/etc/qemu-ifup"
+ #ifndef SMBD_COMMAND
  #ifdef __sun__
  #define SMBD_COMMAND "/usr/sfw/sbin/smbd"
  #else
  #define SMBD_COMMAND "/usr/sbin/smbd"
  #endif
+ #endif
  
  //#define DEBUG_UNUSED_IOPORT
  //#define DEBUG_IOPORT
  
  #define PHYS_RAM_MAX_SIZE (2047 * 1024 * 1024)
***************
*** 156,165 ****
--- 164,174 ----
  #endif
  int usb_enabled = 0;
  static VLANState *first_vlan;
  int smp_cpus = 1;
  const char *vnc_display;
+ const char *vnc_name;
  #if defined(TARGET_SPARC)
  #define MAX_CPUS 16
  #elif defined(TARGET_I386)
  #define MAX_CPUS 255
  #else
***************
*** 626,636 ****
  static int use_rt_clock;
  
  static void init_get_clock(void)
  {
      use_rt_clock = 0;
! #if defined(__linux__)
      {
          struct timespec ts;
          if (clock_gettime(CLOCK_MONOTONIC, &ts) == 0) {
              use_rt_clock = 1;
          }
--- 635,645 ----
  static int use_rt_clock;
  
  static void init_get_clock(void)
  {
      use_rt_clock = 0;
! #if defined(__linux__) || (defined(__FreeBSD__) && __FreeBSD_version >= 500000)
      {
          struct timespec ts;
          if (clock_gettime(CLOCK_MONOTONIC, &ts) == 0) {
              use_rt_clock = 1;
          }
***************
*** 638,648 ****
  #endif
  }
  
  static int64_t get_clock(void)
  {
! #if defined(__linux__)
      if (use_rt_clock) {
          struct timespec ts;
          clock_gettime(CLOCK_MONOTONIC, &ts);
          return ts.tv_sec * 1000000000LL + ts.tv_nsec;
      } else 
--- 647,657 ----
  #endif
  }
  
  static int64_t get_clock(void)
  {
! #if defined(__linux__) || (defined(__FreeBSD__) && __FreeBSD_version >= 500000)
      if (use_rt_clock) {
          struct timespec ts;
          clock_gettime(CLOCK_MONOTONIC, &ts);
          return ts.tv_sec * 1000000000LL + ts.tv_nsec;
      } else 
***************
*** 1639,1649 ****
          term_init();
      }
      return chr;
  }
  
! #if defined(__linux__)
  static CharDriverState *qemu_chr_open_pty(void)
  {
      struct termios tty;
      char slave_name[1024];
      int master_fd, slave_fd;
--- 1648,1658 ----
          term_init();
      }
      return chr;
  }
  
! #if defined(__linux__) || defined(__FreeBSD__)
  static CharDriverState *qemu_chr_open_pty(void)
  {
      struct termios tty;
      char slave_name[1024];
      int master_fd, slave_fd;
***************
*** 1718,1731 ****
  
      cfsetispeed(&tty, spd);
      cfsetospeed(&tty, spd);
  
      tty.c_iflag &= ~(IGNBRK|BRKINT|PARMRK|ISTRIP
!                           |INLCR|IGNCR|ICRNL|IXON);
!     tty.c_oflag |= OPOST;
      tty.c_lflag &= ~(ECHO|ECHONL|ICANON|IEXTEN|ISIG);
      tty.c_cflag &= ~(CSIZE|PARENB|PARODD|CRTSCTS|CSTOPB);
      switch(data_bits) {
      default:
      case 8:
          tty.c_cflag |= CS8;
          break;
--- 1727,1743 ----
  
      cfsetispeed(&tty, spd);
      cfsetospeed(&tty, spd);
  
      tty.c_iflag &= ~(IGNBRK|BRKINT|PARMRK|ISTRIP
!                           |INLCR|IGNCR|ICRNL|IXON|IMAXBEL);
!     tty.c_oflag &= ~OPOST; /* Don't do any output processing! */
      tty.c_lflag &= ~(ECHO|ECHONL|ICANON|IEXTEN|ISIG);
      tty.c_cflag &= ~(CSIZE|PARENB|PARODD|CRTSCTS|CSTOPB);
+ #ifdef __FreeBSD__
+     cfmakeraw(&tty);
+ #endif
      switch(data_bits) {
      default:
      case 8:
          tty.c_cflag |= CS8;
          break;
***************
*** 1797,1806 ****
--- 1809,1819 ----
      chr->chr_ioctl = tty_serial_ioctl;
      qemu_chr_reset(chr);
      return chr;
  }
  
+ #if defined(__linux__)
  static int pp_ioctl(CharDriverState *chr, int cmd, void *arg)
  {
      int fd = (int)chr->opaque;
      uint8_t b;
  
***************
*** 1861,1870 ****
--- 1874,1941 ----
  
      qemu_chr_reset(chr);
  
      return chr;
  }
+ #elif defined(__FreeBSD__)
+ static int pp_ioctl(CharDriverState *chr, int cmd, void *arg)
+ {
+     int fd = (int)chr->opaque;
+     uint8_t b;
+ 
+     switch(cmd) {
+     case CHR_IOCTL_PP_READ_DATA:
+         if (ioctl(fd, PPIGDATA, &b) < 0)
+             return -ENOTSUP;
+         *(uint8_t *)arg = b;
+         break;
+     case CHR_IOCTL_PP_WRITE_DATA:
+         b = *(uint8_t *)arg;
+         if (ioctl(fd, PPISDATA, &b) < 0)
+             return -ENOTSUP;
+         break;
+     case CHR_IOCTL_PP_READ_CONTROL:
+         if (ioctl(fd, PPIGCTRL, &b) < 0)
+             return -ENOTSUP;
+         *(uint8_t *)arg = b;
+         break;
+     case CHR_IOCTL_PP_WRITE_CONTROL:
+         b = *(uint8_t *)arg;
+         if (ioctl(fd, PPISCTRL, &b) < 0)
+             return -ENOTSUP;
+         break;
+     case CHR_IOCTL_PP_READ_STATUS:
+         if (ioctl(fd, PPIGSTATUS, &b) < 0)
+             return -ENOTSUP;
+         *(uint8_t *)arg = b;
+         break;
+     default:
+         return -ENOTSUP;
+     }
+     return 0;
+ }
+ 
+ CharDriverState *qemu_chr_open_pp(const char *filename)
+ {
+     CharDriverState *chr;
+     int fd;
+ 
+     fd = open(filename, O_RDWR);
+     if (fd < 0)
+         return NULL;
+ 
+     chr = qemu_mallocz(sizeof(CharDriverState));
+     if (!chr) {
+         close(fd);
+         return NULL;
+     }
+     chr->opaque = (void *)fd;
+     chr->chr_write = null_chr_write;
+     chr->chr_ioctl = pp_ioctl;
+     return chr;
+ }
+ #endif
  
  #else
  static CharDriverState *qemu_chr_open_pty(void)
  {
      return NULL;
***************
*** 2737,2746 ****
--- 2808,2824 ----
          return qemu_chr_open_pp(filename);
      } else 
      if (strstart(filename, "/dev/", NULL)) {
          return qemu_chr_open_tty(filename);
      } else 
+ #elif defined(__FreeBSD__)
+     if (strstart(filename, "/dev/ppi", NULL)) {
+         return qemu_chr_open_pp(filename);
+     } else 
+     if (strstart(filename, "/dev/", NULL)) {
+         return qemu_chr_open_tty(filename);
+     } else 
  #endif
  #ifdef _WIN32
      if (strstart(filename, "COM", NULL)) {
          return qemu_chr_open_win(filename);
      } else
***************
*** 3169,3178 ****
--- 3247,3284 ----
  
  #endif /* !defined(_WIN32) */
  
  #endif /* CONFIG_SLIRP */
  
+ #ifdef __FreeBSD__
+ #define LOAD_QUIETLY	1
+ #define LOAD_VERBOSLY	2
+ 
+ int
+ loadmodules(int how, const char *module, ...)
+ {
+   int loaded = 0;
+   va_list ap;
+ 
+   va_start(ap, module);
+ #ifndef NO_MODULES
+   while (module != NULL) {
+     if (modfind(module) == -1) {
+       if (kldload(module) == -1) {
+         if (how == LOAD_VERBOSLY)
+           fprintf(stderr, "%s: Cannot load module\n", module);
+       } else
+         loaded++;
+     }
+     module = va_arg(ap, const char *);
+   }
+   va_end(ap);
+ #endif
+   return loaded;
+ }
+ #endif
+ 
  #if !defined(_WIN32)
  
  typedef struct TAPState {
      VLANClientState *vc;
      int fd;
***************
*** 3224,3238 ****
  {
      int fd;
      char *dev;
      struct stat s;
  
      fd = open("/dev/tap", O_RDWR);
      if (fd < 0) {
!         fprintf(stderr, "warning: could not open /dev/tap: no virtual network emulation\n");
          return -1;
      }
  
      fstat(fd, &s);
      dev = devname(s.st_rdev, S_IFCHR);
      pstrcpy(ifname, ifname_size, dev);
  
--- 3330,3388 ----
  {
      int fd;
      char *dev;
      struct stat s;
  
+ #ifdef __FreeBSD__
+     int i, kldtried = 0, enoentcount = 0, err = 0;
+     char dname[100];
+ #ifdef USE_DEVTAP
+     /*
+      * 5.x has /dev/tap, but that seems to just blindly increase its
+      * couter on every open() for some people(??), i.e. on every qemu run.
+      */
+     i = -1;
+ #else
+     i = 0;
+ #endif
+     for (; i < 10; i++) {
+         if (i == -1)
+ 	    strcpy(dname, "/dev/tap");
+         else
+ 	    snprintf(dname, sizeof dname, "%s%d",
+ 		     "/dev/tap", i);
+         fd = open(dname, O_RDWR);
+         if (fd >= 0)
+             break;
+         else if (errno == ENXIO || errno == ENOENT) {
+             if (i == 0 && !kldtried++) {
+                 /*
+                  * Attempt to load the tunnel interface KLD if it isn't loaded
+                  * already.
+                  */
+                 if (loadmodules(LOAD_VERBOSLY, "if_tap", NULL))
+                     i = -1;
+                 continue;
+             }
+             if (errno != ENOENT || ++enoentcount > 3) {
+                 err = errno;
+ 	        break;
+             }
+         } else
+             err = errno;
+     }
+     if (fd < 0) {
+         fprintf(stderr, "warning: could not open %s (%s): no virtual network emulation\n", dname, strerror(err));
+         return -1;
+     }
+ #else
      fd = open("/dev/tap", O_RDWR);
      if (fd < 0) {
!         fprintf(stderr, "warning: could not open /dev/tap (%s): no virtual network emulation\n", strerror(errno));
          return -1;
      }
+ #endif
  
      fstat(fd, &s);
      dev = devname(s.st_rdev, S_IFCHR);
      pstrcpy(ifname, ifname_size, dev);
  
***************
*** 6199,6208 ****
--- 6349,6359 ----
      QEMU_OPTION_win2k_hack,
      QEMU_OPTION_usb,
      QEMU_OPTION_usbdevice,
      QEMU_OPTION_smp,
      QEMU_OPTION_vnc,
+     QEMU_OPTION_vncname,
      QEMU_OPTION_no_acpi,
      QEMU_OPTION_no_reboot,
      QEMU_OPTION_daemonize,
      QEMU_OPTION_option_rom,
      QEMU_OPTION_semihosting
***************
*** 6279,6288 ****
--- 6430,6440 ----
      { "pidfile", HAS_ARG, QEMU_OPTION_pidfile },
      { "win2k-hack", 0, QEMU_OPTION_win2k_hack },
      { "usbdevice", HAS_ARG, QEMU_OPTION_usbdevice },
      { "smp", HAS_ARG, QEMU_OPTION_smp },
      { "vnc", HAS_ARG, QEMU_OPTION_vnc },
+     { "vncname", HAS_ARG, QEMU_OPTION_vncname },
  
      /* temporary options */
      { "usb", 0, QEMU_OPTION_usb },
      { "cirrusvga", 0, QEMU_OPTION_cirrusvga },
      { "no-acpi", 0, QEMU_OPTION_no_acpi },
***************
*** 6704,6713 ****
--- 6856,6866 ----
                  }
                  break;
              case QEMU_OPTION_nographic:
                  pstrcpy(monitor_device, sizeof(monitor_device), "stdio");
                  pstrcpy(serial_devices[0], sizeof(serial_devices[0]), "stdio");
+                 pstrcpy(parallel_devices[0], sizeof(parallel_devices[0]), "null");
                  nographic = 1;
                  break;
              case QEMU_OPTION_kernel:
                  kernel_filename = optarg;
                  break;
***************
*** 6936,6945 ****
--- 7089,7101 ----
                  }
                  break;
  	    case QEMU_OPTION_vnc:
  		vnc_display = optarg;
  		break;
+             case QEMU_OPTION_vncname:
+                 vnc_name = optarg;
+                 break;
              case QEMU_OPTION_no_acpi:
                  acpi_enabled = 0;
                  break;
              case QEMU_OPTION_no_reboot:
                  no_reboot = 1;
*** vl.h	Fri Feb 16 13:27:06 2007
--- /home/reddawg/qemu/work/qemu-0.9.0/vl.h	Fri Feb 16 13:30:23 2007
***************
*** 1,9 ****
--- 1,10 ----
  /*
   * QEMU System Emulator header
   * 
   * Copyright (c) 2003 Fabrice Bellard
+  * Copyright (C) 2007 Christopher Olsen <cwolsen@ubixos.com>
   * 
   * Permission is hereby granted, free of charge, to any person obtaining a copy
   * of this software and associated documentation files (the "Software"), to deal
   * in the Software without restriction, including without limitation the rights
   * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
***************
*** 28,37 ****
--- 29,44 ----
  #include <stdlib.h>
  #include <stdio.h>
  #include <stdarg.h>
  #include <string.h>
  #include <inttypes.h>
+ #ifndef PRId64
+ #define	PRId64	"lld"	/* int64_t */
+ #define	PRIo64	"llo"	/* int64_t */
+ #define	PRIx64	"llx"	/* int64_t */
+ #define	PRIu64	"llu"	/* int64_t */
+ #endif
  #include <limits.h>
  #include <time.h>
  #include <ctype.h>
  #include <errno.h>
  #include <unistd.h>
***************
*** 110,119 ****
--- 117,129 ----
  uint64_t muldiv64(uint64_t a, uint32_t b, uint32_t c);
  
  void hw_error(const char *fmt, ...);
  
  extern const char *bios_dir;
+ 
+ //UBU
+ extern const char *vnc_name;
  
  extern int vm_running;
  
  typedef struct vm_change_state_entry VMChangeStateEntry;
  typedef void VMChangeStateHandler(void *opaque, int running);
*** vnc.c	Fri Feb 16 13:27:06 2007
--- /home/reddawg/qemu/work/qemu-0.9.0/vnc.c	Fri Feb 16 13:29:13 2007
***************
*** 1,10 ****
--- 1,11 ----
  /*
   * QEMU VNC display driver
   * 
   * Copyright (C) 2006 Anthony Liguori <anthony@codemonkey.ws>
   * Copyright (C) 2006 Fabrice Bellard
+  * Copyright (C) 2007 Christopher Olsen <cwolsen@ubixos.com>
   * 
   * Permission is hereby granted, free of charge, to any person obtaining a copy
   * of this software and associated documentation files (the "Software"), to deal
   * in the Software without restriction, including without limitation the rights
   * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
***************
*** 1054,1063 ****
--- 1055,1065 ----
  }
  
  static int protocol_client_init(VncState *vs, char *data, size_t len)
  {
      char pad[3] = { 0, 0, 0 };
+     char name[64];
  
      vs->width = vs->ds->width;
      vs->height = vs->ds->height;
      vnc_write_u16(vs, vs->ds->width);
      vnc_write_u16(vs, vs->ds->height);
***************
*** 1098,1109 ****
      }
      vs->write_pixels = vnc_write_pixels_copy;
  	
      vnc_write(vs, pad, 3);           /* padding */
  
!     vnc_write_u32(vs, 4);        
!     vnc_write(vs, "QEMU", 4);
      vnc_flush(vs);
  
      vnc_read_when(vs, protocol_client_msg, 1);
  
      return 0;
--- 1100,1115 ----
      }
      vs->write_pixels = vnc_write_pixels_copy;
  	
      vnc_write(vs, pad, 3);           /* padding */
  
!     if (vnc_name == 0x0)
!       sprintf(name, "QEMU: Unknown");
!     else
!       sprintf(name, "QEMU: %s",vnc_name);
!     vnc_write_u32(vs, strlen(name));
!     vnc_write(vs, name, strlen(name));
      vnc_flush(vs);
  
      vnc_read_when(vs, protocol_client_msg, 1);
  
      return 0;

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-18 20:36 ` Christopher Olsen
@ 2007-02-18 23:08   ` Anthony Liguori
  2007-02-18 23:53     ` Christopher Olsen
  2007-02-19  0:11   ` Johannes Schindelin
  1 sibling, 1 reply; 49+ messages in thread
From: Anthony Liguori @ 2007-02-18 23:08 UTC (permalink / raw)
  To: qemu-devel

Christopher Olsen wrote:
> I didn't see a way so here is a patch for it work on 0.9.0
>   

I've got a more generic -name patch I've been sitting on.  It adds a 
title for the VNC session and SDL session.  If there's interest, I can 
push it further ahead in my queue.

Regards,

Anthony Liguori

> -Christopher
>
> On Friday 16 February 2007 14:02, Christopher Olsen wrote:
>   
>> Anyone here know if there is a way to append to the VNC display header?
>>
>> -Christopher
>>     
>
>   
> ------------------------------------------------------------------------
>
> *** vl.c	Fri Feb 16 13:27:06 2007
> --- /home/reddawg/qemu/work/qemu-0.9.0/vl.c	Fri Feb 16 13:30:09 2007
> ***************
> *** 1,9 ****
> --- 1,10 ----
>   /*
>    * QEMU System Emulator
>    * 
>    * Copyright (c) 2003-2007 Fabrice Bellard
> +  * Copyright (C) 2007 Christopher Olsen <cwolsen@ubixos.com>
>    * 
>    * Permission is hereby granted, free of charge, to any person obtaining a copy
>    * of this software and associated documentation files (the "Software"), to deal
>    * in the Software without restriction, including without limitation the rights
>    * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> ***************
> *** 45,54 ****
> --- 46,60 ----
>   #ifdef _BSD
>   #include <sys/stat.h>
>   #ifndef __APPLE__
>   #include <libutil.h>
>   #endif
> + #ifdef __FreeBSD__
> + #include <sys/module.h>
> + #include <dev/ppbus/ppi.h>
> + #include <dev/ppbus/ppbconf.h>
> + #endif
>   #else
>   #ifndef __sun__
>   #include <linux/if.h>
>   #include <linux/if_tun.h>
>   #include <pty.h>
> ***************
> *** 87,101 ****
> --- 93,109 ----
>   #include "disas.h"
>   
>   #include "exec-all.h"
>   
>   #define DEFAULT_NETWORK_SCRIPT "/etc/qemu-ifup"
> + #ifndef SMBD_COMMAND
>   #ifdef __sun__
>   #define SMBD_COMMAND "/usr/sfw/sbin/smbd"
>   #else
>   #define SMBD_COMMAND "/usr/sbin/smbd"
>   #endif
> + #endif
>   
>   //#define DEBUG_UNUSED_IOPORT
>   //#define DEBUG_IOPORT
>   
>   #define PHYS_RAM_MAX_SIZE (2047 * 1024 * 1024)
> ***************
> *** 156,165 ****
> --- 164,174 ----
>   #endif
>   int usb_enabled = 0;
>   static VLANState *first_vlan;
>   int smp_cpus = 1;
>   const char *vnc_display;
> + const char *vnc_name;
>   #if defined(TARGET_SPARC)
>   #define MAX_CPUS 16
>   #elif defined(TARGET_I386)
>   #define MAX_CPUS 255
>   #else
> ***************
> *** 626,636 ****
>   static int use_rt_clock;
>   
>   static void init_get_clock(void)
>   {
>       use_rt_clock = 0;
> ! #if defined(__linux__)
>       {
>           struct timespec ts;
>           if (clock_gettime(CLOCK_MONOTONIC, &ts) == 0) {
>               use_rt_clock = 1;
>           }
> --- 635,645 ----
>   static int use_rt_clock;
>   
>   static void init_get_clock(void)
>   {
>       use_rt_clock = 0;
> ! #if defined(__linux__) || (defined(__FreeBSD__) && __FreeBSD_version >= 500000)
>       {
>           struct timespec ts;
>           if (clock_gettime(CLOCK_MONOTONIC, &ts) == 0) {
>               use_rt_clock = 1;
>           }
> ***************
> *** 638,648 ****
>   #endif
>   }
>   
>   static int64_t get_clock(void)
>   {
> ! #if defined(__linux__)
>       if (use_rt_clock) {
>           struct timespec ts;
>           clock_gettime(CLOCK_MONOTONIC, &ts);
>           return ts.tv_sec * 1000000000LL + ts.tv_nsec;
>       } else 
> --- 647,657 ----
>   #endif
>   }
>   
>   static int64_t get_clock(void)
>   {
> ! #if defined(__linux__) || (defined(__FreeBSD__) && __FreeBSD_version >= 500000)
>       if (use_rt_clock) {
>           struct timespec ts;
>           clock_gettime(CLOCK_MONOTONIC, &ts);
>           return ts.tv_sec * 1000000000LL + ts.tv_nsec;
>       } else 
> ***************
> *** 1639,1649 ****
>           term_init();
>       }
>       return chr;
>   }
>   
> ! #if defined(__linux__)
>   static CharDriverState *qemu_chr_open_pty(void)
>   {
>       struct termios tty;
>       char slave_name[1024];
>       int master_fd, slave_fd;
> --- 1648,1658 ----
>           term_init();
>       }
>       return chr;
>   }
>   
> ! #if defined(__linux__) || defined(__FreeBSD__)
>   static CharDriverState *qemu_chr_open_pty(void)
>   {
>       struct termios tty;
>       char slave_name[1024];
>       int master_fd, slave_fd;
> ***************
> *** 1718,1731 ****
>   
>       cfsetispeed(&tty, spd);
>       cfsetospeed(&tty, spd);
>   
>       tty.c_iflag &= ~(IGNBRK|BRKINT|PARMRK|ISTRIP
> !                           |INLCR|IGNCR|ICRNL|IXON);
> !     tty.c_oflag |= OPOST;
>       tty.c_lflag &= ~(ECHO|ECHONL|ICANON|IEXTEN|ISIG);
>       tty.c_cflag &= ~(CSIZE|PARENB|PARODD|CRTSCTS|CSTOPB);
>       switch(data_bits) {
>       default:
>       case 8:
>           tty.c_cflag |= CS8;
>           break;
> --- 1727,1743 ----
>   
>       cfsetispeed(&tty, spd);
>       cfsetospeed(&tty, spd);
>   
>       tty.c_iflag &= ~(IGNBRK|BRKINT|PARMRK|ISTRIP
> !                           |INLCR|IGNCR|ICRNL|IXON|IMAXBEL);
> !     tty.c_oflag &= ~OPOST; /* Don't do any output processing! */
>       tty.c_lflag &= ~(ECHO|ECHONL|ICANON|IEXTEN|ISIG);
>       tty.c_cflag &= ~(CSIZE|PARENB|PARODD|CRTSCTS|CSTOPB);
> + #ifdef __FreeBSD__
> +     cfmakeraw(&tty);
> + #endif
>       switch(data_bits) {
>       default:
>       case 8:
>           tty.c_cflag |= CS8;
>           break;
> ***************
> *** 1797,1806 ****
> --- 1809,1819 ----
>       chr->chr_ioctl = tty_serial_ioctl;
>       qemu_chr_reset(chr);
>       return chr;
>   }
>   
> + #if defined(__linux__)
>   static int pp_ioctl(CharDriverState *chr, int cmd, void *arg)
>   {
>       int fd = (int)chr->opaque;
>       uint8_t b;
>   
> ***************
> *** 1861,1870 ****
> --- 1874,1941 ----
>   
>       qemu_chr_reset(chr);
>   
>       return chr;
>   }
> + #elif defined(__FreeBSD__)
> + static int pp_ioctl(CharDriverState *chr, int cmd, void *arg)
> + {
> +     int fd = (int)chr->opaque;
> +     uint8_t b;
> + 
> +     switch(cmd) {
> +     case CHR_IOCTL_PP_READ_DATA:
> +         if (ioctl(fd, PPIGDATA, &b) < 0)
> +             return -ENOTSUP;
> +         *(uint8_t *)arg = b;
> +         break;
> +     case CHR_IOCTL_PP_WRITE_DATA:
> +         b = *(uint8_t *)arg;
> +         if (ioctl(fd, PPISDATA, &b) < 0)
> +             return -ENOTSUP;
> +         break;
> +     case CHR_IOCTL_PP_READ_CONTROL:
> +         if (ioctl(fd, PPIGCTRL, &b) < 0)
> +             return -ENOTSUP;
> +         *(uint8_t *)arg = b;
> +         break;
> +     case CHR_IOCTL_PP_WRITE_CONTROL:
> +         b = *(uint8_t *)arg;
> +         if (ioctl(fd, PPISCTRL, &b) < 0)
> +             return -ENOTSUP;
> +         break;
> +     case CHR_IOCTL_PP_READ_STATUS:
> +         if (ioctl(fd, PPIGSTATUS, &b) < 0)
> +             return -ENOTSUP;
> +         *(uint8_t *)arg = b;
> +         break;
> +     default:
> +         return -ENOTSUP;
> +     }
> +     return 0;
> + }
> + 
> + CharDriverState *qemu_chr_open_pp(const char *filename)
> + {
> +     CharDriverState *chr;
> +     int fd;
> + 
> +     fd = open(filename, O_RDWR);
> +     if (fd < 0)
> +         return NULL;
> + 
> +     chr = qemu_mallocz(sizeof(CharDriverState));
> +     if (!chr) {
> +         close(fd);
> +         return NULL;
> +     }
> +     chr->opaque = (void *)fd;
> +     chr->chr_write = null_chr_write;
> +     chr->chr_ioctl = pp_ioctl;
> +     return chr;
> + }
> + #endif
>   
>   #else
>   static CharDriverState *qemu_chr_open_pty(void)
>   {
>       return NULL;
> ***************
> *** 2737,2746 ****
> --- 2808,2824 ----
>           return qemu_chr_open_pp(filename);
>       } else 
>       if (strstart(filename, "/dev/", NULL)) {
>           return qemu_chr_open_tty(filename);
>       } else 
> + #elif defined(__FreeBSD__)
> +     if (strstart(filename, "/dev/ppi", NULL)) {
> +         return qemu_chr_open_pp(filename);
> +     } else 
> +     if (strstart(filename, "/dev/", NULL)) {
> +         return qemu_chr_open_tty(filename);
> +     } else 
>   #endif
>   #ifdef _WIN32
>       if (strstart(filename, "COM", NULL)) {
>           return qemu_chr_open_win(filename);
>       } else
> ***************
> *** 3169,3178 ****
> --- 3247,3284 ----
>   
>   #endif /* !defined(_WIN32) */
>   
>   #endif /* CONFIG_SLIRP */
>   
> + #ifdef __FreeBSD__
> + #define LOAD_QUIETLY	1
> + #define LOAD_VERBOSLY	2
> + 
> + int
> + loadmodules(int how, const char *module, ...)
> + {
> +   int loaded = 0;
> +   va_list ap;
> + 
> +   va_start(ap, module);
> + #ifndef NO_MODULES
> +   while (module != NULL) {
> +     if (modfind(module) == -1) {
> +       if (kldload(module) == -1) {
> +         if (how == LOAD_VERBOSLY)
> +           fprintf(stderr, "%s: Cannot load module\n", module);
> +       } else
> +         loaded++;
> +     }
> +     module = va_arg(ap, const char *);
> +   }
> +   va_end(ap);
> + #endif
> +   return loaded;
> + }
> + #endif
> + 
>   #if !defined(_WIN32)
>   
>   typedef struct TAPState {
>       VLANClientState *vc;
>       int fd;
> ***************
> *** 3224,3238 ****
>   {
>       int fd;
>       char *dev;
>       struct stat s;
>   
>       fd = open("/dev/tap", O_RDWR);
>       if (fd < 0) {
> !         fprintf(stderr, "warning: could not open /dev/tap: no virtual network emulation\n");
>           return -1;
>       }
>   
>       fstat(fd, &s);
>       dev = devname(s.st_rdev, S_IFCHR);
>       pstrcpy(ifname, ifname_size, dev);
>   
> --- 3330,3388 ----
>   {
>       int fd;
>       char *dev;
>       struct stat s;
>   
> + #ifdef __FreeBSD__
> +     int i, kldtried = 0, enoentcount = 0, err = 0;
> +     char dname[100];
> + #ifdef USE_DEVTAP
> +     /*
> +      * 5.x has /dev/tap, but that seems to just blindly increase its
> +      * couter on every open() for some people(??), i.e. on every qemu run.
> +      */
> +     i = -1;
> + #else
> +     i = 0;
> + #endif
> +     for (; i < 10; i++) {
> +         if (i == -1)
> + 	    strcpy(dname, "/dev/tap");
> +         else
> + 	    snprintf(dname, sizeof dname, "%s%d",
> + 		     "/dev/tap", i);
> +         fd = open(dname, O_RDWR);
> +         if (fd >= 0)
> +             break;
> +         else if (errno == ENXIO || errno == ENOENT) {
> +             if (i == 0 && !kldtried++) {
> +                 /*
> +                  * Attempt to load the tunnel interface KLD if it isn't loaded
> +                  * already.
> +                  */
> +                 if (loadmodules(LOAD_VERBOSLY, "if_tap", NULL))
> +                     i = -1;
> +                 continue;
> +             }
> +             if (errno != ENOENT || ++enoentcount > 3) {
> +                 err = errno;
> + 	        break;
> +             }
> +         } else
> +             err = errno;
> +     }
> +     if (fd < 0) {
> +         fprintf(stderr, "warning: could not open %s (%s): no virtual network emulation\n", dname, strerror(err));
> +         return -1;
> +     }
> + #else
>       fd = open("/dev/tap", O_RDWR);
>       if (fd < 0) {
> !         fprintf(stderr, "warning: could not open /dev/tap (%s): no virtual network emulation\n", strerror(errno));
>           return -1;
>       }
> + #endif
>   
>       fstat(fd, &s);
>       dev = devname(s.st_rdev, S_IFCHR);
>       pstrcpy(ifname, ifname_size, dev);
>   
> ***************
> *** 6199,6208 ****
> --- 6349,6359 ----
>       QEMU_OPTION_win2k_hack,
>       QEMU_OPTION_usb,
>       QEMU_OPTION_usbdevice,
>       QEMU_OPTION_smp,
>       QEMU_OPTION_vnc,
> +     QEMU_OPTION_vncname,
>       QEMU_OPTION_no_acpi,
>       QEMU_OPTION_no_reboot,
>       QEMU_OPTION_daemonize,
>       QEMU_OPTION_option_rom,
>       QEMU_OPTION_semihosting
> ***************
> *** 6279,6288 ****
> --- 6430,6440 ----
>       { "pidfile", HAS_ARG, QEMU_OPTION_pidfile },
>       { "win2k-hack", 0, QEMU_OPTION_win2k_hack },
>       { "usbdevice", HAS_ARG, QEMU_OPTION_usbdevice },
>       { "smp", HAS_ARG, QEMU_OPTION_smp },
>       { "vnc", HAS_ARG, QEMU_OPTION_vnc },
> +     { "vncname", HAS_ARG, QEMU_OPTION_vncname },
>   
>       /* temporary options */
>       { "usb", 0, QEMU_OPTION_usb },
>       { "cirrusvga", 0, QEMU_OPTION_cirrusvga },
>       { "no-acpi", 0, QEMU_OPTION_no_acpi },
> ***************
> *** 6704,6713 ****
> --- 6856,6866 ----
>                   }
>                   break;
>               case QEMU_OPTION_nographic:
>                   pstrcpy(monitor_device, sizeof(monitor_device), "stdio");
>                   pstrcpy(serial_devices[0], sizeof(serial_devices[0]), "stdio");
> +                 pstrcpy(parallel_devices[0], sizeof(parallel_devices[0]), "null");
>                   nographic = 1;
>                   break;
>               case QEMU_OPTION_kernel:
>                   kernel_filename = optarg;
>                   break;
> ***************
> *** 6936,6945 ****
> --- 7089,7101 ----
>                   }
>                   break;
>   	    case QEMU_OPTION_vnc:
>   		vnc_display = optarg;
>   		break;
> +             case QEMU_OPTION_vncname:
> +                 vnc_name = optarg;
> +                 break;
>               case QEMU_OPTION_no_acpi:
>                   acpi_enabled = 0;
>                   break;
>               case QEMU_OPTION_no_reboot:
>                   no_reboot = 1;
> *** vl.h	Fri Feb 16 13:27:06 2007
> --- /home/reddawg/qemu/work/qemu-0.9.0/vl.h	Fri Feb 16 13:30:23 2007
> ***************
> *** 1,9 ****
> --- 1,10 ----
>   /*
>    * QEMU System Emulator header
>    * 
>    * Copyright (c) 2003 Fabrice Bellard
> +  * Copyright (C) 2007 Christopher Olsen <cwolsen@ubixos.com>
>    * 
>    * Permission is hereby granted, free of charge, to any person obtaining a copy
>    * of this software and associated documentation files (the "Software"), to deal
>    * in the Software without restriction, including without limitation the rights
>    * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> ***************
> *** 28,37 ****
> --- 29,44 ----
>   #include <stdlib.h>
>   #include <stdio.h>
>   #include <stdarg.h>
>   #include <string.h>
>   #include <inttypes.h>
> + #ifndef PRId64
> + #define	PRId64	"lld"	/* int64_t */
> + #define	PRIo64	"llo"	/* int64_t */
> + #define	PRIx64	"llx"	/* int64_t */
> + #define	PRIu64	"llu"	/* int64_t */
> + #endif
>   #include <limits.h>
>   #include <time.h>
>   #include <ctype.h>
>   #include <errno.h>
>   #include <unistd.h>
> ***************
> *** 110,119 ****
> --- 117,129 ----
>   uint64_t muldiv64(uint64_t a, uint32_t b, uint32_t c);
>   
>   void hw_error(const char *fmt, ...);
>   
>   extern const char *bios_dir;
> + 
> + //UBU
> + extern const char *vnc_name;
>   
>   extern int vm_running;
>   
>   typedef struct vm_change_state_entry VMChangeStateEntry;
>   typedef void VMChangeStateHandler(void *opaque, int running);
> *** vnc.c	Fri Feb 16 13:27:06 2007
> --- /home/reddawg/qemu/work/qemu-0.9.0/vnc.c	Fri Feb 16 13:29:13 2007
> ***************
> *** 1,10 ****
> --- 1,11 ----
>   /*
>    * QEMU VNC display driver
>    * 
>    * Copyright (C) 2006 Anthony Liguori <anthony@codemonkey.ws>
>    * Copyright (C) 2006 Fabrice Bellard
> +  * Copyright (C) 2007 Christopher Olsen <cwolsen@ubixos.com>
>    * 
>    * Permission is hereby granted, free of charge, to any person obtaining a copy
>    * of this software and associated documentation files (the "Software"), to deal
>    * in the Software without restriction, including without limitation the rights
>    * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> ***************
> *** 1054,1063 ****
> --- 1055,1065 ----
>   }
>   
>   static int protocol_client_init(VncState *vs, char *data, size_t len)
>   {
>       char pad[3] = { 0, 0, 0 };
> +     char name[64];
>   
>       vs->width = vs->ds->width;
>       vs->height = vs->ds->height;
>       vnc_write_u16(vs, vs->ds->width);
>       vnc_write_u16(vs, vs->ds->height);
> ***************
> *** 1098,1109 ****
>       }
>       vs->write_pixels = vnc_write_pixels_copy;
>   	
>       vnc_write(vs, pad, 3);           /* padding */
>   
> !     vnc_write_u32(vs, 4);        
> !     vnc_write(vs, "QEMU", 4);
>       vnc_flush(vs);
>   
>       vnc_read_when(vs, protocol_client_msg, 1);
>   
>       return 0;
> --- 1100,1115 ----
>       }
>       vs->write_pixels = vnc_write_pixels_copy;
>   	
>       vnc_write(vs, pad, 3);           /* padding */
>   
> !     if (vnc_name == 0x0)
> !       sprintf(name, "QEMU: Unknown");
> !     else
> !       sprintf(name, "QEMU: %s",vnc_name);
> !     vnc_write_u32(vs, strlen(name));
> !     vnc_write(vs, name, strlen(name));
>       vnc_flush(vs);
>   
>       vnc_read_when(vs, protocol_client_msg, 1);
>   
>       return 0;
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>   

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-18 23:08   ` Anthony Liguori
@ 2007-02-18 23:53     ` Christopher Olsen
  2007-02-19  0:14       ` Johannes Schindelin
  0 siblings, 1 reply; 49+ messages in thread
From: Christopher Olsen @ 2007-02-18 23:53 UTC (permalink / raw)
  To: qemu-devel

Anthony,

Actually I have a version 2 to my patch which I will forward in by tomorrow 
which allows for vnc authentication..

-Christopher

On Sunday 18 February 2007 18:08, Anthony Liguori wrote:
> Christopher Olsen wrote:
> > I didn't see a way so here is a patch for it work on 0.9.0
>
> I've got a more generic -name patch I've been sitting on.  It adds a
> title for the VNC session and SDL session.  If there's interest, I can
> push it further ahead in my queue.
>
> Regards,
>
> Anthony Liguori
>
> > -Christopher
> >
> > On Friday 16 February 2007 14:02, Christopher Olsen wrote:
> >> Anyone here know if there is a way to append to the VNC display header?
> >>
> >> -Christopher
> >
> > ------------------------------------------------------------------------
> >
> > *** vl.c	Fri Feb 16 13:27:06 2007
> > --- /home/reddawg/qemu/work/qemu-0.9.0/vl.c	Fri Feb 16 13:30:09 2007
> > ***************
> > *** 1,9 ****
> > --- 1,10 ----
> >   /*
> >    * QEMU System Emulator
> >    *
> >    * Copyright (c) 2003-2007 Fabrice Bellard
> > +  * Copyright (C) 2007 Christopher Olsen <cwolsen@ubixos.com>
> >    *
> >    * Permission is hereby granted, free of charge, to any person
> > obtaining a copy * of this software and associated documentation files
> > (the "Software"), to deal * in the Software without restriction,
> > including without limitation the rights * to use, copy, modify, merge,
> > publish, distribute, sublicense, and/or sell ***************
> > *** 45,54 ****
> > --- 46,60 ----
> >   #ifdef _BSD
> >   #include <sys/stat.h>
> >   #ifndef __APPLE__
> >   #include <libutil.h>
> >   #endif
> > + #ifdef __FreeBSD__
> > + #include <sys/module.h>
> > + #include <dev/ppbus/ppi.h>
> > + #include <dev/ppbus/ppbconf.h>
> > + #endif
> >   #else
> >   #ifndef __sun__
> >   #include <linux/if.h>
> >   #include <linux/if_tun.h>
> >   #include <pty.h>
> > ***************
> > *** 87,101 ****
> > --- 93,109 ----
> >   #include "disas.h"
> >
> >   #include "exec-all.h"
> >
> >   #define DEFAULT_NETWORK_SCRIPT "/etc/qemu-ifup"
> > + #ifndef SMBD_COMMAND
> >   #ifdef __sun__
> >   #define SMBD_COMMAND "/usr/sfw/sbin/smbd"
> >   #else
> >   #define SMBD_COMMAND "/usr/sbin/smbd"
> >   #endif
> > + #endif
> >
> >   //#define DEBUG_UNUSED_IOPORT
> >   //#define DEBUG_IOPORT
> >
> >   #define PHYS_RAM_MAX_SIZE (2047 * 1024 * 1024)
> > ***************
> > *** 156,165 ****
> > --- 164,174 ----
> >   #endif
> >   int usb_enabled = 0;
> >   static VLANState *first_vlan;
> >   int smp_cpus = 1;
> >   const char *vnc_display;
> > + const char *vnc_name;
> >   #if defined(TARGET_SPARC)
> >   #define MAX_CPUS 16
> >   #elif defined(TARGET_I386)
> >   #define MAX_CPUS 255
> >   #else
> > ***************
> > *** 626,636 ****
> >   static int use_rt_clock;
> >
> >   static void init_get_clock(void)
> >   {
> >       use_rt_clock = 0;
> > ! #if defined(__linux__)
> >       {
> >           struct timespec ts;
> >           if (clock_gettime(CLOCK_MONOTONIC, &ts) == 0) {
> >               use_rt_clock = 1;
> >           }
> > --- 635,645 ----
> >   static int use_rt_clock;
> >
> >   static void init_get_clock(void)
> >   {
> >       use_rt_clock = 0;
> > ! #if defined(__linux__) || (defined(__FreeBSD__) && __FreeBSD_version >=
> > 500000) {
> >           struct timespec ts;
> >           if (clock_gettime(CLOCK_MONOTONIC, &ts) == 0) {
> >               use_rt_clock = 1;
> >           }
> > ***************
> > *** 638,648 ****
> >   #endif
> >   }
> >
> >   static int64_t get_clock(void)
> >   {
> > ! #if defined(__linux__)
> >       if (use_rt_clock) {
> >           struct timespec ts;
> >           clock_gettime(CLOCK_MONOTONIC, &ts);
> >           return ts.tv_sec * 1000000000LL + ts.tv_nsec;
> >       } else
> > --- 647,657 ----
> >   #endif
> >   }
> >
> >   static int64_t get_clock(void)
> >   {
> > ! #if defined(__linux__) || (defined(__FreeBSD__) && __FreeBSD_version >=
> > 500000) if (use_rt_clock) {
> >           struct timespec ts;
> >           clock_gettime(CLOCK_MONOTONIC, &ts);
> >           return ts.tv_sec * 1000000000LL + ts.tv_nsec;
> >       } else
> > ***************
> > *** 1639,1649 ****
> >           term_init();
> >       }
> >       return chr;
> >   }
> >
> > ! #if defined(__linux__)
> >   static CharDriverState *qemu_chr_open_pty(void)
> >   {
> >       struct termios tty;
> >       char slave_name[1024];
> >       int master_fd, slave_fd;
> > --- 1648,1658 ----
> >           term_init();
> >       }
> >       return chr;
> >   }
> >
> > ! #if defined(__linux__) || defined(__FreeBSD__)
> >   static CharDriverState *qemu_chr_open_pty(void)
> >   {
> >       struct termios tty;
> >       char slave_name[1024];
> >       int master_fd, slave_fd;
> > ***************
> > *** 1718,1731 ****
> >
> >       cfsetispeed(&tty, spd);
> >       cfsetospeed(&tty, spd);
> >
> >       tty.c_iflag &= ~(IGNBRK|BRKINT|PARMRK|ISTRIP
> > !                           |INLCR|IGNCR|ICRNL|IXON);
> > !     tty.c_oflag |= OPOST;
> >       tty.c_lflag &= ~(ECHO|ECHONL|ICANON|IEXTEN|ISIG);
> >       tty.c_cflag &= ~(CSIZE|PARENB|PARODD|CRTSCTS|CSTOPB);
> >       switch(data_bits) {
> >       default:
> >       case 8:
> >           tty.c_cflag |= CS8;
> >           break;
> > --- 1727,1743 ----
> >
> >       cfsetispeed(&tty, spd);
> >       cfsetospeed(&tty, spd);
> >
> >       tty.c_iflag &= ~(IGNBRK|BRKINT|PARMRK|ISTRIP
> > !                           |INLCR|IGNCR|ICRNL|IXON|IMAXBEL);
> > !     tty.c_oflag &= ~OPOST; /* Don't do any output processing! */
> >       tty.c_lflag &= ~(ECHO|ECHONL|ICANON|IEXTEN|ISIG);
> >       tty.c_cflag &= ~(CSIZE|PARENB|PARODD|CRTSCTS|CSTOPB);
> > + #ifdef __FreeBSD__
> > +     cfmakeraw(&tty);
> > + #endif
> >       switch(data_bits) {
> >       default:
> >       case 8:
> >           tty.c_cflag |= CS8;
> >           break;
> > ***************
> > *** 1797,1806 ****
> > --- 1809,1819 ----
> >       chr->chr_ioctl = tty_serial_ioctl;
> >       qemu_chr_reset(chr);
> >       return chr;
> >   }
> >
> > + #if defined(__linux__)
> >   static int pp_ioctl(CharDriverState *chr, int cmd, void *arg)
> >   {
> >       int fd = (int)chr->opaque;
> >       uint8_t b;
> >
> > ***************
> > *** 1861,1870 ****
> > --- 1874,1941 ----
> >
> >       qemu_chr_reset(chr);
> >
> >       return chr;
> >   }
> > + #elif defined(__FreeBSD__)
> > + static int pp_ioctl(CharDriverState *chr, int cmd, void *arg)
> > + {
> > +     int fd = (int)chr->opaque;
> > +     uint8_t b;
> > +
> > +     switch(cmd) {
> > +     case CHR_IOCTL_PP_READ_DATA:
> > +         if (ioctl(fd, PPIGDATA, &b) < 0)
> > +             return -ENOTSUP;
> > +         *(uint8_t *)arg = b;
> > +         break;
> > +     case CHR_IOCTL_PP_WRITE_DATA:
> > +         b = *(uint8_t *)arg;
> > +         if (ioctl(fd, PPISDATA, &b) < 0)
> > +             return -ENOTSUP;
> > +         break;
> > +     case CHR_IOCTL_PP_READ_CONTROL:
> > +         if (ioctl(fd, PPIGCTRL, &b) < 0)
> > +             return -ENOTSUP;
> > +         *(uint8_t *)arg = b;
> > +         break;
> > +     case CHR_IOCTL_PP_WRITE_CONTROL:
> > +         b = *(uint8_t *)arg;
> > +         if (ioctl(fd, PPISCTRL, &b) < 0)
> > +             return -ENOTSUP;
> > +         break;
> > +     case CHR_IOCTL_PP_READ_STATUS:
> > +         if (ioctl(fd, PPIGSTATUS, &b) < 0)
> > +             return -ENOTSUP;
> > +         *(uint8_t *)arg = b;
> > +         break;
> > +     default:
> > +         return -ENOTSUP;
> > +     }
> > +     return 0;
> > + }
> > +
> > + CharDriverState *qemu_chr_open_pp(const char *filename)
> > + {
> > +     CharDriverState *chr;
> > +     int fd;
> > +
> > +     fd = open(filename, O_RDWR);
> > +     if (fd < 0)
> > +         return NULL;
> > +
> > +     chr = qemu_mallocz(sizeof(CharDriverState));
> > +     if (!chr) {
> > +         close(fd);
> > +         return NULL;
> > +     }
> > +     chr->opaque = (void *)fd;
> > +     chr->chr_write = null_chr_write;
> > +     chr->chr_ioctl = pp_ioctl;
> > +     return chr;
> > + }
> > + #endif
> >
> >   #else
> >   static CharDriverState *qemu_chr_open_pty(void)
> >   {
> >       return NULL;
> > ***************
> > *** 2737,2746 ****
> > --- 2808,2824 ----
> >           return qemu_chr_open_pp(filename);
> >       } else
> >       if (strstart(filename, "/dev/", NULL)) {
> >           return qemu_chr_open_tty(filename);
> >       } else
> > + #elif defined(__FreeBSD__)
> > +     if (strstart(filename, "/dev/ppi", NULL)) {
> > +         return qemu_chr_open_pp(filename);
> > +     } else
> > +     if (strstart(filename, "/dev/", NULL)) {
> > +         return qemu_chr_open_tty(filename);
> > +     } else
> >   #endif
> >   #ifdef _WIN32
> >       if (strstart(filename, "COM", NULL)) {
> >           return qemu_chr_open_win(filename);
> >       } else
> > ***************
> > *** 3169,3178 ****
> > --- 3247,3284 ----
> >
> >   #endif /* !defined(_WIN32) */
> >
> >   #endif /* CONFIG_SLIRP */
> >
> > + #ifdef __FreeBSD__
> > + #define LOAD_QUIETLY	1
> > + #define LOAD_VERBOSLY	2
> > +
> > + int
> > + loadmodules(int how, const char *module, ...)
> > + {
> > +   int loaded = 0;
> > +   va_list ap;
> > +
> > +   va_start(ap, module);
> > + #ifndef NO_MODULES
> > +   while (module != NULL) {
> > +     if (modfind(module) == -1) {
> > +       if (kldload(module) == -1) {
> > +         if (how == LOAD_VERBOSLY)
> > +           fprintf(stderr, "%s: Cannot load module\n", module);
> > +       } else
> > +         loaded++;
> > +     }
> > +     module = va_arg(ap, const char *);
> > +   }
> > +   va_end(ap);
> > + #endif
> > +   return loaded;
> > + }
> > + #endif
> > +
> >   #if !defined(_WIN32)
> >
> >   typedef struct TAPState {
> >       VLANClientState *vc;
> >       int fd;
> > ***************
> > *** 3224,3238 ****
> >   {
> >       int fd;
> >       char *dev;
> >       struct stat s;
> >
> >       fd = open("/dev/tap", O_RDWR);
> >       if (fd < 0) {
> > !         fprintf(stderr, "warning: could not open /dev/tap: no virtual
> > network emulation\n"); return -1;
> >       }
> >
> >       fstat(fd, &s);
> >       dev = devname(s.st_rdev, S_IFCHR);
> >       pstrcpy(ifname, ifname_size, dev);
> >
> > --- 3330,3388 ----
> >   {
> >       int fd;
> >       char *dev;
> >       struct stat s;
> >
> > + #ifdef __FreeBSD__
> > +     int i, kldtried = 0, enoentcount = 0, err = 0;
> > +     char dname[100];
> > + #ifdef USE_DEVTAP
> > +     /*
> > +      * 5.x has /dev/tap, but that seems to just blindly increase its
> > +      * couter on every open() for some people(??), i.e. on every qemu
> > run. +      */
> > +     i = -1;
> > + #else
> > +     i = 0;
> > + #endif
> > +     for (; i < 10; i++) {
> > +         if (i == -1)
> > + 	    strcpy(dname, "/dev/tap");
> > +         else
> > + 	    snprintf(dname, sizeof dname, "%s%d",
> > + 		     "/dev/tap", i);
> > +         fd = open(dname, O_RDWR);
> > +         if (fd >= 0)
> > +             break;
> > +         else if (errno == ENXIO || errno == ENOENT) {
> > +             if (i == 0 && !kldtried++) {
> > +                 /*
> > +                  * Attempt to load the tunnel interface KLD if it isn't
> > loaded +                  * already.
> > +                  */
> > +                 if (loadmodules(LOAD_VERBOSLY, "if_tap", NULL))
> > +                     i = -1;
> > +                 continue;
> > +             }
> > +             if (errno != ENOENT || ++enoentcount > 3) {
> > +                 err = errno;
> > + 	        break;
> > +             }
> > +         } else
> > +             err = errno;
> > +     }
> > +     if (fd < 0) {
> > +         fprintf(stderr, "warning: could not open %s (%s): no virtual
> > network emulation\n", dname, strerror(err)); +         return -1;
> > +     }
> > + #else
> >       fd = open("/dev/tap", O_RDWR);
> >       if (fd < 0) {
> > !         fprintf(stderr, "warning: could not open /dev/tap (%s): no
> > virtual network emulation\n", strerror(errno)); return -1;
> >       }
> > + #endif
> >
> >       fstat(fd, &s);
> >       dev = devname(s.st_rdev, S_IFCHR);
> >       pstrcpy(ifname, ifname_size, dev);
> >
> > ***************
> > *** 6199,6208 ****
> > --- 6349,6359 ----
> >       QEMU_OPTION_win2k_hack,
> >       QEMU_OPTION_usb,
> >       QEMU_OPTION_usbdevice,
> >       QEMU_OPTION_smp,
> >       QEMU_OPTION_vnc,
> > +     QEMU_OPTION_vncname,
> >       QEMU_OPTION_no_acpi,
> >       QEMU_OPTION_no_reboot,
> >       QEMU_OPTION_daemonize,
> >       QEMU_OPTION_option_rom,
> >       QEMU_OPTION_semihosting
> > ***************
> > *** 6279,6288 ****
> > --- 6430,6440 ----
> >       { "pidfile", HAS_ARG, QEMU_OPTION_pidfile },
> >       { "win2k-hack", 0, QEMU_OPTION_win2k_hack },
> >       { "usbdevice", HAS_ARG, QEMU_OPTION_usbdevice },
> >       { "smp", HAS_ARG, QEMU_OPTION_smp },
> >       { "vnc", HAS_ARG, QEMU_OPTION_vnc },
> > +     { "vncname", HAS_ARG, QEMU_OPTION_vncname },
> >
> >       /* temporary options */
> >       { "usb", 0, QEMU_OPTION_usb },
> >       { "cirrusvga", 0, QEMU_OPTION_cirrusvga },
> >       { "no-acpi", 0, QEMU_OPTION_no_acpi },
> > ***************
> > *** 6704,6713 ****
> > --- 6856,6866 ----
> >                   }
> >                   break;
> >               case QEMU_OPTION_nographic:
> >                   pstrcpy(monitor_device, sizeof(monitor_device),
> > "stdio"); pstrcpy(serial_devices[0], sizeof(serial_devices[0]), "stdio");
> > +                 pstrcpy(parallel_devices[0],
> > sizeof(parallel_devices[0]), "null"); nographic = 1;
> >                   break;
> >               case QEMU_OPTION_kernel:
> >                   kernel_filename = optarg;
> >                   break;
> > ***************
> > *** 6936,6945 ****
> > --- 7089,7101 ----
> >                   }
> >                   break;
> >   	    case QEMU_OPTION_vnc:
> >   		vnc_display = optarg;
> >   		break;
> > +             case QEMU_OPTION_vncname:
> > +                 vnc_name = optarg;
> > +                 break;
> >               case QEMU_OPTION_no_acpi:
> >                   acpi_enabled = 0;
> >                   break;
> >               case QEMU_OPTION_no_reboot:
> >                   no_reboot = 1;
> > *** vl.h	Fri Feb 16 13:27:06 2007
> > --- /home/reddawg/qemu/work/qemu-0.9.0/vl.h	Fri Feb 16 13:30:23 2007
> > ***************
> > *** 1,9 ****
> > --- 1,10 ----
> >   /*
> >    * QEMU System Emulator header
> >    *
> >    * Copyright (c) 2003 Fabrice Bellard
> > +  * Copyright (C) 2007 Christopher Olsen <cwolsen@ubixos.com>
> >    *
> >    * Permission is hereby granted, free of charge, to any person
> > obtaining a copy * of this software and associated documentation files
> > (the "Software"), to deal * in the Software without restriction,
> > including without limitation the rights * to use, copy, modify, merge,
> > publish, distribute, sublicense, and/or sell ***************
> > *** 28,37 ****
> > --- 29,44 ----
> >   #include <stdlib.h>
> >   #include <stdio.h>
> >   #include <stdarg.h>
> >   #include <string.h>
> >   #include <inttypes.h>
> > + #ifndef PRId64
> > + #define	PRId64	"lld"	/* int64_t */
> > + #define	PRIo64	"llo"	/* int64_t */
> > + #define	PRIx64	"llx"	/* int64_t */
> > + #define	PRIu64	"llu"	/* int64_t */
> > + #endif
> >   #include <limits.h>
> >   #include <time.h>
> >   #include <ctype.h>
> >   #include <errno.h>
> >   #include <unistd.h>
> > ***************
> > *** 110,119 ****
> > --- 117,129 ----
> >   uint64_t muldiv64(uint64_t a, uint32_t b, uint32_t c);
> >
> >   void hw_error(const char *fmt, ...);
> >
> >   extern const char *bios_dir;
> > +
> > + //UBU
> > + extern const char *vnc_name;
> >
> >   extern int vm_running;
> >
> >   typedef struct vm_change_state_entry VMChangeStateEntry;
> >   typedef void VMChangeStateHandler(void *opaque, int running);
> > *** vnc.c	Fri Feb 16 13:27:06 2007
> > --- /home/reddawg/qemu/work/qemu-0.9.0/vnc.c	Fri Feb 16 13:29:13 2007
> > ***************
> > *** 1,10 ****
> > --- 1,11 ----
> >   /*
> >    * QEMU VNC display driver
> >    *
> >    * Copyright (C) 2006 Anthony Liguori <anthony@codemonkey.ws>
> >    * Copyright (C) 2006 Fabrice Bellard
> > +  * Copyright (C) 2007 Christopher Olsen <cwolsen@ubixos.com>
> >    *
> >    * Permission is hereby granted, free of charge, to any person
> > obtaining a copy * of this software and associated documentation files
> > (the "Software"), to deal * in the Software without restriction,
> > including without limitation the rights * to use, copy, modify, merge,
> > publish, distribute, sublicense, and/or sell ***************
> > *** 1054,1063 ****
> > --- 1055,1065 ----
> >   }
> >
> >   static int protocol_client_init(VncState *vs, char *data, size_t len)
> >   {
> >       char pad[3] = { 0, 0, 0 };
> > +     char name[64];
> >
> >       vs->width = vs->ds->width;
> >       vs->height = vs->ds->height;
> >       vnc_write_u16(vs, vs->ds->width);
> >       vnc_write_u16(vs, vs->ds->height);
> > ***************
> > *** 1098,1109 ****
> >       }
> >       vs->write_pixels = vnc_write_pixels_copy;
> >
> >       vnc_write(vs, pad, 3);           /* padding */
> >
> > !     vnc_write_u32(vs, 4);
> > !     vnc_write(vs, "QEMU", 4);
> >       vnc_flush(vs);
> >
> >       vnc_read_when(vs, protocol_client_msg, 1);
> >
> >       return 0;
> > --- 1100,1115 ----
> >       }
> >       vs->write_pixels = vnc_write_pixels_copy;
> >
> >       vnc_write(vs, pad, 3);           /* padding */
> >
> > !     if (vnc_name == 0x0)
> > !       sprintf(name, "QEMU: Unknown");
> > !     else
> > !       sprintf(name, "QEMU: %s",vnc_name);
> > !     vnc_write_u32(vs, strlen(name));
> > !     vnc_write(vs, name, strlen(name));
> >       vnc_flush(vs);
> >
> >       vnc_read_when(vs, protocol_client_msg, 1);
> >
> >       return 0;
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > 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

-- 
Christopher Olsen
cwolsen@domainatlantic.com
Tel: 631-676-4877
Fax: 631-249-3036

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-18 20:36 ` Christopher Olsen
  2007-02-18 23:08   ` Anthony Liguori
@ 2007-02-19  0:11   ` Johannes Schindelin
  2007-02-19  0:25     ` Christopher Olsen
  1 sibling, 1 reply; 49+ messages in thread
From: Johannes Schindelin @ 2007-02-19  0:11 UTC (permalink / raw)
  To: Christopher Olsen; +Cc: qemu-devel

Hi,

On Sun, 18 Feb 2007, Christopher Olsen wrote:

> I didn't see a way so here is a patch for it work on 0.9.0

This is a sneaky way to introduce a whole shotload of things, among others 
a copyright to your name, FreeBSD stuff, some #define's which may or may 
not break things.

Judging by the lines occupied by the vncname stuff, your patch is 
misnamed.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-18 23:53     ` Christopher Olsen
@ 2007-02-19  0:14       ` Johannes Schindelin
  2007-02-19  0:30         ` Christopher Olsen
  0 siblings, 1 reply; 49+ messages in thread
From: Johannes Schindelin @ 2007-02-19  0:14 UTC (permalink / raw)
  To: Christopher Olsen; +Cc: qemu-devel

Hi,

On Sun, 18 Feb 2007, Christopher Olsen wrote:

> Actually I have a version 2 to my patch which I will forward in by 
> tomorrow which allows for vnc authentication..

Which one? AFAICT there are three authentication methods, one of which is 
not secure at all. Another one is no vnc authentication at all, but rather 
an ssh authentication. The third method does not encrypt the rest of the 
protocol, so is not secure. (And yes, there exists a fourth method, which 
appears to be purely VNC, but which is not open source.)

Ciao,
Dscho

P.S.: I forgot to mention that your patch is not in unified format, which 
seems to be the preferred patch format on this list.

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-19  0:11   ` Johannes Schindelin
@ 2007-02-19  0:25     ` Christopher Olsen
  0 siblings, 0 replies; 49+ messages in thread
From: Christopher Olsen @ 2007-02-19  0:25 UTC (permalink / raw)
  To: qemu-devel

Oops.. I really did mean to trim that patch down to just the code portions....

On Sunday 18 February 2007 19:11, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 18 Feb 2007, Christopher Olsen wrote:
> > I didn't see a way so here is a patch for it work on 0.9.0
>
> This is a sneaky way to introduce a whole shotload of things, among others
> a copyright to your name, FreeBSD stuff, some #define's which may or may
> not break things.
>
> Judging by the lines occupied by the vncname stuff, your patch is
> misnamed.
>
> Ciao,
> Dscho
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

-- 
Christopher Olsen
cwolsen@domainatlantic.com
Tel: 631-676-4877
Fax: 631-249-3036

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-19  0:14       ` Johannes Schindelin
@ 2007-02-19  0:30         ` Christopher Olsen
  2007-02-19  0:41           ` Johannes Schindelin
  2007-02-19  2:01           ` Anthony Liguori
  0 siblings, 2 replies; 49+ messages in thread
From: Christopher Olsen @ 2007-02-19  0:30 UTC (permalink / raw)
  To: qemu-devel

Sorry I'll attempt to use the preferred patching method in the future..

Secure vnc auth method the default built in method from

On Sunday 18 February 2007 19:14, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 18 Feb 2007, Christopher Olsen wrote:
> > Actually I have a version 2 to my patch which I will forward in by
> > tomorrow which allows for vnc authentication..
>
> Which one? AFAICT there are three authentication methods, one of which is
> not secure at all. Another one is no vnc authentication at all, but rather
> an ssh authentication. The third method does not encrypt the rest of the
> protocol, so is not secure. (And yes, there exists a fourth method, which
> appears to be purely VNC, but which is not open source.)
>
> Ciao,
> Dscho
>
> P.S.: I forgot to mention that your patch is not in unified format, which
> seems to be the preferred patch format on this list.
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

-- 
Christopher Olsen
cwolsen@domainatlantic.com
Tel: 631-676-4877
Fax: 631-249-3036

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-19  0:30         ` Christopher Olsen
@ 2007-02-19  0:41           ` Johannes Schindelin
  2007-02-19  2:01           ` Anthony Liguori
  1 sibling, 0 replies; 49+ messages in thread
From: Johannes Schindelin @ 2007-02-19  0:41 UTC (permalink / raw)
  To: Christopher Olsen; +Cc: qemu-devel

Hi,

On Sun, 18 Feb 2007, Christopher Olsen wrote:

> Secure vnc auth method the default built in method from

... yes?

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-19  0:30         ` Christopher Olsen
  2007-02-19  0:41           ` Johannes Schindelin
@ 2007-02-19  2:01           ` Anthony Liguori
  2007-02-19  2:11             ` Johannes Schindelin
  1 sibling, 1 reply; 49+ messages in thread
From: Anthony Liguori @ 2007-02-19  2:01 UTC (permalink / raw)
  To: qemu-devel

Christopher Olsen wrote:
> Sorry I'll attempt to use the preferred patching method in the future..
>
> Secure vnc auth method the default built in method from
>   

We can't take a password from a command line.  Supporting VNC auth is 
super easy otherwise.  I really think we need to have a config file 
before we can do VNC passwords.

Regards,

Anthony Liguori

> On Sunday 18 February 2007 19:14, Johannes Schindelin wrote:
>   
>> Hi,
>>
>> On Sun, 18 Feb 2007, Christopher Olsen wrote:
>>     
>>> Actually I have a version 2 to my patch which I will forward in by
>>> tomorrow which allows for vnc authentication..
>>>       
>> Which one? AFAICT there are three authentication methods, one of which is
>> not secure at all. Another one is no vnc authentication at all, but rather
>> an ssh authentication. The third method does not encrypt the rest of the
>> protocol, so is not secure. (And yes, there exists a fourth method, which
>> appears to be purely VNC, but which is not open source.)
>>
>> Ciao,
>> Dscho
>>
>> P.S.: I forgot to mention that your patch is not in unified format, which
>> seems to be the preferred patch format on this list.
>>
>>
>>
>> _______________________________________________
>> Qemu-devel mailing list
>> Qemu-devel@nongnu.org
>> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>>     
>
>   

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-19  2:01           ` Anthony Liguori
@ 2007-02-19  2:11             ` Johannes Schindelin
  2007-02-19  2:48               ` Anthony Liguori
  2007-02-19 17:30               ` Daniel P. Berrange
  0 siblings, 2 replies; 49+ messages in thread
From: Johannes Schindelin @ 2007-02-19  2:11 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: qemu-devel

Hi,

On Sun, 18 Feb 2007, Anthony Liguori wrote:

> Christopher Olsen wrote:
> > Sorry I'll attempt to use the preferred patching method in the future..
> > 
> > Secure vnc auth method the default built in method from
> >   
> 
> We can't take a password from a command line.  Supporting VNC auth is 
> super easy otherwise.  I really think we need to have a config file 
> before we can do VNC passwords.

No, you should not do VNC passwords. The default VNC password exchange is 
insecure and you should not lure users into believing in that false 
security.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-19  2:11             ` Johannes Schindelin
@ 2007-02-19  2:48               ` Anthony Liguori
  2007-02-19 12:19                 ` Christopher Olsen
  2007-02-19 17:30               ` Daniel P. Berrange
  1 sibling, 1 reply; 49+ messages in thread
From: Anthony Liguori @ 2007-02-19  2:48 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: qemu-devel

Johannes Schindelin wrote:
> Hi,
>
> On Sun, 18 Feb 2007, Anthony Liguori wrote:
>
>   
>> Christopher Olsen wrote:
>>     
>>> Sorry I'll attempt to use the preferred patching method in the future..
>>>
>>> Secure vnc auth method the default built in method from
>>>   
>>>       
>> We can't take a password from a command line.  Supporting VNC auth is 
>> super easy otherwise.  I really think we need to have a config file 
>> before we can do VNC passwords.
>>     
>
> No, you should not do VNC passwords. The default VNC password exchange is 
> insecure and you should not lure users into believing in that false 
> security.
>   

I actually agree with you.

Regards,

Anthony Liguori

> Ciao,
> Dscho
>
>
>   

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-19  2:48               ` Anthony Liguori
@ 2007-02-19 12:19                 ` Christopher Olsen
  2007-02-19 14:53                   ` Johannes Schindelin
  0 siblings, 1 reply; 49+ messages in thread
From: Christopher Olsen @ 2007-02-19 12:19 UTC (permalink / raw)
  To: qemu-devel

In regards to all this

Johannes... You're correct the challenge response method for authentication 
inside of VNC isn't secure at all it's like locking your screen door at home 
will keep most people out just not the ones who really want to get in...

I've done some further thought and investigation and as far as using QEMU 
inside a Unix environment, I see no reason as to why the authentication 
couldn't be tied into PAM...

Any thoughts?

-Christopher


On Sunday 18 February 2007 21:48, Anthony Liguori wrote:
> Johannes Schindelin wrote:
> > Hi,
> >
> > On Sun, 18 Feb 2007, Anthony Liguori wrote:
> >> Christopher Olsen wrote:
> >>> Sorry I'll attempt to use the preferred patching method in the future..
> >>>
> >>> Secure vnc auth method the default built in method from
> >>
> >> We can't take a password from a command line.  Supporting VNC auth is
> >> super easy otherwise.  I really think we need to have a config file
> >> before we can do VNC passwords.
> >
> > No, you should not do VNC passwords. The default VNC password exchange is
> > insecure and you should not lure users into believing in that false
> > security.
>
> I actually agree with you.
>
> Regards,
>
> Anthony Liguori
>
> > Ciao,
> > Dscho
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

-- 
Christopher Olsen
cwolsen@domainatlantic.com
Tel: 631-676-4877
Fax: 631-249-3036

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-19 12:19                 ` Christopher Olsen
@ 2007-02-19 14:53                   ` Johannes Schindelin
  2007-02-19 17:16                     ` Christopher Olsen
  0 siblings, 1 reply; 49+ messages in thread
From: Johannes Schindelin @ 2007-02-19 14:53 UTC (permalink / raw)
  To: Christopher Olsen; +Cc: qemu-devel

Hi,

On Mon, 19 Feb 2007, Christopher Olsen wrote:

> I've done some further thought and investigation and as far as using 
> QEMU inside a Unix environment, I see no reason as to why the 
> authentication couldn't be tied into PAM...

Because this is supposed to be a standard protocol, meant for widespread 
use, not just on Unix.

I see many developments in the VNC protocol lately, which only target one 
special use case. Which is quite sad, because I think that with just a 
little more thought the results would be so much more useful for others, 
too.

See for example the inbuilt VNC server in QEmu. It does not exchange any 
code with any other VNC implementation. So, every improvement in this or 
that implementation is lost on all the others. Like I said, sad.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-19 14:53                   ` Johannes Schindelin
@ 2007-02-19 17:16                     ` Christopher Olsen
  0 siblings, 0 replies; 49+ messages in thread
From: Christopher Olsen @ 2007-02-19 17:16 UTC (permalink / raw)
  To: qemu-devel

Understandable...

However I'm not sure about others and how they intend to use QEMU.. But I for 
one know that I do have a use for authentication within the VNC session.. 

You're right that it's supposed to be a standard protocol but it doesn't 
appread to be from the many different flavors of VNC i've seen and how they 
license it.

-Christopher


On Monday 19 February 2007 09:53, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 19 Feb 2007, Christopher Olsen wrote:
> > I've done some further thought and investigation and as far as using
> > QEMU inside a Unix environment, I see no reason as to why the
> > authentication couldn't be tied into PAM...
>
> Because this is supposed to be a standard protocol, meant for widespread
> use, not just on Unix.
>
> I see many developments in the VNC protocol lately, which only target one
> special use case. Which is quite sad, because I think that with just a
> little more thought the results would be so much more useful for others,
> too.
>
> See for example the inbuilt VNC server in QEmu. It does not exchange any
> code with any other VNC implementation. So, every improvement in this or
> that implementation is lost on all the others. Like I said, sad.
>
> Ciao,
> Dscho
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

-- 
Christopher Olsen
cwolsen@domainatlantic.com
Tel: 631-676-4877
Fax: 631-249-3036

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-19  2:11             ` Johannes Schindelin
  2007-02-19  2:48               ` Anthony Liguori
@ 2007-02-19 17:30               ` Daniel P. Berrange
  2007-02-19 17:41                 ` Christopher Olsen
  1 sibling, 1 reply; 49+ messages in thread
From: Daniel P. Berrange @ 2007-02-19 17:30 UTC (permalink / raw)
  To: qemu-devel; +Cc: Anthony Liguori

On Mon, Feb 19, 2007 at 03:11:15AM +0100, Johannes Schindelin wrote:
> Hi,
> 
> On Sun, 18 Feb 2007, Anthony Liguori wrote:
> 
> > Christopher Olsen wrote:
> > > Sorry I'll attempt to use the preferred patching method in the future..
> > > 
> > > Secure vnc auth method the default built in method from
> > >   
> > 
> > We can't take a password from a command line.  Supporting VNC auth is 
> > super easy otherwise.  I really think we need to have a config file 
> > before we can do VNC passwords.
> 
> No, you should not do VNC passwords. The default VNC password exchange is 
> insecure and you should not lure users into believing in that false 
> security.

Sure it is insecure over an unencrypted network channel, but if you are
tunnelling the VNC connection over SSH, or have restricted it to only
bind to 127.0.0.1  then AFAIK it is just fine. So supporting VNC password
auth would allow users on a shared machine to secure the console from
other unprivileged users on the same box. Definitely useful over the
current situation where there's no way to secure even the local-only
case. For a serious general purpose authentication I'd like to see the
TLS protocol extension for VNC (as implemented in VeNCrypt) supported
allowing both secure auth & wire encryption.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-19 17:30               ` Daniel P. Berrange
@ 2007-02-19 17:41                 ` Christopher Olsen
  2007-02-19 19:09                   ` Daniel P. Berrange
  0 siblings, 1 reply; 49+ messages in thread
From: Christopher Olsen @ 2007-02-19 17:41 UTC (permalink / raw)
  To: Daniel P. Berrange, qemu-devel


On Monday 19 February 2007 12:30, Daniel P. Berrange wrote:
> On Mon, Feb 19, 2007 at 03:11:15AM +0100, Johannes Schindelin wrote:
> > Hi,
> >
> > On Sun, 18 Feb 2007, Anthony Liguori wrote:
> > > Christopher Olsen wrote:
> > > > Sorry I'll attempt to use the preferred patching method in the
> > > > future..
> > > >
> > > > Secure vnc auth method the default built in method from
> > >
> > > We can't take a password from a command line.  Supporting VNC auth is
> > > super easy otherwise.  I really think we need to have a config file
> > > before we can do VNC passwords.
> >
> > No, you should not do VNC passwords. The default VNC password exchange is
> > insecure and you should not lure users into believing in that false
> > security.
>
> Sure it is insecure over an unencrypted network channel, but if you are
> tunnelling the VNC connection over SSH, or have restricted it to only
> bind to 127.0.0.1  then AFAIK it is just fine. So supporting VNC password
> auth would allow users on a shared machine to secure the console from
> other unprivileged users on the same box. Definitely useful over the
> current situation where there's no way to secure even the local-only
> case. For a serious general purpose authentication I'd like to see the
> TLS protocol extension for VNC (as implemented in VeNCrypt) supported
> allowing both secure auth & wire encryption.
>
> Dan.

I've Checked out the VeNCrypt.. Looks a little win32 oriented... 

I'm gathering the problem here is that VNC is spinning off in many 
directions...  So any implementation on the QEMU side will of course marry it 
to a particular VNC branch or I had an alternative idea..

That being the authentication can take place inside the VNC before the VM's 
frame buffer is attached.. This way whichever VNC client the enduser is using 
they can auth in.

-Christopher


-- 
Christopher Olsen
cwolsen@domainatlantic.com
Tel: 631-676-4877
Fax: 631-249-3036

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-19 17:41                 ` Christopher Olsen
@ 2007-02-19 19:09                   ` Daniel P. Berrange
  2007-02-19 19:29                     ` Christopher Olsen
  2007-02-19 22:52                     ` Fabrice Bellard
  0 siblings, 2 replies; 49+ messages in thread
From: Daniel P. Berrange @ 2007-02-19 19:09 UTC (permalink / raw)
  To: Christopher Olsen; +Cc: qemu-devel

On Mon, Feb 19, 2007 at 12:41:53PM -0500, Christopher Olsen wrote:
> 
> On Monday 19 February 2007 12:30, Daniel P. Berrange wrote:
> > On Mon, Feb 19, 2007 at 03:11:15AM +0100, Johannes Schindelin wrote:
> > > Hi,
> > >
> > > On Sun, 18 Feb 2007, Anthony Liguori wrote:
> > > > Christopher Olsen wrote:
> > > > > Sorry I'll attempt to use the preferred patching method in the
> > > > > future..
> > > > >
> > > > > Secure vnc auth method the default built in method from
> > > >
> > > > We can't take a password from a command line.  Supporting VNC auth is
> > > > super easy otherwise.  I really think we need to have a config file
> > > > before we can do VNC passwords.
> > >
> > > No, you should not do VNC passwords. The default VNC password exchange is
> > > insecure and you should not lure users into believing in that false
> > > security.
> >
> > Sure it is insecure over an unencrypted network channel, but if you are
> > tunnelling the VNC connection over SSH, or have restricted it to only
> > bind to 127.0.0.1  then AFAIK it is just fine. So supporting VNC password
> > auth would allow users on a shared machine to secure the console from
> > other unprivileged users on the same box. Definitely useful over the
> > current situation where there's no way to secure even the local-only
> > case. For a serious general purpose authentication I'd like to see the
> > TLS protocol extension for VNC (as implemented in VeNCrypt) supported
> > allowing both secure auth & wire encryption.
> >
> > Dan.
> 
> I've Checked out the VeNCrypt.. Looks a little win32 oriented... 

Guess you missed the 'unix' directory - I have compiled both server & client
of VeNCrypt on Linux no trouble.

> I'm gathering the problem here is that VNC is spinning off in many 
> directions...  So any implementation on the QEMU side will of course marry it 
> to a particular VNC branch or I had an alternative idea..

I think the crux of the matter is that RealVNC sell a commercial version
of VNC which offers real encryption. So I'm guessing that's why they've
never merged any of the patches to do TLS encryption in the open source
codebase. All the patches for VNC + TLS i've seen posted are iterations
of each other - VeNCrypt is the most complete implenentation of any of
them, so the one I'd go for out of the all the choices. 

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-19 19:09                   ` Daniel P. Berrange
@ 2007-02-19 19:29                     ` Christopher Olsen
  2007-02-19 22:52                     ` Fabrice Bellard
  1 sibling, 0 replies; 49+ messages in thread
From: Christopher Olsen @ 2007-02-19 19:29 UTC (permalink / raw)
  To: Daniel P. Berrange, qemu-devel

On Monday 19 February 2007 14:09, Daniel P. Berrange wrote:
> Guess you missed the 'unix' directory - I have compiled both server &
> client of VeNCrypt on Linux no trouble.
>
> > I'm gathering the problem here is that VNC is spinning off in many
> > directions...  So any implementation on the QEMU side will of course
> > marry it to a particular VNC branch or I had an alternative idea..
>
> I think the crux of the matter is that RealVNC sell a commercial version
> of VNC which offers real encryption. So I'm guessing that's why they've
> never merged any of the patches to do TLS encryption in the open source
> codebase. All the patches for VNC + TLS i've seen posted are iterations
> of each other - VeNCrypt is the most complete implenentation of any of
> them, so the one I'd go for out of the all the choices.
>
> Regards,
> Dan.

I will take some further investigation into VeNCrypt.. I may have looked over 
it too quickly.

If it seams feasible then I will move  forward with it later today provide 
that no wheels are in motion to this and/or there are no real objections to 
it.

-Christopher



-- 
Christopher Olsen
cwolsen@domainatlantic.com
Tel: 631-676-4877
Fax: 631-249-3036

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-19 19:09                   ` Daniel P. Berrange
  2007-02-19 19:29                     ` Christopher Olsen
@ 2007-02-19 22:52                     ` Fabrice Bellard
  2007-02-19 23:37                       ` Christopher Olsen
  2007-02-19 23:58                       ` [Qemu-devel] QEMU: VNC Johannes Schindelin
  1 sibling, 2 replies; 49+ messages in thread
From: Fabrice Bellard @ 2007-02-19 22:52 UTC (permalink / raw)
  To: qemu-devel

Daniel P. Berrange wrote:
> On Mon, Feb 19, 2007 at 12:41:53PM -0500, Christopher Olsen wrote:
>> On Monday 19 February 2007 12:30, Daniel P. Berrange wrote:
>>> On Mon, Feb 19, 2007 at 03:11:15AM +0100, Johannes Schindelin wrote:
>>>> Hi,
>>>>
>>>> On Sun, 18 Feb 2007, Anthony Liguori wrote:
>>>>> Christopher Olsen wrote:
>>>>>> Sorry I'll attempt to use the preferred patching method in the
>>>>>> future..
>>>>>>
>>>>>> Secure vnc auth method the default built in method from
>>>>> We can't take a password from a command line.  Supporting VNC auth is
>>>>> super easy otherwise.  I really think we need to have a config file
>>>>> before we can do VNC passwords.
>>>> No, you should not do VNC passwords. The default VNC password exchange is
>>>> insecure and you should not lure users into believing in that false
>>>> security.
>>> Sure it is insecure over an unencrypted network channel, but if you are
>>> tunnelling the VNC connection over SSH, or have restricted it to only
>>> bind to 127.0.0.1  then AFAIK it is just fine. So supporting VNC password
>>> auth would allow users on a shared machine to secure the console from
>>> other unprivileged users on the same box. Definitely useful over the
>>> current situation where there's no way to secure even the local-only
>>> case. For a serious general purpose authentication I'd like to see the
>>> TLS protocol extension for VNC (as implemented in VeNCrypt) supported
>>> allowing both secure auth & wire encryption.
>>>
>>> Dan.
>> I've Checked out the VeNCrypt.. Looks a little win32 oriented... 
> 
> Guess you missed the 'unix' directory - I have compiled both server & client
> of VeNCrypt on Linux no trouble.
> 
>> I'm gathering the problem here is that VNC is spinning off in many 
>> directions...  So any implementation on the QEMU side will of course marry it 
>> to a particular VNC branch or I had an alternative idea..
> 
> I think the crux of the matter is that RealVNC sell a commercial version
> of VNC which offers real encryption. So I'm guessing that's why they've
> never merged any of the patches to do TLS encryption in the open source
> codebase. All the patches for VNC + TLS i've seen posted are iterations
> of each other - VeNCrypt is the most complete implenentation of any of
> them, so the one I'd go for out of the all the choices. 

On the technical side, adding OpenSSL support in the current VNC 
implementation is QEMU seems easy (OpenSSL has a non blocking API which 
can be used with the current callback API).

Fabrice.

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-19 22:52                     ` Fabrice Bellard
@ 2007-02-19 23:37                       ` Christopher Olsen
  2007-02-20  0:36                         ` Daniel P. Berrange
  2007-02-19 23:58                       ` [Qemu-devel] QEMU: VNC Johannes Schindelin
  1 sibling, 1 reply; 49+ messages in thread
From: Christopher Olsen @ 2007-02-19 23:37 UTC (permalink / raw)
  To: qemu-devel

On Monday 19 February 2007 17:52, Fabrice Bellard wrote:
>
> On the technical side, adding OpenSSL support in the current VNC
> implementation is QEMU seems easy (OpenSSL has a non blocking API which
> can be used with the current callback API).
>
> Fabrice.
>

Good call... Let me look into that.

-Christopher


-- 
Christopher Olsen
cwolsen@domainatlantic.com
Tel: 631-676-4877
Fax: 631-249-3036

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-19 22:52                     ` Fabrice Bellard
  2007-02-19 23:37                       ` Christopher Olsen
@ 2007-02-19 23:58                       ` Johannes Schindelin
  1 sibling, 0 replies; 49+ messages in thread
From: Johannes Schindelin @ 2007-02-19 23:58 UTC (permalink / raw)
  To: Fabrice Bellard; +Cc: qemu-devel

Hi,

On Mon, 19 Feb 2007, Fabrice Bellard wrote:

> On the technical side, adding OpenSSL support in the current VNC 
> implementation is QEMU seems easy (OpenSSL has a non blocking API which 
> can be used with the current callback API).

Goodbye compatibility.

I mean, you _can_ just ask for breakage of a standard.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-19 23:37                       ` Christopher Olsen
@ 2007-02-20  0:36                         ` Daniel P. Berrange
  2007-02-20  0:45                           ` Anthony Liguori
  0 siblings, 1 reply; 49+ messages in thread
From: Daniel P. Berrange @ 2007-02-20  0:36 UTC (permalink / raw)
  To: qemu-devel

On Mon, Feb 19, 2007 at 06:37:39PM -0500, Christopher Olsen wrote:
> On Monday 19 February 2007 17:52, Fabrice Bellard wrote:
> >
> > On the technical side, adding OpenSSL support in the current VNC
> > implementation is QEMU seems easy (OpenSSL has a non blocking API which
> > can be used with the current callback API).
> >
> > Fabrice.
> >
> 
> Good call... Let me look into that.

Actually OpenSSL has some potential licensing issues when combined with
GPL code so I'd avoid it. The GNU TLS library, however, is just as easy
to integrate into existing programs - I've modified a number of apps to
use it very successfully.  Or if you want support for all manner of
crypto key management hardware devices, there's also Mozilla NSS libraries.
All support non-blocking APIs, so aside from the extra code to do the TLS
handshake and key verification, there's little modification needed to
the main codebase - eg for GNU TLS once handshake is complete you can
simply  replace read()/write() calls with gnutls_read() / gnutls_write()


Regards,
Dan.

[1] http://lists.debian.org/debian-legal/2004/05/msg00595.html
    http://www.gnome.org/~markmc/openssl-and-the-gpl.html
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-20  0:36                         ` Daniel P. Berrange
@ 2007-02-20  0:45                           ` Anthony Liguori
  2007-02-20  0:53                             ` Christopher Olsen
  2007-02-20  1:05                             ` Daniel P. Berrange
  0 siblings, 2 replies; 49+ messages in thread
From: Anthony Liguori @ 2007-02-20  0:45 UTC (permalink / raw)
  To: Daniel P. Berrange, qemu-devel

Daniel P. Berrange wrote:
> On Mon, Feb 19, 2007 at 06:37:39PM -0500, Christopher Olsen wrote:
>   
>> On Monday 19 February 2007 17:52, Fabrice Bellard wrote:
>>     
>>> On the technical side, adding OpenSSL support in the current VNC
>>> implementation is QEMU seems easy (OpenSSL has a non blocking API which
>>> can be used with the current callback API).
>>>
>>> Fabrice.
>>>
>>>       
>> Good call... Let me look into that.
>>     
>
> Actually OpenSSL has some potential licensing issues when combined with
> GPL code so I'd avoid it. The GNU TLS library, however, is just as easy
> to integrate into existing programs - I've modified a number of apps to
> use it very successfully.  Or if you want support for all manner of
> crypto key management hardware devices, there's also Mozilla NSS libraries.
> All support non-blocking APIs, so aside from the extra code to do the TLS
> handshake and key verification, there's little modification needed to
> the main codebase - eg for GNU TLS once handshake is complete you can
> simply  replace read()/write() calls with gnutls_read() / gnutls_write()
>   

While this is all well and good, there is still the fundamental problem 
of how does one associate credentials with a VM.  The actual security 
mechanism is, IMHO, just an implementation detail.

Regards,

Anthony Liguori

> Regards,
> Dan.
>
> [1] http://lists.debian.org/debian-legal/2004/05/msg00595.html
>     http://www.gnome.org/~markmc/openssl-and-the-gpl.html
>   

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-20  0:45                           ` Anthony Liguori
@ 2007-02-20  0:53                             ` Christopher Olsen
  2007-02-20  1:05                             ` Daniel P. Berrange
  1 sibling, 0 replies; 49+ messages in thread
From: Christopher Olsen @ 2007-02-20  0:53 UTC (permalink / raw)
  To: qemu-devel

On Monday 19 February 2007 19:45, Anthony Liguori wrote:
> While this is all well and good, there is still the fundamental problem
> of how does one associate credentials with a VM.  The actual security
> mechanism is, IMHO, just an implementation detail.
>
> Regards,
>
> Anthony Liguori
>

Very true... So why not have QEMU contain it's own list of credentials? 
independent from the host system.. After all it is designed to produce VM's 

Though my anticipated direction of QEMU and everyone else could be completely 
different. I for one know I'm on the hunt for an opensource product similar 
to VMware's ESX server which for simpler terms is a scaled up version of 
VMware Workstation running on a modified Linux kernel.

But for all intended purposes authentication into a VM could be beneficial to 
everyone collectively.

-Christopher

-- 
Christopher Olsen
cwolsen@domainatlantic.com
Tel: 631-676-4877
Fax: 631-249-3036

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-20  0:45                           ` Anthony Liguori
  2007-02-20  0:53                             ` Christopher Olsen
@ 2007-02-20  1:05                             ` Daniel P. Berrange
  2007-02-20  1:11                               ` Johannes Schindelin
  2007-02-20  1:15                               ` [Qemu-devel] FreeBSD Support Christopher Olsen
  1 sibling, 2 replies; 49+ messages in thread
From: Daniel P. Berrange @ 2007-02-20  1:05 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: qemu-devel

On Mon, Feb 19, 2007 at 06:45:54PM -0600, Anthony Liguori wrote:
> Daniel P. Berrange wrote:
> >On Mon, Feb 19, 2007 at 06:37:39PM -0500, Christopher Olsen wrote:
> >  
> >>On Monday 19 February 2007 17:52, Fabrice Bellard wrote:
> >>    
> >>>On the technical side, adding OpenSSL support in the current VNC
> >>>implementation is QEMU seems easy (OpenSSL has a non blocking API which
> >>>can be used with the current callback API).
> >>>
> >>>Fabrice.
> >>>
> >>>      
> >>Good call... Let me look into that.
> >>    
> >
> >Actually OpenSSL has some potential licensing issues when combined with
> >GPL code so I'd avoid it. The GNU TLS library, however, is just as easy
> >to integrate into existing programs - I've modified a number of apps to
> >use it very successfully.  Or if you want support for all manner of
> >crypto key management hardware devices, there's also Mozilla NSS libraries.
> >All support non-blocking APIs, so aside from the extra code to do the TLS
> >handshake and key verification, there's little modification needed to
> >the main codebase - eg for GNU TLS once handshake is complete you can
> >simply  replace read()/write() calls with gnutls_read() / gnutls_write()
> >  
> 
> While this is all well and good, there is still the fundamental problem 
> of how does one associate credentials with a VM.  The actual security 
> mechanism is, IMHO, just an implementation detail.

Well there's a number of plausible options 

 - Password, but using challenge/resonse (either plain or TLS channel)
 - Simple  password (assuming a TLS encypted channel)
 - Whitelist based on client TLS certificate (common name/fingerprint)
 - Auth against PAM using same username of qemu process owner (asume TLS)

While in general I don't think it makes much sense to tie it into the 
host system auth scheme (because VM administrators don't map onto UNIX
accounts in the general case), the latter would be useful for developers
not wishing to setup dedicated auth. There's probably more suggestions,
but I reckon those would cover a pretty wide base of deployment scenarios
from individual developers to large corporate deployment.

I wouldn't really want to translate all these schemes into a 1000 command
line flags though, so the earlier point in the thread about a QEMU config
file becomes very relevant

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-20  1:05                             ` Daniel P. Berrange
@ 2007-02-20  1:11                               ` Johannes Schindelin
  2007-02-20  1:18                                 ` Christopher Olsen
  2007-02-20 19:46                                 ` Joe Batt
  2007-02-20  1:15                               ` [Qemu-devel] FreeBSD Support Christopher Olsen
  1 sibling, 2 replies; 49+ messages in thread
From: Johannes Schindelin @ 2007-02-20  1:11 UTC (permalink / raw)
  To: Daniel P. Berrange; +Cc: qemu-devel, Anthony Liguori

Hi,

On Tue, 20 Feb 2007, Daniel P. Berrange wrote:

> Well there's a number of plausible options 
> 
>  - Password, but using challenge/resonse (either plain or TLS channel)
>  - Simple  password (assuming a TLS encypted channel)
>  - Whitelist based on client TLS certificate (common name/fingerprint)
>  - Auth against PAM using same username of qemu process owner (asume TLS)

or just

- create a pipe(), fork() and be unbothered by any authentication.

Of course, QEmu's VNC server would have to be taught to communicate via 
stdio.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Qemu-devel] FreeBSD Support
  2007-02-20  1:05                             ` Daniel P. Berrange
  2007-02-20  1:11                               ` Johannes Schindelin
@ 2007-02-20  1:15                               ` Christopher Olsen
  2007-02-20  1:46                                 ` Paul Brook
  1 sibling, 1 reply; 49+ messages in thread
From: Christopher Olsen @ 2007-02-20  1:15 UTC (permalink / raw)
  To: qemu-devel

This is a sidetrack here... But is it at all possible to make future releases 
of the source more FreeBSD friendly?

I am willing to work off a specified codebase to bring it up to FreeBSD speed 
so it can be easily maintained from there... 

Because unfortunately out of the box it doesn't build.

-Christopher

-- 
Christopher Olsen
cwolsen@domainatlantic.com
Tel: 631-676-4877
Fax: 631-249-3036

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-20  1:11                               ` Johannes Schindelin
@ 2007-02-20  1:18                                 ` Christopher Olsen
  2007-02-20 19:46                                 ` Joe Batt
  1 sibling, 0 replies; 49+ messages in thread
From: Christopher Olsen @ 2007-02-20  1:18 UTC (permalink / raw)
  To: qemu-devel

On Monday 19 February 2007 20:11, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 20 Feb 2007, Daniel P. Berrange wrote:
> > Well there's a number of plausible options
> >
> >  - Password, but using challenge/resonse (either plain or TLS channel)
> >  - Simple  password (assuming a TLS encypted channel)
> >  - Whitelist based on client TLS certificate (common name/fingerprint)
> >  - Auth against PAM using same username of qemu process owner (asume TLS)
>
> or just
>
> - create a pipe(), fork() and be unbothered by any authentication.
>
> Of course, QEmu's VNC server would have to be taught to communicate via
> stdio.
>
> Ciao,
> Dscho
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

That's well and good but as pointed out by Anthony how does one verify 
credentials with the VM over VNC or what ever future protocol there is..

This could be something designed more native into it as I could see in the 
future the possability of remote configuration of VM's over some interface 
yet to come.

-Christopher

-- 
Christopher Olsen
cwolsen@domainatlantic.com
Tel: 631-676-4877
Fax: 631-249-3036

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] FreeBSD Support
  2007-02-20  1:15                               ` [Qemu-devel] FreeBSD Support Christopher Olsen
@ 2007-02-20  1:46                                 ` Paul Brook
  2007-02-20  2:10                                   ` Christopher Olsen
  0 siblings, 1 reply; 49+ messages in thread
From: Paul Brook @ 2007-02-20  1:46 UTC (permalink / raw)
  To: qemu-devel; +Cc: Christopher Olsen

> This is a sidetrack here... But is it at all possible to make future
> releases of the source more FreeBSD friendly?

If someone puts in the effort to make it so, yes.

Note that dumping the current patches from FreeBSD ports on the list is 
generally not sufficient. Blindly posting patches without explanation is a 
good way to get them ignored.

All patches should include a description of what they are fixing (ie. what 
qemu currently does wrong), how the patch fixes it, and why this is the right 
way to fix it. For OS specific hacks there needs to be a good reason why that 
OS is special. 
If you can't answer all the above questions then you shouldn't be submitting 
the patch. In some cases you may need to rewriting the patches to meet these 
criteria. Individual OS/Distros tend to be less picky because they only care 
whether the result works on that one system.

Paul

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] FreeBSD Support
  2007-02-20  1:46                                 ` Paul Brook
@ 2007-02-20  2:10                                   ` Christopher Olsen
  2007-02-20  2:41                                     ` Paul Brook
  0 siblings, 1 reply; 49+ messages in thread
From: Christopher Olsen @ 2007-02-20  2:10 UTC (permalink / raw)
  To: qemu-devel

On Monday 19 February 2007 20:46, Paul Brook wrote:
> > This is a sidetrack here... But is it at all possible to make future
> > releases of the source more FreeBSD friendly?
>
> If someone puts in the effort to make it so, yes.
>
> Note that dumping the current patches from FreeBSD ports on the list is
> generally not sufficient. Blindly posting patches without explanation is a
> good way to get them ignored.
>
> All patches should include a description of what they are fixing (ie. what
> qemu currently does wrong), how the patch fixes it, and why this is the
> right way to fix it. For OS specific hacks there needs to be a good reason
> why that OS is special.
> If you can't answer all the above questions then you shouldn't be
> submitting the patch. In some cases you may need to rewriting the patches
> to meet these criteria. Individual OS/Distros tend to be less picky because
> they only care whether the result works on that one system.
>
> Paul
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Paul,

So should I make a separate patch for each modified file?

-Christopher

-- 
Christopher Olsen
cwolsen@domainatlantic.com
Tel: 631-676-4877
Fax: 631-249-3036

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] FreeBSD Support
  2007-02-20  2:10                                   ` Christopher Olsen
@ 2007-02-20  2:41                                     ` Paul Brook
  2007-02-20  3:26                                       ` Christopher Olsen
  0 siblings, 1 reply; 49+ messages in thread
From: Paul Brook @ 2007-02-20  2:41 UTC (permalink / raw)
  To: qemu-devel; +Cc: Christopher Olsen

> So should I make a separate patch for each modified file?

No. You should break changes into logically independent patches.
It is ok for a single patch to touch multiple files, but it should only fix 
one thing.

Paul

^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Qemu-devel] FreeBSD Support
  2007-02-20  2:41                                     ` Paul Brook
@ 2007-02-20  3:26                                       ` Christopher Olsen
  2007-02-24 19:08                                         ` Juergen Lock
  2007-02-26  0:12                                         ` andrzej zaborowski
  0 siblings, 2 replies; 49+ messages in thread
From: Christopher Olsen @ 2007-02-20  3:26 UTC (permalink / raw)
  To: qemu-devel

[-- Attachment #1: Type: text/plain, Size: 758 bytes --]

Ok FreeBSD Support round one..

Be gentle this is my first attempt at working with the rest of this 
community..

Files it modifies and the reasons are as follows

configure - Adds HOST_FREEBSD type to alter included libraries FreeBSD does 
not need -ltr 
Makefile.target - Once again uses HOST_FREEBSD to avoid including -ltr

osdeps.c - FreeBSD does not have /dev/shm so it uses /tmp for kqemu_valloc 
also sys/vfs.h is not part of freebsd stat information is part of 
mount.h/param.h

vl.c - FreeBSD needs module if_tap for tap not default in kernel and fopen the 
tap device with a workaround for FreeBSD related issues for incrementing the 
tap device

-Christopher


-- 
Christopher Olsen
cwolsen@domainatlantic.com
Tel: 631-676-4877
Fax: 631-249-3036

[-- Attachment #2: qemu.freebsd.patch --]
[-- Type: text/x-diff, Size: 4093 bytes --]

--- configure	Mon Feb 19 21:49:15 2007
+++ /home/reddawg/qemu-0.9.0/configure	Mon Feb 19 21:00:11 2007
@@ -111,6 +111,7 @@
 ;;
 FreeBSD)
 bsd="yes"
+freebsd="yes"
 oss="yes"
 if [ "$cpu" = "i386" -o "$cpu" = "x86_64" ] ; then
     kqemu="yes"
@@ -719,6 +720,10 @@
 if test "$solaris" = "yes" ; then
   echo "CONFIG_SOLARIS=yes" >> $config_mak
   echo "#define HOST_SOLARIS $solarisrev" >> $config_h
+fi
+if test "$freebsd" = "yes" ; then
+  echo "CONFIG_FREEBSD=yes" >> $config_mak
+  echo "#define HOST_FREEBSD 1" >> $config_h
 fi
 if test "$gdbstub" = "yes" ; then
   echo "CONFIG_GDBSTUB=yes" >> $config_mak
--- Makefile.target	Mon Feb 19 21:49:15 2007
+++ /home/reddawg/qemu-0.9.0/Makefile.target	Mon Feb 19 21:07:04 2007
@@ -440,7 +440,11 @@
 ifndef CONFIG_DARWIN
 ifndef CONFIG_WIN32
 ifndef CONFIG_SOLARIS
+ifndef CONFIG_FREEBSD
 VL_LIBS=-lutil -lrt
+else
+VL_LIBS=-lutil
+endif
 endif
 endif
 endif
--- osdep.c	Mon Feb 19 22:01:46 2007
+++ /home/reddawg/qemu-0.9.0/osdep.c	Mon Feb 19 21:40:45 2007
@@ -79,7 +79,12 @@
 
 #if defined(USE_KQEMU)
 
+#ifdef HOST_FREEBSD
+#include <sys/param.h>
+#include <sys/mount.h>
+#else
 #include <sys/vfs.h>
+#endif
 #include <sys/mman.h>
 #include <fcntl.h>
 
@@ -102,6 +107,9 @@
 #ifdef HOST_SOLARIS
             tmpdir = "/tmp";
         if (statvfs(tmpdir, &stfs) == 0) {
+#elif HOST_FREEBSD
+            tmpdir = "/tmp";
+        if (statfs(tmpdir, &stfs) == 0) {
 #else
             tmpdir = "/dev/shm";
         if (statfs(tmpdir, &stfs) == 0) {
--- vl.c	Mon Feb 19 22:01:46 2007
+++ /home/reddawg/qemu-0.9.0/vl.c	Mon Feb 19 22:10:06 2007
@@ -47,6 +47,9 @@
 #ifndef __APPLE__
 #include <libutil.h>
 #endif
+#ifdef HOST_FREEBSD 
+#include <sys/module.h>
+#endif
 #else
 #ifndef __sun__
 #include <linux/if.h>
@@ -3171,6 +3174,34 @@
 
 #endif /* CONFIG_SLIRP */
 
+#ifdef HOST_FREEBSD
+
+#define LOAD_QUIETLY   1
+#define LOAD_VERBOSLY  2
+
+/* This function is used to load needed kernel modules for tap */
+int loadmodules(int how, const char *module, ...) {
+  int loaded = 0;
+  va_list ap;
+
+  va_start(ap, module);
+#ifndef NO_MODULES
+  while (module != NULL) {
+    if (modfind(module) == -1) {
+      if (kldload(module) == -1) {
+        if (how == LOAD_VERBOSLY)
+          fprintf(stderr, "%s: Cannot load module\n", module);
+      } else
+        loaded++;
+    }
+    module = va_arg(ap, const char *);
+  }
+  va_end(ap);
+#endif
+  return loaded;
+}
+#endif
+
 #if !defined(_WIN32)
 
 typedef struct TAPState {
@@ -3226,11 +3257,55 @@
     char *dev;
     struct stat s;
 
+#ifdef HOST_FREEBSD
+    int i, kldtried = 0, enoentcount = 0, err = 0;
+    char dname[100];
+#ifdef USE_DEVTAP
+    /*
+     * 5.x has /dev/tap, but that seems to just blindly increase its
+     * couter on every open() for some people(??), i.e. on every qemu run.
+     */
+    i = -1;
+#else
+    i = 0;
+#endif
+    for (; i < 10; i++) {
+        if (i == -1)
+           strcpy(dname, "/dev/tap");
+        else
+           snprintf(dname, sizeof dname, "%s%d",
+                    "/dev/tap", i);
+        fd = open(dname, O_RDWR);
+        if (fd >= 0)
+            break;
+        else if (errno == ENXIO || errno == ENOENT) {
+            if (i == 0 && !kldtried++) {
+                /*
+                 * Attempt to load the tunnel interface KLD if it isn't loaded
+                 * already.
+                 */
+                if (loadmodules(LOAD_VERBOSLY, "if_tap", NULL))
+                    i = -1;
+                continue;
+            }
+            if (errno != ENOENT || ++enoentcount > 3) {
+                err = errno;
+               break;
+            }
+        } else
+            err = errno;
+    }
+    if (fd < 0) {
+        fprintf(stderr, "warning: could not open %s (%s): no virtual network emulation\n", dname, strerror(err));
+        return -1;
+    }
+#else
     fd = open("/dev/tap", O_RDWR);
     if (fd < 0) {
         fprintf(stderr, "warning: could not open /dev/tap: no virtual network emulation\n");
         return -1;
     }
+#endif
 
     fstat(fd, &s);
     dev = devname(s.st_rdev, S_IFCHR);

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-20  1:11                               ` Johannes Schindelin
  2007-02-20  1:18                                 ` Christopher Olsen
@ 2007-02-20 19:46                                 ` Joe Batt
  1 sibling, 0 replies; 49+ messages in thread
From: Joe Batt @ 2007-02-20 19:46 UTC (permalink / raw)
  To: qemu-devel

Amen!

I was beginning to wonder when we would be integrating the email reader.

It would be nice if vncviewer didn't require a "host:port", but  
instead would also accept a pair of pipes.

pipes are local and can even be anonymous.  host:port is at least  
machine wide and can be net wide.

Joe


On Feb 19, 2007, at 8:11 PM, Johannes Schindelin wrote:

> Hi,
>
> On Tue, 20 Feb 2007, Daniel P. Berrange wrote:
>
>> Well there's a number of plausible options
>>
>>  - Password, but using challenge/resonse (either plain or TLS  
>> channel)
>>  - Simple  password (assuming a TLS encypted channel)
>>  - Whitelist based on client TLS certificate (common name/ 
>> fingerprint)
>>  - Auth against PAM using same username of qemu process owner  
>> (asume TLS)
>
> or just
>
> - create a pipe(), fork() and be unbothered by any authentication.
>
> Of course, QEmu's VNC server would have to be taught to communicate  
> via
> stdio.
>
> Ciao,
> Dscho
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] FreeBSD Support
  2007-02-20  3:26                                       ` Christopher Olsen
@ 2007-02-24 19:08                                         ` Juergen Lock
  2007-02-24 20:54                                           ` Leonardo Reiter
  2007-02-26  0:12                                         ` andrzej zaborowski
  1 sibling, 1 reply; 49+ messages in thread
From: Juergen Lock @ 2007-02-24 19:08 UTC (permalink / raw)
  To: cwolsen; +Cc: qemu-devel

In article <200702192226.45410.cwolsen@domainatlantic.com> you write:
>-=-=-=-=-=-
>
>Ok FreeBSD Support round one..
>
>Be gentle this is my first attempt at working with the rest of this 
>community..
>
>Files it modifies and the reasons are as follows
>
>configure - Adds HOST_FREEBSD type to alter included libraries FreeBSD does 
>not need -ltr 
>Makefile.target - Once again uses HOST_FREEBSD to avoid including -ltr
>
>osdeps.c - FreeBSD does not have /dev/shm so it uses /tmp for kqemu_valloc 
>also sys/vfs.h is not part of freebsd stat information is part of 
>mount.h/param.h
>...

Actually the port simply uses mmap MAP_PRIVATE|MAP_ANON, so no
tempfile is used at all (this is files/patch-osdep.c in the port):

Index: qemu/osdep.c
@@ -79,7 +79,9 @@
 
 #if defined(USE_KQEMU)
 
+#ifndef __FreeBSD__
 #include <sys/vfs.h>
+#endif
 #include <sys/mman.h>
 #include <fcntl.h>
 
@@ -90,6 +92,7 @@
     const char *tmpdir;
     char phys_ram_file[1024];
     void *ptr;
+#ifndef __FreeBSD__
 #ifdef HOST_SOLARIS
     struct statvfs stfs;
 #else
@@ -151,12 +154,20 @@
         }
         unlink(phys_ram_file);
     }
+#endif
     size = (size + 4095) & ~4095;
+#ifndef __FreeBSD__
     ftruncate(phys_ram_fd, phys_ram_size + size);
     ptr = mmap(NULL, 
                size, 
                PROT_WRITE | PROT_READ, MAP_SHARED, 
                phys_ram_fd, phys_ram_size);
+#else
+    ptr = mmap(NULL, 
+               size, 
+               PROT_WRITE | PROT_READ, MAP_PRIVATE|MAP_ANON, 
+               -1, 0);
+#endif
     if (ptr == MAP_FAILED) {
         fprintf(stderr, "Could not map physical memory\n");
         exit(1);

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] FreeBSD Support
  2007-02-24 19:08                                         ` Juergen Lock
@ 2007-02-24 20:54                                           ` Leonardo Reiter
  0 siblings, 0 replies; 49+ messages in thread
From: Leonardo Reiter @ 2007-02-24 20:54 UTC (permalink / raw)
  To: qemu-devel

MAP_PRIVATE|MAP_ANON also works on Solaris.  In fact, Linux is the
only platform where it doesn't work due to a bug in the Linux kernel
as Fabrice mentions:

http://www.qemu.org/kqemu-tech.html#SEC7

Technically on Solaris, /tmp is probably the same thing as
MAP_PRIVATE|MAP_ANON since the filesystem is actually mapped to
virtual memory... however, it's much cleaner to not use a file if not
necessary.  I can post a reworked patch that makes the file mapping
for the Linux case only if anyone's interested, but it's a pretty
simple change.

- Leo Reiter

On 2/24/07, Juergen Lock <nox@jelal.kn-bremen.de> wrote:
> In article <200702192226.45410.cwolsen@domainatlantic.com> you write:
> >-=-=-=-=-=-
> >
> >Ok FreeBSD Support round one..
> >
> >Be gentle this is my first attempt at working with the rest of this
> >community..
> >
> >Files it modifies and the reasons are as follows
> >
> >configure - Adds HOST_FREEBSD type to alter included libraries FreeBSD does
> >not need -ltr
> >Makefile.target - Once again uses HOST_FREEBSD to avoid including -ltr
> >
> >osdeps.c - FreeBSD does not have /dev/shm so it uses /tmp for kqemu_valloc
> >also sys/vfs.h is not part of freebsd stat information is part of
> >mount.h/param.h
> >...
>
> Actually the port simply uses mmap MAP_PRIVATE|MAP_ANON, so no
> tempfile is used at all (this is files/patch-osdep.c in the port):
>
> Index: qemu/osdep.c
> @@ -79,7 +79,9 @@
>
>  #if defined(USE_KQEMU)
>
> +#ifndef __FreeBSD__
>  #include <sys/vfs.h>
> +#endif
>  #include <sys/mman.h>
>  #include <fcntl.h>
>
> @@ -90,6 +92,7 @@
>      const char *tmpdir;
>      char phys_ram_file[1024];
>      void *ptr;
> +#ifndef __FreeBSD__
>  #ifdef HOST_SOLARIS
>      struct statvfs stfs;
>  #else
> @@ -151,12 +154,20 @@
>          }
>          unlink(phys_ram_file);
>      }
> +#endif
>      size = (size + 4095) & ~4095;
> +#ifndef __FreeBSD__
>      ftruncate(phys_ram_fd, phys_ram_size + size);
>      ptr = mmap(NULL,
>                 size,
>                 PROT_WRITE | PROT_READ, MAP_SHARED,
>                 phys_ram_fd, phys_ram_size);
> +#else
> +    ptr = mmap(NULL,
> +               size,
> +               PROT_WRITE | PROT_READ, MAP_PRIVATE|MAP_ANON,
> +               -1, 0);
> +#endif
>      if (ptr == MAP_FAILED) {
>          fprintf(stderr, "Could not map physical memory\n");
>          exit(1);
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] FreeBSD Support
  2007-02-20  3:26                                       ` Christopher Olsen
  2007-02-24 19:08                                         ` Juergen Lock
@ 2007-02-26  0:12                                         ` andrzej zaborowski
  2007-03-03 22:12                                           ` Thiemo Seufer
  1 sibling, 1 reply; 49+ messages in thread
From: andrzej zaborowski @ 2007-02-26  0:12 UTC (permalink / raw)
  To: qemu-devel

Hi,

On 20/02/07, Christopher Olsen <cwolsen@domainatlantic.com> wrote:
> Ok FreeBSD Support round one..
>
> Be gentle this is my first attempt at working with the rest of this
> community..
>
> Files it modifies and the reasons are as follows
>
> configure - Adds HOST_FREEBSD type to alter included libraries FreeBSD does
> not need -ltr
> Makefile.target - Once again uses HOST_FREEBSD to avoid including -ltr

See http://lists.gnu.org/archive/html/qemu-devel/2006-11/msg00166.html
- I believe this is a more appropriate way to select -lrt.

Regards,
Andrew

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] FreeBSD Support
  2007-02-26  0:12                                         ` andrzej zaborowski
@ 2007-03-03 22:12                                           ` Thiemo Seufer
  2007-03-05  7:38                                             ` andrzej zaborowski
  0 siblings, 1 reply; 49+ messages in thread
From: Thiemo Seufer @ 2007-03-03 22:12 UTC (permalink / raw)
  To: andrzej zaborowski; +Cc: qemu-devel

andrzej zaborowski wrote:
> Hi,
> 
> On 20/02/07, Christopher Olsen <cwolsen@domainatlantic.com> wrote:
> >Ok FreeBSD Support round one..
> >
> >Be gentle this is my first attempt at working with the rest of this
> >community..
> >
> >Files it modifies and the reasons are as follows
> >
> >configure - Adds HOST_FREEBSD type to alter included libraries FreeBSD does
> >not need -ltr
> >Makefile.target - Once again uses HOST_FREEBSD to avoid including -ltr
> 
> See http://lists.gnu.org/archive/html/qemu-devel/2006-11/msg00166.html
> - I believe this is a more appropriate way to select -lrt.

The solaris part there looked a bit inconsistent, is the appended
version ok?


Thiemo


Index: qemu-work/Makefile
===================================================================
--- qemu-work.orig/Makefile	2007-02-11 16:10:55.000000000 +0000
+++ qemu-work/Makefile	2007-03-02 21:07:26.000000000 +0000
@@ -24,11 +24,7 @@
 DOCS=
 endif
 
-ifndef CONFIG_DARWIN
-ifndef CONFIG_WIN32
-LIBS+=-lrt
-endif
-endif
+LIBS+=$(AIOLIBS)
 
 all: $(TOOLS) $(DOCS) recurse-all
 
Index: qemu-work/Makefile.target
===================================================================
--- qemu-work.orig/Makefile.target	2007-03-02 20:57:01.000000000 +0000
+++ qemu-work/Makefile.target	2007-03-02 21:01:22.000000000 +0000
@@ -436,6 +436,7 @@
 endif
 
 VL_LDFLAGS=
+VL_LIBS=$(AIOLIBS)
 # specific flags are needed for non soft mmu emulator
 ifdef CONFIG_STATIC
 VL_LDFLAGS+=-static
@@ -446,7 +447,7 @@
 ifndef CONFIG_DARWIN
 ifndef CONFIG_WIN32
 ifndef CONFIG_SOLARIS
-VL_LIBS=-lutil -lrt
+VL_LIBS+=-lutil
 endif
 endif
 endif
Index: qemu-work/configure
===================================================================
--- qemu-work.orig/configure	2007-03-02 20:57:00.000000000 +0000
+++ qemu-work/configure	2007-03-02 21:07:10.000000000 +0000
@@ -159,6 +159,12 @@
   fi
 fi
 
+if [ "$bsd" = "yes" -o "$darwin" = "yes" -o "$solaris" = "yes" -o "$mingw32" = "yes" ] ; then
+    AIOLIBS=
+else
+    AIOLIBS="-lrt"
+fi
+
 # find source path
 source_path=`dirname "$0"`
 if [ -z "$source_path" ]; then
@@ -653,6 +659,7 @@
 echo "CFLAGS=$CFLAGS" >> $config_mak
 echo "LDFLAGS=$LDFLAGS" >> $config_mak
 echo "EXESUF=$EXESUF" >> $config_mak
+echo "AIOLIBS=$AIOLIBS" >> $config_mak
 if test "$cpu" = "i386" ; then
   echo "ARCH=i386" >> $config_mak
   echo "#define HOST_I386 1" >> $config_h

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] FreeBSD Support
  2007-03-03 22:12                                           ` Thiemo Seufer
@ 2007-03-05  7:38                                             ` andrzej zaborowski
  0 siblings, 0 replies; 49+ messages in thread
From: andrzej zaborowski @ 2007-03-05  7:38 UTC (permalink / raw)
  To: Thiemo Seufer; +Cc: qemu-devel

Hi,

On 03/03/07, Thiemo Seufer <ths@networkno.de> wrote:
> andrzej zaborowski wrote:
> > Hi,
> >
> > On 20/02/07, Christopher Olsen <cwolsen@domainatlantic.com> wrote:
> > >Ok FreeBSD Support round one..
> > >
> > >Be gentle this is my first attempt at working with the rest of this
> > >community..
> > >
> > >Files it modifies and the reasons are as follows
> > >
> > >configure - Adds HOST_FREEBSD type to alter included libraries FreeBSD does
> > >not need -ltr
> > >Makefile.target - Once again uses HOST_FREEBSD to avoid including -ltr
> >
> > See http://lists.gnu.org/archive/html/qemu-devel/2006-11/msg00166.html
> > - I believe this is a more appropriate way to select -lrt.
>
> The solaris part there looked a bit inconsistent, is the appended
> version ok?

It works for FreeBSD, I think it's Ok.

Regards,
Andrew

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-22 17:35         ` Johannes Schindelin
@ 2007-02-22 17:55           ` Leonardo Reiter
  0 siblings, 0 replies; 49+ messages in thread
From: Leonardo Reiter @ 2007-02-22 17:55 UTC (permalink / raw)
  To: qemu-devel

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 <Johannes.Schindelin@gmx.de> 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
>

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-22 17:29       ` Anthony Liguori
@ 2007-02-22 17:35         ` Johannes Schindelin
  2007-02-22 17:55           ` Leonardo Reiter
  0 siblings, 1 reply; 49+ messages in thread
From: Johannes Schindelin @ 2007-02-22 17:35 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: Luke-Jr, qemu-devel

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

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-22 17:18     ` Johannes Schindelin
@ 2007-02-22 17:29       ` Anthony Liguori
  2007-02-22 17:35         ` Johannes Schindelin
  0 siblings, 1 reply; 49+ messages in thread
From: Anthony Liguori @ 2007-02-22 17:29 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Luke-Jr, qemu-devel

Johannes Schindelin wrote:
> Hi,
>
> On Thu, 22 Feb 2007, Anthony Liguori wrote:
>
>   
>> Johannes Schindelin wrote:
>>     
>>> On Thu, 22 Feb 2007, Luke-Jr wrote:
>>>
>>>       
>>>> 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.
>>>>     
>>>>         
>
> [Why do you quote me as if Luke was quoted?]
>   

Because thunderbird sucks and did it automagically.

>> 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.
>>     
>
> 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.

Regards,

Anthony Liguori

> Ciao,
> Dscho
>
> BTW Anothony, now that I already have you on the subject of VNC, do you 
> have any plans on making the documentation on 
> http://www.realvnc.com/docs/rfbproto.pdf a little more useful for the 
> extensions you registered?
>
>
>   

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
       [not found]     ` <200702221044.48581.luke@dashjr.org>
@ 2007-02-22 17:27       ` Anthony Liguori
  0 siblings, 0 replies; 49+ messages in thread
From: Anthony Liguori @ 2007-02-22 17:27 UTC (permalink / raw)
  To: Luke -Jr, qemu-devel

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...
>
>   

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-22 16:35   ` Anthony Liguori
  2007-02-22 16:39     ` Christopher Olsen
@ 2007-02-22 17:18     ` Johannes Schindelin
  2007-02-22 17:29       ` Anthony Liguori
       [not found]     ` <200702221044.48581.luke@dashjr.org>
  2 siblings, 1 reply; 49+ messages in thread
From: Johannes Schindelin @ 2007-02-22 17:18 UTC (permalink / raw)
  To: Anthony Liguori; +Cc: Luke-Jr, qemu-devel

Hi,

On Thu, 22 Feb 2007, Anthony Liguori wrote:

> Johannes Schindelin wrote:
> > 
> > On Thu, 22 Feb 2007, Luke-Jr wrote:
> > 
> > > 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.
> > >     

[Why do you quote me as if Luke was quoted?]

> 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.

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

Ciao,
Dscho

BTW Anothony, now that I already have you on the subject of VNC, do you 
have any plans on making the documentation on 
http://www.realvnc.com/docs/rfbproto.pdf a little more useful for the 
extensions you registered?

^ permalink raw reply	[flat|nested] 49+ messages in thread

* RE: [Qemu-devel] QEMU: VNC
  2007-02-22 16:35   ` Anthony Liguori
@ 2007-02-22 16:39     ` Christopher Olsen
  2007-02-22 17:18     ` Johannes Schindelin
       [not found]     ` <200702221044.48581.luke@dashjr.org>
  2 siblings, 0 replies; 49+ messages in thread
From: Christopher Olsen @ 2007-02-22 16:39 UTC (permalink / raw)
  To: qemu-devel

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: qemu-devel-bounces+cwolsen=domainatlantic.com@nongnu.org
[mailto:qemu-devel-bounces+cwolsen=domainatlantic.com@nongnu.org]On
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

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-22 16:22 ` Johannes Schindelin
@ 2007-02-22 16:35   ` Anthony Liguori
  2007-02-22 16:39     ` Christopher Olsen
                       ` (2 more replies)
  0 siblings, 3 replies; 49+ messages in thread
From: Anthony Liguori @ 2007-02-22 16:35 UTC (permalink / raw)
  To: qemu-devel; +Cc: Luke-Jr

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
>>
>>     

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [Qemu-devel] QEMU: VNC
  2007-02-22  5:19 Luke-Jr
@ 2007-02-22 16:22 ` Johannes Schindelin
  2007-02-22 16:35   ` Anthony Liguori
  0 siblings, 1 reply; 49+ messages in thread
From: Johannes Schindelin @ 2007-02-22 16:22 UTC (permalink / raw)
  To: Luke-Jr; +Cc: qemu-devel

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

^ permalink raw reply	[flat|nested] 49+ messages in thread

* [Qemu-devel] QEMU: VNC
@ 2007-02-22  5:19 Luke-Jr
  2007-02-22 16:22 ` Johannes Schindelin
  0 siblings, 1 reply; 49+ messages in thread
From: Luke-Jr @ 2007-02-22  5:19 UTC (permalink / raw)
  To: qemu-devel

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

^ permalink raw reply	[flat|nested] 49+ messages in thread

end of thread, other threads:[~2007-03-05  7:38 UTC | newest]

Thread overview: 49+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-16 19:02 [Qemu-devel] QEMU: VNC Christopher Olsen
2007-02-16 20:57 ` Anthony Liguori
2007-02-18 20:36 ` Christopher Olsen
2007-02-18 23:08   ` Anthony Liguori
2007-02-18 23:53     ` Christopher Olsen
2007-02-19  0:14       ` Johannes Schindelin
2007-02-19  0:30         ` Christopher Olsen
2007-02-19  0:41           ` Johannes Schindelin
2007-02-19  2:01           ` Anthony Liguori
2007-02-19  2:11             ` Johannes Schindelin
2007-02-19  2:48               ` Anthony Liguori
2007-02-19 12:19                 ` Christopher Olsen
2007-02-19 14:53                   ` Johannes Schindelin
2007-02-19 17:16                     ` Christopher Olsen
2007-02-19 17:30               ` Daniel P. Berrange
2007-02-19 17:41                 ` Christopher Olsen
2007-02-19 19:09                   ` Daniel P. Berrange
2007-02-19 19:29                     ` Christopher Olsen
2007-02-19 22:52                     ` Fabrice Bellard
2007-02-19 23:37                       ` Christopher Olsen
2007-02-20  0:36                         ` Daniel P. Berrange
2007-02-20  0:45                           ` Anthony Liguori
2007-02-20  0:53                             ` Christopher Olsen
2007-02-20  1:05                             ` Daniel P. Berrange
2007-02-20  1:11                               ` Johannes Schindelin
2007-02-20  1:18                                 ` Christopher Olsen
2007-02-20 19:46                                 ` Joe Batt
2007-02-20  1:15                               ` [Qemu-devel] FreeBSD Support Christopher Olsen
2007-02-20  1:46                                 ` Paul Brook
2007-02-20  2:10                                   ` Christopher Olsen
2007-02-20  2:41                                     ` Paul Brook
2007-02-20  3:26                                       ` Christopher Olsen
2007-02-24 19:08                                         ` Juergen Lock
2007-02-24 20:54                                           ` Leonardo Reiter
2007-02-26  0:12                                         ` andrzej zaborowski
2007-03-03 22:12                                           ` Thiemo Seufer
2007-03-05  7:38                                             ` andrzej zaborowski
2007-02-19 23:58                       ` [Qemu-devel] QEMU: VNC Johannes Schindelin
2007-02-19  0:11   ` Johannes Schindelin
2007-02-19  0:25     ` Christopher Olsen
2007-02-22  5:19 Luke-Jr
2007-02-22 16:22 ` Johannes Schindelin
2007-02-22 16:35   ` Anthony Liguori
2007-02-22 16:39     ` Christopher Olsen
2007-02-22 17:18     ` Johannes Schindelin
2007-02-22 17:29       ` Anthony Liguori
2007-02-22 17:35         ` Johannes Schindelin
2007-02-22 17:55           ` Leonardo Reiter
     [not found]     ` <200702221044.48581.luke@dashjr.org>
2007-02-22 17:27       ` Anthony Liguori

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.