Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
Avi Kivity wrote: Jorge Lucángeli Obes wrote: My feeling is that config files are outdated. When used with a gui, you end up writing silly parsers and stuff and still wrecking things horribly when the the gui writer's expectations don't match reality. When used without a gui, they increase the amount of details one has to remember (where's that config file? I renamed my image, did I remember to update the config file?). They also make upgrading more difficult. There's only so much that can be expressed on a command line. There are actually limits to the command line size on a lot of platforms. I don't see why reading options from a file is so much worse than reading them from the command line. In my view, the bottom line is: we need an _easy_ way of launching VMs when one doesn't want all the options of the managed approach. I back Avi on this one, I would like to be able to do qemu guest.img Well, I disagree with Avi now. Dan's comment about guest images now being untrusted is a killer. without worrying about configuration files, or XML, or parsing. That's not to say that a global configuration file for QEMU wouldn't be useful, but I think it would solve a different problem. When I read Avi's TODO, I basically thought about getting rid of the long command lines I had to store in scripts. I wanted to write that command line once, and then forgetting about it, until I needed to change it. I wanted an image to be self-contained as much as possible. That's what I set to achieve. All that said, I rethought Anthony's idea of storing plain text in the image and with proper tools, it can work out. I don't like the idea of having users overwriting and padding files, but the approach seems less of a hack than using empty snapshots. In short: I think we will need to have something like 'qemu-img cmdline' anyways, independent of the implementation. That's because I would like an implementation that does not depend on extra files. For that, we already have libvirt and the likes. I like the format-independent nature of Anthony's idea too. Basically we're adding a meta-format that works along with all other formats. Anthony's other idea, to require self-contained images to be executable, may be workable. I have some doubts that it is a sufficient indicator of trust (though with normal shell scripts and executables it is). I know we are not in democracy, but if I can vote I'd like to vote to the idea of Christian Brunschen... We can modify qemu to test if the argument is a directory, if yes, it reads args from file args in this directory and for security the disk image must be in the same directory. for instance, we have: ./pc1/ ./pc1/args ./pc1/my_disk and in ./pc1/args, we have -hda my_disk and when we run qemu pc1, it starts qemu -hda ./pc1/my_disk I don't like the idea of the config file (when it is complex it is very hard to have a correct one like for Xen or like for Xorg) I don't like the idea of Anthony because it looks like a hack . Laurent, the killjoy -- - [EMAIL PROTECTED] -- Software is hard - Donald Knuth signature.asc Description: OpenPGP digital signature
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
On 8/13/07, Laurent Vivier [EMAIL PROTECTED] wrote: I know we are not in democracy, but if I can vote I'd like to vote to the idea of Christian Brunschen... We can modify qemu to test if the argument is a directory, if yes, it reads args from file args in this directory and for security the disk image must be in the same directory. I'd like to also vote for this solution, as I believe it's portable for windows hosts and generic enough to satisfy most needs. Christian
[Qemu-devel] Re: [kvm-devel] [PATCH] Add support for HPET periodic timer.
On 8/13/07, Daniel P. Berrange [EMAIL PROTECTED] wrote: On Mon, Aug 13, 2007 at 11:04:46AM +0300, Avi Kivity wrote: Luca Tettamanti wrote: Something like: - try to use HPET (unless -no-rtc selected) - try to use RTC (unless -no-rtc selected) - fallback to normal unix facilities If we're going to add command line args it probably makes sense to be a little more generic than -no-rtc or -use-hpet. Have a list of preferred clock sources eg -clock hpet,rtc,unix If -clock is omitted, then default to trying all in the priority you describe. Makes sense, I'll prepare a patch (maybe after a couple of days of vacation :P). Luca
[Qemu-devel] [PATCH] qemu: reset buffer pointers after CR/LF
If readline_handle_byte() is sent both a CR and LF, and readline_start() is not called after the first CR, then the LF will cause the same command to be executed a second time. Fix this by explicitly resetting the buffer pointers when it is processed. Signed-off-by: Jim Paris [EMAIL PROTECTED] --- Index: readline.c === RCS file: /sources/qemu/qemu/readline.c,v retrieving revision 1.2 diff -u -r1.2 readline.c --- readline.c 25 Jun 2007 11:36:50 - 1.2 +++ readline.c 13 Aug 2007 16:23:29 - @@ -374,6 +374,10 @@ if (!term_is_password) term_hist_add(term_cmd_buf); term_printf(\n); +term_cmd_buf_index = 0; +term_cmd_buf_size = 0; +term_last_cmd_buf_index = 0; +term_last_cmd_buf_size = 0; /* NOTE: readline_start can be called here */ term_readline_func(term_readline_opaque, term_cmd_buf); break;
Re: [Qemu-devel] PATCH 2/8: Extend monitor 'change' command for VNC
This patch extends the QEMU monitor 'change' command so that it can
be used to change the configuration of the VNC server. On the command
line the user can use -vnc none, and then issue the 'change vnc :1'
command later from the monitor. This is utilized in the next patch
to let the monitor fetch a password for the server. The concept could
also be extended to serial parallel devices allowing changing of
their configuration on the fly.
Example usage:
qemu [...OPTIONS...] -vnc none -monitor stdio
(qemu) change vnc 127.0.0.1:1,password
Signed-off-by: Daniel P. Berrange [EMAIL PROTECTED]
diff -r 4bae9b5b1e5b monitor.c
--- a/monitor.c Wed Aug 08 15:04:25 2007 -0400
+++ b/monitor.c Wed Aug 08 15:04:27 2007 -0400
@@ -386,7 +386,7 @@ static void do_eject(int force, const ch
eject_device(bs, force);
}
-static void do_change(const char *device, const char *filename)
+static void do_change_block(const char *device, const char *filename)
{
BlockDriverState *bs;
@@ -399,6 +399,21 @@ static void do_change(const char *device
return;
bdrv_open(bs, filename, 0);
qemu_key_check(bs, filename);
+}
+
+static void do_change_vnc(const char *target)
+{
+if (vnc_display_open(NULL, target) 0)
+ term_printf(could not start VNC server on %s\n, target);
+}
+
+static void do_change(const char *device, const char *target)
+{
+if (strcmp(device, vnc) == 0) {
+ do_change_vnc(target);
+} else {
+ do_change_block(device, target);
+}
}
static void do_screen_dump(const char *filename)
diff -r 4bae9b5b1e5b vnc.c
--- a/vnc.c Wed Aug 08 15:04:25 2007 -0400
+++ b/vnc.c Wed Aug 08 15:04:27 2007 -0400
@@ -1208,7 +1208,7 @@ void vnc_display_init(DisplayState *ds)
void vnc_display_close(DisplayState *ds)
{
-VncState *vs = (VncState *)ds-opaque;
+VncState *vs = ds ? (VncState *)ds-opaque : vnc_state;
if (vs-display) {
qemu_free(vs-display);
@@ -1238,7 +1238,7 @@ int vnc_display_open(DisplayState *ds, c
int reuse_addr, ret;
socklen_t addrlen;
const char *p;
-VncState *vs = (VncState *)ds-opaque;
+VncState *vs = ds ? (VncState *)ds-opaque : vnc_state;
vnc_display_close(ds);
if (strcmp(arg, none) == 0)
--
|=- 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 -=|
Re: [Qemu-devel] PATCH 3/8: VNC password authentication
This patch introduces support for VNC protocols upto 3.8 and with
it, support for password based authentication. VNC's password based
authentication is not entirely secure, but it is a standard and the
RFB spec requires that all clients support it. The password can be
provided by using the monitor 'change vnc password' and it will prompt
for a password to be entered. Passwords have upto 8 letters of context.
Until the 'change vnc password' monitor command is run, all client
connection attempts will be rejected. This avoids a startup race where
no password would be present. NB, we need a custom copy of d3des here
because VNC uses a 'special' modification of the algorithm. This d3des
code is public domain in all other VNC servers clients. For client
compatability, protocol 3.5 is treated as identical to protocol 3.3.
Example usage:
qemu [...OPTIONS...] -vnc :1,password -monitor stdio
(qemu) change vnc password
Password:
(qemu)
Signed-off-by: Daniel P. Berrange [EMAIL PROTECTED]
diff -r 08374728639d Makefile.target
--- a/Makefile.target Wed Aug 08 15:04:44 2007 -0400
+++ b/Makefile.target Mon Aug 13 11:25:43 2007 -0400
@@ -482,7 +482,7 @@ ifdef CONFIG_SDL
ifdef CONFIG_SDL
VL_OBJS+=sdl.o x_keymap.o
endif
-VL_OBJS+=vnc.o
+VL_OBJS+=vnc.o d3des.o
ifdef CONFIG_COCOA
VL_OBJS+=cocoa.o
COCOA_LIBS=-F/System/Library/Frameworks -framework Cocoa -framework IOKit
@@ -543,7 +543,7 @@ sdl.o: sdl.c keymaps.c sdl_keysym.h
sdl.o: sdl.c keymaps.c sdl_keysym.h
$(CC) $(CFLAGS) $(CPPFLAGS) $(SDL_CFLAGS) $(BASE_CFLAGS) -c -o $@ $
-vnc.o: vnc.c keymaps.c sdl_keysym.h vnchextile.h
+vnc.o: vnc.c keymaps.c sdl_keysym.h vnchextile.h d3des.c d3des.h
$(CC) $(CFLAGS) $(CPPFLAGS) $(BASE_CFLAGS) -c -o $@ $
sdlaudio.o: sdlaudio.c
diff -r 08374728639d d3des.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/d3des.c Wed Aug 08 15:04:47 2007 -0400
@@ -0,0 +1,434 @@
+/*
+ * This is D3DES (V5.09) by Richard Outerbridge with the double and
+ * triple-length support removed for use in VNC. Also the bytebit[] array
+ * has been reversed so that the most significant bit in each byte of the
+ * key is ignored, not the least significant.
+ *
+ * These changes are:
+ * Copyright (C) 1999 ATT Laboratories Cambridge. All Rights Reserved.
+ *
+ * This software is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ */
+
+/* D3DES (V5.09) -
+ *
+ * A portable, public domain, version of the Data Encryption Standard.
+ *
+ * Written with Symantec's THINK (Lightspeed) C by Richard Outerbridge.
+ * Thanks to: Dan Hoey for his excellent Initial and Inverse permutation
+ * code; Jim Gillogly Phil Karn for the DES key schedule code; Dennis
+ * Ferguson, Eric Young and Dana How for comparing notes; and Ray Lau,
+ * for humouring me on.
+ *
+ * Copyright (c) 1988,1989,1990,1991,1992 by Richard Outerbridge.
+ * (GEnie : OUTER; CIS : [71755,204]) Graven Imagery, 1992.
+ */
+
+#include d3des.h
+
+static void scrunch(unsigned char *, unsigned long *);
+static void unscrun(unsigned long *, unsigned char *);
+static void desfunc(unsigned long *, unsigned long *);
+static void cookey(unsigned long *);
+
+static unsigned long KnL[32] = { 0L };
+
+static unsigned short bytebit[8] = {
+ 01, 02, 04, 010, 020, 040, 0100, 0200 };
+
+static unsigned long bigbyte[24] = {
+ 0x80L, 0x40L, 0x20L, 0x10L,
+ 0x8L, 0x4L, 0x2L, 0x1L,
+ 0x8000L,0x4000L,0x2000L,0x1000L,
+ 0x800L, 0x400L, 0x200L, 0x100L,
+ 0x80L, 0x40L, 0x20L, 0x10L,
+ 0x8L, 0x4L, 0x2L, 0x1L};
+
+/* Use the key schedule specified in the Standard (ANSI X3.92-1981). */
+
+static unsigned char pc1[56] = {
+ 56, 48, 40, 32, 24, 16, 8, 0, 57, 49, 41, 33, 25, 17,
+9, 1, 58, 50, 42, 34, 26, 18, 10, 2, 59, 51, 43, 35,
+ 62, 54, 46, 38, 30, 22, 14, 6, 61, 53, 45, 37, 29, 21,
+ 13, 5, 60, 52, 44, 36, 28, 20, 12, 4, 27, 19, 11, 3 };
+
+static unsigned char totrot[16] = {
+ 1,2,4,6,8,10,12,14,15,17,19,21,23,25,27,28 };
+
+static unsigned char pc2[48] = {
+ 13, 16, 10, 23, 0, 4, 2, 27, 14, 5, 20, 9,
+ 22, 18, 11, 3, 25, 7, 15, 6, 26, 19, 12, 1,
+ 40, 51, 30, 36, 46, 54, 29, 39, 50, 44, 32, 47,
+ 43, 48, 38, 55, 33, 52, 45, 41, 49, 35, 28, 31 };
+
+void deskey(key, edf) /* Thanks to James Gillogly Phil Karn! */
+unsigned char *key;
+int edf;
+{
+ register int i, j, l, m, n;
+ unsigned char pc1m[56], pcr[56];
+ unsigned long kn[32];
+
+ for ( j = 0; j 56; j++ ) {
+ l = pc1[j];
+ m = l 07;
+ pc1m[j] = (key[l 3] bytebit[m]) ? 1 : 0;
+ }
+ for( i = 0; i
Re: [Qemu-devel] PATCH 4/8: VeNCrypt basic TLS support
This patch introduces minimal support for the VeNCrypt protocol
extension. This layers use of TLS (aka SSL) into the VNC data stream,
providing session encryption. This patch is the bare minimum protocol
support. It is enabled by using the 'tls' option flag eg -vnc :1,tls'
This is not secure on its own since it uses anonymous credentials.
The next patches will introduce x509 certificate credentials.
The configure script is setup to automatically look for the GNU TLS
libraries using pkgconfig. If they are not found then TLS support is
disabled. The --disable-vnc-tls argument to configure can be used to
disable support even if available. This should avoid any breakage on
platforms without the GNU TLS libraries.
Daniel P. Berrange [EMAIL PROTECTED]
diff -r b859a28df03a Makefile.target
--- a/Makefile.target Wed Aug 08 15:04:52 2007 -0400
+++ b/Makefile.target Wed Aug 08 15:04:53 2007 -0400
@@ -405,6 +405,11 @@ endif
endif
AUDIODRV+= wavcapture.o
+ifdef CONFIG_VNC_TLS
+CPPFLAGS += $(CONFIG_VNC_TLS_CFLAGS)
+LIBS += $(CONFIG_VNC_TLS_LIBS)
+endif
+
VL_OBJS += i2c.o smbus.o
# SCSI layer
diff -r b859a28df03a configure
--- a/configure Wed Aug 08 15:04:52 2007 -0400
+++ b/configure Wed Aug 08 15:04:53 2007 -0400
@@ -89,6 +89,7 @@ fmod=no
fmod=no
fmod_lib=
fmod_inc=
+vnc_tls=yes
bsd=no
linux=no
kqemu=no
@@ -252,6 +253,8 @@ for opt do
;;
--fmod-inc=*) fmod_inc=$optarg
;;
+ --disable-vnc-tls) vnc_tls=no
+ ;;
--enable-mingw32) mingw32=yes ; cross_prefix=i386-mingw32- ;
linux_user=no
;;
--disable-slirp) slirp=no
@@ -362,6 +365,7 @@ echo --enable-alsaenable
echo --enable-alsaenable ALSA audio driver
echo --enable-fmodenable FMOD audio driver
echo --enable-dsound enable DirectSound audio driver
+echo --disable-vnc-tlsdisable TLS encryption for VNC server
echo --enable-system enable all system emulation targets
echo --disable-system disable all system emulation targets
echo --enable-linux-user enable all linux usermode emulation targets
@@ -589,6 +593,16 @@ fi # -z $sdl
fi # -z $sdl
##
+# VNC TLS detection
+if test $vnc_tls = yes ; then
+ `pkg-config gnutls` || vnc_tls=no
+fi
+if test $vnc_tls = yes ; then
+ vnc_tls_cflags=`pkg-config --cflags gnutls`
+ vnc_tls_libs=`pkg-config --libs gnutls`
+fi
+
+##
# alsa sound support libraries
if test $alsa = yes ; then
@@ -675,6 +689,11 @@ fi
fi
echo FMOD support $fmod $fmod_support
echo OSS support $oss
+echo VNC TLS support $vnc_tls
+if test $vnc_tls = yes ; then
+echo TLS CFLAGS$vnc_tls_cflags
+echo TLS LIBS $vnc_tls_libs
+fi
if test -n $sparc_cpu; then
echo Target Sparc Arch $sparc_cpu
fi
@@ -847,6 +866,12 @@ if test $fmod = yes ; then
echo CONFIG_FMOD_INC=$fmod_inc $config_mak
echo #define CONFIG_FMOD 1 $config_h
fi
+if test $vnc_tls = yes ; then
+ echo CONFIG_VNC_TLS=yes $config_mak
+ echo CONFIG_VNC_TLS_CFLAGS=$vnc_tls_cflags $config_mak
+ echo CONFIG_VNC_TLS_LIBS=$vnc_tls_libs $config_mak
+ echo #define CONFIG_VNC_TLS 1 $config_h
+fi
qemu_version=`head $source_path/VERSION`
echo VERSION=$qemu_version $config_mak
echo #define QEMU_VERSION \$qemu_version\ $config_h
diff -r b859a28df03a vnc.c
--- a/vnc.c Wed Aug 08 15:04:52 2007 -0400
+++ b/vnc.c Wed Aug 08 15:04:53 2007 -0400
@@ -32,13 +32,26 @@
#include keymaps.c
#include d3des.h
-// #define _VNC_DEBUG
-
-#ifdef _VNC_DEBUG
+#if CONFIG_VNC_TLS
+#include gnutls/gnutls.h
+#include gnutls/x509.h
+#endif /* CONFIG_VNC_TLS */
+
+// #define _VNC_DEBUG 1
+
+#if _VNC_DEBUG
#define VNC_DEBUG(fmt, ...) do { fprintf(stderr, fmt, ## __VA_ARGS__); } while
(0)
+
+#if CONFIG_VNC_TLS _VNC_DEBUG = 2
+/* Very verbose, so only enabled for _VNC_DEBUG = 2 */
+static void vnc_debug_gnutls_log(int level, const char* str) {
+VNC_DEBUG(%d %s, level, str);
+}
+#endif /* CONFIG_VNC_TLS _VNC_DEBUG */
#else
#define VNC_DEBUG(fmt, ...) do { } while (0)
#endif
+
typedef struct Buffer
{
@@ -76,6 +89,23 @@ enum {
VNC_AUTH_TLS = 18,
VNC_AUTH_VENCRYPT = 19
};
+
+#if CONFIG_VNC_TLS
+enum {
+VNC_WIREMODE_CLEAR,
+VNC_WIREMODE_TLS,
+};
+
+enum {
+VNC_AUTH_VENCRYPT_PLAIN = 256,
+VNC_AUTH_VENCRYPT_TLSNONE = 257,
+VNC_AUTH_VENCRYPT_TLSVNC = 258,
+VNC_AUTH_VENCRYPT_TLSPLAIN = 259,
+VNC_AUTH_VENCRYPT_X509NONE = 260,
+VNC_AUTH_VENCRYPT_X509VNC = 261,
+VNC_AUTH_VENCRYPT_X509PLAIN = 262,
+};
+#endif /* CONFIG_VNC_TLS */
struct VncState
{
@@ -102,7 +132,15 @@ struct VncState
char *display;
char *password;
int auth;
+#if CONFIG_VNC_TLS
+int subauth;
+#endif
char challenge[VNC_AUTH_CHALLENGE_SIZE];
+
+#if CONFIG_VNC_TLS
+int wiremode;
+gnutls_session_t tls_session;
+#endif
Buffer output;
Buffer input;
@@ -579,12 +617,20 @@ static int
Re: [Qemu-devel] PATCH 5/8: x509 certificate for server
This patch adds support for using x509 certificates on the server
end. The server needs a CA certificate, and its own certificate and
private key. A CA revocation list is optional. This this patch the
file names are hardcoded. The next-but-one patch will make them
configurable.
The use of x509 certificates is controlled by the 'x509' flag to
the VNC arg, eg '-vnc :1,tls,x509'. This only provides encryption
of the session, no authentication. The subsequent patch will allow
certificates to be used for authentication too.
Example using TLS, x509 server certificates and password auth
qemu [...OPTIONS...] -vnc :1,password,tls,x509 -monitor stdio
(qemu) change vnc password
Password:
(qemu)
Signed-off-by: Daniel P. Berrange [EMAIL PROTECTED]
diff -r 4199204d1b36 vnc.c
--- a/vnc.c Wed Aug 08 12:53:40 2007 -0400
+++ b/vnc.c Wed Aug 08 12:53:43 2007 -0400
@@ -105,6 +105,14 @@ enum {
VNC_AUTH_VENCRYPT_X509VNC = 261,
VNC_AUTH_VENCRYPT_X509PLAIN = 262,
};
+
+#if CONFIG_VNC_TLS
+#define X509_CA_CERT_FILE ca-cert.pem
+#define X509_CA_CRL_FILE ca-crl.pem
+#define X509_SERVER_KEY_FILE server-key.pem
+#define X509_SERVER_CERT_FILE server-cert.pem
+#endif
+
#endif /* CONFIG_VNC_TLS */
struct VncState
@@ -1377,16 +1385,60 @@ static gnutls_anon_server_credentials vn
}
+static gnutls_certificate_credentials_t vnc_tls_initialize_x509_cred(void)
+{
+gnutls_certificate_credentials_t x509_cred;
+int ret;
+struct stat st;
+
+if ((ret = gnutls_certificate_allocate_credentials(x509_cred)) 0) {
+ VNC_DEBUG(Cannot allocate credentials %s\n, gnutls_strerror(ret));
+ return NULL;
+}
+if ((ret = gnutls_certificate_set_x509_trust_file(x509_cred,
X509_CA_CERT_FILE, GNUTLS_X509_FMT_PEM)) 0) {
+ VNC_DEBUG(Cannot load CA certificate %s\n, gnutls_strerror(ret));
+ gnutls_certificate_free_credentials(x509_cred);
+ return NULL;
+}
+
+if ((ret = gnutls_certificate_set_x509_key_file (x509_cred,
X509_SERVER_CERT_FILE,
+X509_SERVER_KEY_FILE,
+GNUTLS_X509_FMT_PEM)) 0)
{
+ VNC_DEBUG(Cannot load certificate key %s\n, gnutls_strerror(ret));
+ gnutls_certificate_free_credentials(x509_cred);
+ return NULL;
+}
+
+if (stat(X509_CA_CRL_FILE, st) 0) {
+ if (errno != ENOENT) {
+ gnutls_certificate_free_credentials(x509_cred);
+ return NULL;
+ }
+} else {
+ if ((ret = gnutls_certificate_set_x509_crl_file(x509_cred,
X509_CA_CRL_FILE, GNUTLS_X509_FMT_PEM)) 0) {
+ VNC_DEBUG(Cannot load CRL %s\n, gnutls_strerror(ret));
+ gnutls_certificate_free_credentials(x509_cred);
+ return NULL;
+ }
+}
+
+gnutls_certificate_set_dh_params (x509_cred, dh_params);
+
+return x509_cred;
+}
+
static int start_auth_vencrypt_subauth(VncState *vs)
{
switch (vs-subauth) {
case VNC_AUTH_VENCRYPT_TLSNONE:
+case VNC_AUTH_VENCRYPT_X509NONE:
VNC_DEBUG(Accept TLS auth none\n);
vnc_write_u32(vs, 0); /* Accept auth completion */
vnc_read_when(vs, protocol_client_init, 1);
break;
case VNC_AUTH_VENCRYPT_TLSVNC:
+case VNC_AUTH_VENCRYPT_X509VNC:
VNC_DEBUG(Start TLS auth VNC\n);
return start_auth_vnc(vs);
@@ -1437,11 +1489,17 @@ static void vnc_handshake_io(void *opaqu
vnc_continue_handshake(vs);
}
+#define NEED_X509_AUTH(vs) \
+((vs)-subauth == VNC_AUTH_VENCRYPT_X509NONE || \
+ (vs)-subauth == VNC_AUTH_VENCRYPT_X509VNC ||\
+ (vs)-subauth == VNC_AUTH_VENCRYPT_X509PLAIN)
+
+
static int vnc_start_tls(struct VncState *vs) {
static const int cert_type_priority[] = { GNUTLS_CRT_X509, 0 };
static const int protocol_priority[]= { GNUTLS_TLS1_1, GNUTLS_TLS1_0,
GNUTLS_SSL3, 0 };
static const int kx_anon[] = {GNUTLS_KX_ANON_DH, 0};
-gnutls_anon_server_credentials anon_cred = NULL;
+static const int kx_x509[] = {GNUTLS_KX_DHE_DSS, GNUTLS_KX_RSA,
GNUTLS_KX_DHE_RSA, GNUTLS_KX_SRP, 0};
VNC_DEBUG(Do TLS setup\n);
if (vnc_tls_initialize() 0) {
@@ -1462,7 +1520,7 @@ static int vnc_start_tls(struct VncState
return -1;
}
- if (gnutls_kx_set_priority(vs-tls_session, kx_anon) 0) {
+ if (gnutls_kx_set_priority(vs-tls_session, NEED_X509_AUTH(vs) ?
kx_x509 : kx_anon) 0) {
gnutls_deinit(vs-tls_session);
vs-tls_session = NULL;
vnc_client_error(vs);
@@ -1483,19 +1541,36 @@ static int vnc_start_tls(struct VncState
return -1;
}
- anon_cred = vnc_tls_initialize_anon_cred();
- if (!anon_cred) {
- gnutls_deinit(vs-tls_session);
- vs-tls_session = NULL;
- vnc_client_error(vs);
- return -1;
- }
- if (gnutls_credentials_set(vs-tls_session, GNUTLS_CRD_ANON, anon_cred)
0) {
Re: [Qemu-devel] PATCH 7/8: custom location for x509 cert paths
This final code patch extends the VNC server config syntax so that the x509
and x509verify flags both use a path following them. This path is then used
to determine the filenames for the CA certificate revocation list, and the
server certificate private key. If the path containing the certificates is
not provided, all client authentication attempts will be rejected.
Example usage on command line:
qemu [...OPTIONS...] -vnc :1,tls,x509verify=/etc/pki/qemu
Signed-off-by: Daniel P. Berrange [EMAIL PROTECTED]
diff -r 109ed8417169 vnc.c
--- a/vnc.c Wed Aug 08 12:54:13 2007 -0400
+++ b/vnc.c Wed Aug 08 12:54:18 2007 -0400
@@ -143,6 +143,11 @@ struct VncState
#if CONFIG_VNC_TLS
int subauth;
int x509verify;
+
+char *x509cacert;
+char *x509cacrl;
+char *x509cert;
+char *x509key;
#endif
char challenge[VNC_AUTH_CHALLENGE_SIZE];
@@ -1386,37 +1391,49 @@ static gnutls_anon_server_credentials vn
}
-static gnutls_certificate_credentials_t vnc_tls_initialize_x509_cred(void)
+static gnutls_certificate_credentials_t vnc_tls_initialize_x509_cred(VncState
*vs)
{
gnutls_certificate_credentials_t x509_cred;
int ret;
-struct stat st;
+
+if (!vs-x509cacert) {
+ VNC_DEBUG(No CA x509 certificate specified\n);
+ return NULL;
+}
+if (!vs-x509cert) {
+ VNC_DEBUG(No server x509 certificate specified\n);
+ return NULL;
+}
+if (!vs-x509key) {
+ VNC_DEBUG(No server private key specified\n);
+ return NULL;
+}
if ((ret = gnutls_certificate_allocate_credentials(x509_cred)) 0) {
VNC_DEBUG(Cannot allocate credentials %s\n, gnutls_strerror(ret));
return NULL;
}
-if ((ret = gnutls_certificate_set_x509_trust_file(x509_cred,
X509_CA_CERT_FILE, GNUTLS_X509_FMT_PEM)) 0) {
+if ((ret = gnutls_certificate_set_x509_trust_file(x509_cred,
+ vs-x509cacert,
+ GNUTLS_X509_FMT_PEM))
0) {
VNC_DEBUG(Cannot load CA certificate %s\n, gnutls_strerror(ret));
gnutls_certificate_free_credentials(x509_cred);
return NULL;
}
-if ((ret = gnutls_certificate_set_x509_key_file (x509_cred,
X509_SERVER_CERT_FILE,
-X509_SERVER_KEY_FILE,
+if ((ret = gnutls_certificate_set_x509_key_file (x509_cred,
+vs-x509cert,
+vs-x509key,
GNUTLS_X509_FMT_PEM)) 0)
{
VNC_DEBUG(Cannot load certificate key %s\n, gnutls_strerror(ret));
gnutls_certificate_free_credentials(x509_cred);
return NULL;
}
-if (stat(X509_CA_CRL_FILE, st) 0) {
- if (errno != ENOENT) {
- gnutls_certificate_free_credentials(x509_cred);
- return NULL;
- }
-} else {
- if ((ret = gnutls_certificate_set_x509_crl_file(x509_cred,
X509_CA_CRL_FILE, GNUTLS_X509_FMT_PEM)) 0) {
+if (vs-x509cacrl) {
+ if ((ret = gnutls_certificate_set_x509_crl_file(x509_cred,
+ vs-x509cacrl,
+ GNUTLS_X509_FMT_PEM))
0) {
VNC_DEBUG(Cannot load CRL %s\n, gnutls_strerror(ret));
gnutls_certificate_free_credentials(x509_cred);
return NULL;
@@ -1632,7 +1649,7 @@ static int vnc_start_tls(struct VncState
}
if (NEED_X509_AUTH(vs)) {
- gnutls_certificate_server_credentials x509_cred =
vnc_tls_initialize_x509_cred();
+ gnutls_certificate_server_credentials x509_cred =
vnc_tls_initialize_x509_cred(vs);
if (!x509_cred) {
gnutls_deinit(vs-tls_session);
vs-tls_session = NULL;
@@ -1903,6 +1920,63 @@ void vnc_display_init(DisplayState *ds)
vnc_dpy_resize(vs-ds, 640, 400);
}
+#if CONFIG_VNC_TLS
+static int vnc_set_x509_credential(VncState *vs,
+ const char *certdir,
+ const char *filename,
+ char **cred,
+ int ignoreMissing)
+{
+struct stat sb;
+
+if (*cred) {
+ qemu_free(*cred);
+ *cred = NULL;
+}
+
+if (!(*cred = qemu_malloc(strlen(certdir) + strlen(filename) + 2)))
+ return -1;
+
+strcpy(*cred, certdir);
+strcat(*cred, /);
+strcat(*cred, filename);
+
+VNC_DEBUG(Check %s\n, *cred);
+if (stat(*cred, sb) 0) {
+ qemu_free(*cred);
+ *cred = NULL;
+ if (ignoreMissing errno == ENOENT)
+ return 0;
+ return -1;
+}
+
+return 0;
+}
+
+static int vnc_set_x509_credential_dir(VncState *vs,
+ const char *certdir)
+{
+if (vnc_set_x509_credential(vs, certdir,
Re: [Qemu-devel] PATCH 8/8: document all VNC authentication options
This patch updates the user documentation to detail the new syntax
options for VNC server configuration. It moves all the display
related options into a combined logical section for clarity. It
documents the different deployment secenarios possible with the
new VNC server capabilities and their security. It also provides
a guide for setting up a certificate authority and issuing clients
and server with their certificates
Signed-off-by: Daniel P. Berrange [EMAIL PROTECTED]
diff -r e5ce3da5ebb1 qemu-doc.texi
--- a/qemu-doc.texi Mon Aug 13 11:57:58 2007 -0400
+++ b/qemu-doc.texi Mon Aug 13 12:05:16 2007 -0400
@@ -129,6 +129,7 @@ Download the experimental binary install
* pcsys_network:: Network emulation
* direct_linux_boot:: Direct Linux Boot
* pcsys_usb:: USB emulation
+* vnc_security:: VNC security
* gdb_usage:: GDB usage
* pcsys_os_specific:: Target OS specific information
@end menu
@@ -243,6 +244,56 @@ Simulate an SMP system with @var{n} CPUs
Simulate an SMP system with @var{n} CPUs. On the PC target, up to 255
CPUs are supported.
[EMAIL PROTECTED] -audio-help
+
+Will show the audio subsystem help: list of drivers, tunable
+parameters.
+
[EMAIL PROTECTED] -soundhw card1,card2,... or -soundhw all
+
+Enable audio and selected sound hardware. Use ? to print all
+available sound hardware.
+
[EMAIL PROTECTED]
+qemu -soundhw sb16,adlib hda
+qemu -soundhw es1370 hda
+qemu -soundhw all hda
+qemu -soundhw ?
[EMAIL PROTECTED] example
+
[EMAIL PROTECTED] -localtime
+Set the real time clock to local time (the default is to UTC
+time). This option is needed to have correct date in MS-DOS or
+Windows.
+
[EMAIL PROTECTED] -pidfile file
+Store the QEMU process PID in @var{file}. It is useful if you launch QEMU
+from a script.
+
[EMAIL PROTECTED] -daemonize
+Daemonize the QEMU process after initialization. QEMU will not detach from
+standard IO until it is ready to receive connections on any of its devices.
+This option is a useful way for external programs to launch QEMU without having
+to cope with initialization race conditions.
+
[EMAIL PROTECTED] -win2k-hack
+Use it when installing Windows 2000 to avoid a disk full bug. After
+Windows 2000 is installed, you no longer need this option (this option
+slows down the IDE transfers).
+
[EMAIL PROTECTED] -option-rom file
+Load the contents of file as an option ROM. This option is useful to load
+things like EtherBoot.
+
[EMAIL PROTECTED] -name string
+Sets the name of the guest. This name will be display in the SDL window
+caption. The name will also be used for the VNC server.
+
[EMAIL PROTECTED] table
+
+Display options:
[EMAIL PROTECTED] @option
+
@item -nographic
Normally, QEMU uses SDL to display the VGA output. With this option,
@@ -257,21 +308,80 @@ available screen space. This makes the u
available screen space. This makes the using QEMU in a dedicated desktop
workspace more convenient.
[EMAIL PROTECTED] -vnc display
[EMAIL PROTECTED] -full-screen
+Start in full screen.
+
[EMAIL PROTECTED] -vnc display[,option[,option[,...]]]
Normally, QEMU uses SDL to display the VGA output. With this option,
you can have QEMU listen on VNC display @var{display} and redirect the VGA
display over the VNC session. It is very useful to enable the usb
tablet device when using this option (option @option{-usbdevice
tablet}). When using the VNC display, you must use the @option{-k}
-option to set the keyboard layout if you are not using en-us.
-
[EMAIL PROTECTED] may be in the form @var{interface:d}, in which case
connections
-will only be allowed from @var{interface} on display @var{d}. Optionally,
[EMAIL PROTECTED] can be omitted. @var{display} can also be in the form
[EMAIL PROTECTED]:path} where @var{path} is the location of a unix socket to
listen for
-connections on.
-
+parameter to set the keyboard layout if you are not using en-us. Valid
+syntax for the @var{display} is
+
[EMAIL PROTECTED] @code
+
[EMAIL PROTECTED] @var{interface:d}
+
+TCP connections will only be allowed from @var{interface} on display @var{d}.
+By convention the TCP port is [EMAIL PROTECTED] Optionally, @var{interface} can
+be omitted in which case the server will bind to all interfaces.
+
[EMAIL PROTECTED] @var{unix:path}
+
+Connections will be allowed over UNIX domain sockets where @var{path} is the
+location of a unix socket to listen for connections on.
+
[EMAIL PROTECTED] @var{none}
+
+VNC is initialized by not started. The monitor @code{change} command can be
used
+to later start the VNC server.
+
[EMAIL PROTECTED] table
+
+Following the @var{display} value there may be one or more @var{option} flags
+separated by commas. Valid options are
+
[EMAIL PROTECTED] @code
+
[EMAIL PROTECTED] @var{password}
+
+Require that password based authentication is used for client connections.
+The password must be set separately using the @code{change} command in the
[EMAIL PROTECTED]
+
[EMAIL PROTECTED] @var{tls}
+
+Require that client use
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
Jorge Lucángeli Obes wrote: [snip] When I read Avi's TODO, I basically thought about getting rid of the long command lines I had to store in scripts. I wanted to write that command line once, and then forgetting about it, until I needed to change it. Instead of inventing great and wonderfully complicated schemes, the most sensible way I can think of is to recycle a feature which is now implemented in the GNU toolchain, and apparently stems from Windows: qemu @qemu.cfg where qemu.cfg is a file which contains the command line arguments. (This is also low-maintenance, as it allows to re-use the existing parser. No need for duplicated logic.) I wanted an image to be self-contained as much as possible. That's what I set to achieve. Which tends to collect all the complexity in a single piece. That seems to be the common problem of the option discussed here. All that said, I rethought Anthony's idea of storing plain text in the image and with proper tools, it can work out. Requiring proper tools doesn't leave much of a point for plain text. Thiemo
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
On 8/13/07, Thiemo Seufer [EMAIL PROTECTED] wrote: Instead of inventing great and wonderfully complicated schemes, the most sensible way I can think of is to recycle a feature which is now implemented in the GNU toolchain, and apparently stems from Windows: qemu @qemu.cfg where qemu.cfg is a file which contains the command line arguments. (This is also low-maintenance, as it allows to re-use the existing parser. No need for duplicated logic.) except it does not work yet on Windows! I tried with a 1 line file (all arguments on 1 line) and another file with each pair of arguments per line. qemu.exe @detaolb.cfg qemu: could not open hard disk image '@detaolb.cfg' type detaolb.cfg -L bios -m 128 -cdrom detaolb_v04.iso -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu
[Qemu-devel] Re: [kvm-devel] [PATCH] Dynamic ticks
Il Mon, Aug 13, 2007 at 05:42:55PM +0300, Dan Kenigsberg ha scritto:
Dynamic ticks in Qemu: have a SIGALRM generated only when it is
needed, instead of every 1 millisecond. This patch requires that the
host supports high resolution timers, since it arms a POSIX timer to the
nearest Qemu timer's expiry time (which might be rather near).
I tried to send a previous version of this patch yesterday, but luckily
it seems to have been eaten by qemu-devel list. I'd be happy to hear
your comments about it.
I like it ;) I have some comments (and a reworked patch at the end):
Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.323
diff -u -r1.323 vl.c
--- vl.c 29 Jul 2007 17:57:25 - 1.323
+++ vl.c 13 Aug 2007 14:18:19 -
@@ -793,6 +793,15 @@
/* frequency of the times() clock tick */
static int timer_freq;
#endif
+#ifdef DYNAMIC_TICKS
+/* If DYNAMIC_TICKS is defined (and use_dynamic_ticks selected) qemu does not
+ * attepmt to generate SIGALRM at a constant rate. Rather, the system timer
is
+ * set to generate SIGALRM only when it is needed. DYNAMIC_TICKS reduces the
+ * number of SIGALRMs sent to idle dynamic-ticked guests. */
+static timer_t host_timer;
+static void rearm_host_timer(void);
+static int use_dynamic_ticks = 1;
+#endif
I'd make use_dynamic_ticks a static inline helper, in this way gcc will
still optimize it away when not need and you can remove a lot of #ifdefs
from the code.
QEMUClock *qemu_new_clock(int type)
{
@@ -838,6 +847,10 @@
}
pt = t-next;
}
+#ifdef DYNAMIC_TICKS
+if (use_dynamic_ticks)
+rearm_host_timer();
+#endif
Like here
}
/* modify the current timer so that it will be fired when current_time
@@ -897,6 +910,7 @@
/* run the callback (the timer list can be modified) */
ts-cb(ts-opaque);
}
+rearm_host_timer();
}
int64_t qemu_get_clock(QEMUClock *clock)
@@ -1004,7 +1018,12 @@
last_clock = ti;
}
#endif
-if (qemu_timer_expired(active_timers[QEMU_TIMER_VIRTUAL],
+
+if (
+#ifdef DYNAMIC_TICKS
+use_dynamic_ticks ||
+#endif
+qemu_timer_expired(active_timers[QEMU_TIMER_VIRTUAL],
qemu_get_clock(vm_clock)) ||
qemu_timer_expired(active_timers[QEMU_TIMER_REALTIME],
qemu_get_clock(rt_clock))) {
and here (this one is pretty ugly btw)
@@ -1109,21 +1128,37 @@
act.sa_handler = host_alarm_handler;
sigaction(SIGALRM, act, NULL);
-itv.it_interval.tv_sec = 0;
-itv.it_interval.tv_usec = 999; /* for i386 kernel 2.6 to get 1 ms */
-itv.it_value.tv_sec = 0;
-itv.it_value.tv_usec = 10 * 1000;
-setitimer(ITIMER_REAL, itv, NULL);
-/* we probe the tick duration of the kernel to inform the user if
- the emulated kernel requested a too high timer frequency */
-getitimer(ITIMER_REAL, itv);
+#ifdef DYNAMIC_TICKS
+if (use_dynamic_ticks) {
+struct sigevent ev;
+ev.sigev_value.sival_int = 0;
+ev.sigev_notify = SIGEV_SIGNAL;
+ev.sigev_signo = SIGALRM;
+if (timer_create(CLOCK_REALTIME, ev, host_timer))
+perror(timer_create);
Should this fail you end up with a non-working QEMU. It's pretty easy to
recover though, running this code:
+} else
+#endif /* DYNAMIC_TICKS */
+{
+itv.it_interval.tv_sec = 0;
+itv.it_interval.tv_usec = 999; /* for i386 kernel 2.6 to get 1
ms */
+itv.it_value.tv_sec = 0;
+itv.it_value.tv_usec = 10 * 1000;
+setitimer(ITIMER_REAL, itv, NULL);
+/* we probe the tick duration of the kernel to inform the user if
+ the emulated kernel requested a too high timer frequency */
+getitimer(ITIMER_REAL, itv);
+}
#if defined(__linux__)
/* XXX: force /dev/rtc usage because even 2.6 kernels may not
have timers with 1 ms resolution. The correct solution will
be to use the POSIX real time timers available in recent
2.6 kernels */
-if (itv.it_interval.tv_usec 1000 || 1) {
+if (
+#ifdef DYNAMIC_TICKS
+!use_dynamic_ticks
helper ;)
+#endif
+(itv.it_interval.tv_usec 1000 || 1)) {
Plus, in this way you change the behaviour from always try RTC under
Linux to don't use RTC is dynticks is enabled.
Is this what you really want?
Furthermore: I'm not sure about the cost of reprogramming the CMOS RTC,
but with HPET should be feasible to program the timer in one-shot
mode.
/* try to use /dev/rtc to have a faster timer */
if (start_rtc_timer() 0)
goto use_itimer;
@@ -6287,6 +6322,10 @@
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
On 13 Aug 2007, at 20:39, Thiemo Seufer wrote: Instead of inventing great and wonderfully complicated schemes, the most sensible way I can think of is to recycle a feature which is now implemented in the GNU toolchain, and apparently stems from Windows: qemu @qemu.cfg I'm not familiar with that. Is it just GNU bash shorthand for qemu `cat qemu.cfg` ? I wanted an image to be self-contained as much as possible. That's what I set to achieve. Which tends to collect all the complexity in a single piece. That seems to be the common problem of the option discussed here. As far as I can tell, this is desirable for easy distribution of images to other machines; this is pretty much my only objection to the 'directory' idea, which is otherwise a nice, clean solution. (If not, I can't really see what's wrong with a one-liner sh script alongside the image, which is basically what has been reinvented.) All that said, I rethought Anthony's idea of storing plain text in the image and with proper tools, it can work out. Requiring proper tools doesn't leave much of a point for plain text. Correct, but qemu's command-line arguments (and it makes sense to use the same syntax for embedded ones, such that the parser can be re- used) /are/ plain text. Still, it's probably worth thinking of it as a shebang and a serialised (subset of) argv[], rather than /a command line/. In particular, you can avoid having to do sh's job of splitting and escaping again. LionsPhil
[Qemu-devel] Re: [kvm-devel] Storing command line options in images
On Tuesday, August 14, 2007, 0:21:42, Philip Boulain wrote: qemu @qemu.cfg I'm not familiar with that. Is it just GNU bash shorthand for qemu `cat qemu.cfg` ? GNU bash does not have that shorthand, but @file is very similar to `cat file` (the practice was born in DOS days, because the command line was limited to 127 characters). -- Jernej Simončič http://deepthought.ena.si/ A coup that is known in advance is a coup that does not take place. -- Camp's Law
[Qemu-devel] Incorrect handling of interrupted syscalls
Hi, when trying to write a driver that provides a ppdev-compatible API but forwards the data written to the parport to a userspace program, I noticed that Qemu (0.8.2-4etch1 from Debian Etch, but the changelog of 0.9.0 doesn't look like it has been fixed there) doesn't handle interrupted system calls properly, at least as far as the parport emulation is concerned. When the involved ioctl()s get interrupted by a SIGALRM, they don't get restarted, so some port writes get lost. Florian
Re: [kvm-devel] [Qemu-devel] Re: Storing command line options in images
On 8/14/07, Anthony Liguori [EMAIL PROTECTED] wrote: On Mon, 2007-08-13 at 20:39 +0100, Thiemo Seufer wrote: Jorge Lucángeli Obes wrote: [snip] When I read Avi's TODO, I basically thought about getting rid of the long command lines I had to store in scripts. I wanted to write that command line once, and then forgetting about it, until I needed to change it. Instead of inventing great and wonderfully complicated schemes, the most sensible way I can think of is to recycle a feature which is now implemented in the GNU toolchain, and apparently stems from Windows: qemu @qemu.cfg where qemu.cfg is a file which contains the command line arguments. (This is also low-maintenance, as it allows to re-use the existing parser. No need for duplicated logic.) In this case, it's also just as easy to make a shell script. I think an important goal here is to automatically associate the options for a VM with the actual disk image. It's not just about storing said options in a file. On my 64-bit Xubuntu Feisty I get: qemu: could not open hard disk image '@config' Anyways, as Anthony said, we would like to have only one file describing the VM. Since we already have the disk image, we were looking for ways to reuse that image for this purpose. I did not know about '@config', and if I can get it to work, I like it better than a shell script. However, I think it does not completely solve the problem. It still means two files per VM. Cheers, Jorge
