Re: [Qemu-devel] [PATCH] libusb host usb redirector

2005-12-23 Thread Johannes Schindelin 
Hi,

On Thu, 22 Dec 2005, Lonnie Mendez wrote:

> The files are located here:
> http://gnome.dnsalias.net/patches/

< Forbidden
< 
< You don't have permission to access /patches/libusb0.zip on this server.

Thank you,
Dscho



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

[Qemu-devel] IDE driver error handling

2005-12-23 Thread andrzej zaborowski 
Hi there,
Today when I was running qemu with -snapshot and I noticed strange
things happening in the guest system after some amount of disk IO.
After some time of figuring out I found that the reason was my /tmp
partition (on the host, it is 400 MB big) being full. The guest didn't
receive any error or warning when the temporary QCOW image in /tmp
grew to 400 MB. After some investigation, it turned out that write
errors are generally ignored by the QEMU IDE driver. I came up with
the following changes to make the guest receive an IO error when that
happens. Please note that this works for me but I have little idea
about how IDE works. So I am posting this as a pointer to where the
errors really get ignored for someone who feels like fixing this in
QEMU.
Regards,
wish you a Merry Christmas
Andrew

--- qemu/hw/ide.c   2005-08-06 09:14:32.0 +
+++ qemu-warnings/hw/ide.c  2005-12-23 12:34:24.0 +
@@ -676,7 +676,9 @@
 n = s->req_nb_sectors;
 ret = bdrv_write(s->bs, sector_num, s->io_buffer, n);
 s->nsector -= n;
-if (s->nsector == 0) {
+if (ret) {
+ide_abort_command(s);
+} else if (s->nsector == 0) {
 /* no more sector to write */
 ide_transfer_stop(s);
 } else {
@@ -708,7 +710,7 @@
 target_phys_addr_t phys_addr,
 int transfer_size1)
 {
-int len, transfer_size, n;
+int len, transfer_size, n, ret;
 int64_t sector_num;

 transfer_size = transfer_size1;
@@ -717,8 +719,8 @@
 if (len == 0) {
 n = s->io_buffer_size >> 9;
 sector_num = ide_get_sector(s);
-bdrv_write(s->bs, sector_num, s->io_buffer,
-   s->io_buffer_size >> 9);
+ret = bdrv_write(s->bs, sector_num, s->io_buffer,
+ s->io_buffer_size >> 9);
 sector_num += n;
 ide_set_sector(s, sector_num);
 s->nsector -= n;
@@ -729,6 +731,11 @@
 ide_set_irq(s);
 return 0;
 }
+if (ret) {
+ide_abort_command(s);
+ide_set_irq(s);
+return 0;
+}
 if (n > MAX_MULT_SECTORS)
 n = MAX_MULT_SECTORS;
 s->io_buffer_index = 0;

--
balrog 2oo5

Dear Outlook users: Please remove me from your address books
http://www.newsforge.com/article.pl?sid=03/08/21/143258


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

[Qemu-devel] [PATCH] Incorrect address translation in user-net implementation.

2005-12-23 Thread Mark Jonckheere 

Fabrice,

There are still two pending issues with address translation in the
user-net implementation. I already proposed on this list some patches
to correct them but maybe you have missed those messages.

1. UDP broadcast from guest to host:

Current situation:

   guest host
   - 
10.0.2.15 --> 10.0.2.255  # guest sends broadcast packet
10.0.2.15 <-- 10.0.2.255  # host sends reply with invalid source
  # address, packet is ignored by guest

This should be:

   guest host
   - 
10.0.2.15 --> 10.0.2.255  # guest sends broadcast packet
10.0.2.15 <-- 10.0.2.2# host replies with his own address.

Packets with destination address 10.0.2.255 (IP-broadcast) from the
guest to the host are replied by the slirp code with this broadcast
address as source address where it should be the host IP-address..

Correcting this bug makes it possible for e.g. a Windows 98 guest to
browse the network neigbourhoud and see the share that is published
by the host with the -smb switch.

2. using localhost with -redir switch and HOSTNAME == localhost

Current situation:

   host  guest
     -
127.0.0.1 --> 127.0.0.1   # host sends to redirected port
127.0.0.1 --> 10.0.2.15   # destination address is translated
  # source address remains 127.0.0.1
127.0.0.1 <-- 10.0.2.15   # reply from guest is routed to guest
  # and never arrives at host.

This should be:

   host  guest
     -
127.0.0.1 --> 127.0.0.1   # host sends to redirected port
10.0.2.2  --> 10.0.2.15   # both addresses are translated
10.0.2.2  <-- 10.0.2.15   # reply from guest to host
127.0.0.1 <-- 127.0.0.1   # translated back to host address

When you start qemu with the -redir switch e.g. -redir tcp:8080::80
entering http://localhost:8080/ in your webbrowser on the host OS
should connect you with the web server on the guest OS, this doesn't
work when on the host OS the hostname command refers to the loopback
interface.

When you look at this mailing list and the user forum you can see
that this situation has already occured a number of times.

Even if it is not the best practice to use the loopback address
as your hostname, it is in my opinion better to add a small patch
in a non-critical path than to document how to avoid this situation.

see also my previous messages:

http://lists.gnu.org/archive/html/qemu-devel/2004-08/msg00443.html
http://lists.gnu.org/archive/html/qemu-devel/2004-09/msg00188.html
http://lists.gnu.org/archive/html/qemu-devel/2005-08/msg00240.html
http://lists.gnu.org/archive/html/qemu-devel/2005-11/msg00419.html

I hope this one will not slip under your radar.

Greetings,
Mark.




diff -wurb qemu/slirp/misc.c qemu-patched/slirp/misc.c
--- qemu/slirp/misc.c   Sun Dec 12 12:45:10 2004
+++ qemu-patched/slirp/misc.c   Mon Mar 21 13:22:05 2005
@@ -90,13 +90,12 @@
char buff[256];
struct hostent *he;

-   if (gethostname(buff,256) < 0)
-  return;
-   
-   if ((he = gethostbyname(buff)) == NULL)
-  return;
-   
+   if (gethostname(buff,256) == 0)
+   if ((he = gethostbyname(buff)) != NULL)
our_addr = *(struct in_addr *)he->h_addr;
+
+   if (our_addr.s_addr == 0 || our_addr.s_addr == loopback_addr.s_addr)
+   our_addr.s_addr = special_addr.s_addr | htonl(CTL_ALIAS);
 }
 
 #if SIZEOF_CHAR_P == 8
diff -wurb qemu/slirp/slirp.c qemu-patched/slirp/slirp.c
--- qemu/slirp/slirp.c  Fri Oct  8 01:27:35 2004
+++ qemu-patched/slirp/slirp.c  Mon Mar 21 13:22:05 2005
@@ -144,7 +144,6 @@
 m_init();
 
 /* set default addresses */
-getouraddr();
 inet_aton("127.0.0.1", &loopback_addr);
 
 if (get_dns_addr(&dns_addr) < 0) {
@@ -153,6 +152,7 @@
 }
 
 inet_aton(CTL_SPECIAL, &special_addr);
+getouraddr();
 }
 
 #define CONN_CANFSEND(so) (((so)->so_state & 
(SS_FCANTSENDMORE|SS_ISFCONNECTED)) == SS_ISFCONNECTED)
diff -wurb qemu/slirp/udp.c qemu-patched/slirp/udp.c
--- qemu/slirp/udp.cFri Oct  8 01:27:35 2004
+++ qemu-patched/slirp/udp.cMon Mar 21 13:22:05 2005
@@ -314,6 +314,8 @@
 saddr = *addr;
 if ((so->so_faddr.s_addr & htonl(0xff00)) == special_addr.s_addr)
 saddr.sin_addr.s_addr = so->so_faddr.s_addr;
+if ((so->so_faddr.s_addr & htonl(0x00ff)) == htonl(0xff))
+saddr.sin_addr.s_addr = special_addr.s_addr | htonl(CTL_ALIAS);
 daddr.sin_addr = so->so_laddr;
 daddr.sin_port = so->so_lport;
 
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [PATCH] Incorrect address translation in user-net implementation.

2005-12-23 Thread Paul Brook 
> When you start qemu with the -redir switch e.g. -redir tcp:8080::80
> entering http://localhost:8080/ in your webbrowser on the host OS
> should connect you with the web server on the guest OS, this doesn't
> work when on the host OS the hostname command refers to the loopback
> interface.

You may need to use http://127.0.0.1:8080/ to reliably reproduce this. On some 
systems "localhost" resolves to the external address.

Paul


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

[Qemu-devel] [PATCH] Fix to gdb - wrong translation block invalidated when setting gdb breakpoints

2005-12-23 Thread Andre Pech 
Hi all,
I had been running into problems using gdb to debug the virtual machine
kernel. The problem I was experiencing is that I would set a
breakpoint, but that gdb would only sometimes get notified that the
breakpoint was hit. 
I finally tracked down the problem to exec.c:breakpoint_invalidate. The
problem is that breakpoint_invalidate, which is supposed to invalidate
the translation block for the address you want to break at, was
actualling invalidating the translation block for the base address of
the page that contained your breakpoint address. The fix is actually
very simple and is attached below.
Thanks
Andre Pech


diff -dc exec.c{.old,}
*** exec.c.old    2005-12-23 11:40:47.0 -0800
--- exec.c    2005-12-23 11:41:13.0 -0800
***
*** 996,1001 
--- 996,1002 
  target_ulong phys_addr;
  
  phys_addr = cpu_get_phys_page_debug(env, pc);
+ phys_addr += pc & (~TARGET_PAGE_MASK);
  tb_invalidate_phys_page_range(phys_addr, phys_addr + 1, 0);
  }
  #endif
On 12/21/05, Mulyadi Santosa <[EMAIL PROTECTED]
> wrote:
Hello Andre...> I'm running into problems using qemu to debug a kernel module. My> host and virtual machine are both x86 running Fedora Core 4. After> insmoding the module in the virtual machine, starting gdbserver,
> running gdb on the host with the module sections loaded at the right> place, and setting a breakpoint in the module code, gdb does not> always get notified when the code is exectuted. After adding

I'm not doing module debugging, only core kernel code debugging, butmore or less I run into same situation (last time confirmed with Qemu0.7.1)For additional info, sometimes I also suffered the other condition.
Breakpoint is hit, but even if I delete it, the emulation still stopswhenever the code at related physical address is hit. I tried toprintf() every gdb command received by Qemu's gdbstub and it confirmedthat breakpoint deletion command is actually received, but I can't
confirm what is the real bug there.regardsMulyadi

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

Re: [Qemu-devel] Argos: qemu-based honeypot

2005-12-23 Thread Herbert Bos 

Tace,


Hi Herbert,
   I haven try it yet, but it seems very interesting! Btw, would it
be similar to the Minos (http://minos.cs.ucdavis.edu/) system,
implemented using Bochs?
 

Yes, it is a bit like Minos, but (a) considerably faster than the Minos 
implementation on Bochs (but then Minos was intended as a hardware 
solution, and Argos is not), and (b) we have actually done a bit more 
than what we have now released. For instance, we also implemented an 
automated signature generator, that makes an attempt to figure out which 
application is attacked (or indeed the kernel) and generates a Snort 
signature that can be used to block the worm. It is currently not stable 
enough to release. We do have a TR that describes how it works. Drop me 
an email and I will send it to you. In addition, we are working on a 
more advanced signature generator.


My knowledge of Minos is admittedly limited, but I also think it simpler 
to 'do stuff' in Argos (e.g., deal with register spring attacks) as we 
have convenient access to all aspects of the machine and both physical 
and virtual addresses. I realise this is a little speculative - perhaps 
a Minos person could comment.


HJB


On 12/21/05, Herbert Bos <[EMAIL PROTECTED]> wrote:

/ All,/
/ I am happy to announce the first release of Argos: a full system/
/ emulator (based on Qemu) that detects attempts to compromise the system./
/ It is meant to be used in a honeypot and offers full-system protection,/
/ i.e., it protects the kernel and all applications running on top./

/ Argos is  hosted at: http://www.few.vu.nl/~porto/argos 
/

/ Note: while there is a full installation guide and info on how to run/
/ Argos, there is currently little additional documentation. We will add/
/ this as soon as possible. People interested in details should contact us/
/ for a technical report (the paper is currently under submission, so we/
/ cannot stick it on the website yet)./

/ Cheers,/
/ HJB/

/ Here is the blurb from the website./

/ Argos is a /full/ and /secure/ system emulator designed for use in/
/ Honeypots. It is based on QEMU ,/
/ an open source processor emulator that uses dynamic translation to/
/ achieve a fairly good emulation speed./

/ We have extended QEMU to enable it to detect remote attempts to/
/ compromise the emulated guest operating system. Using dynamic taint/
/ analysis Argos tracks network data throughout the processor's execution/
/ and detects any attempts to use them in a malicious way. When an attack/
/ is detected the memory footprint of the attack is logged and the/
/ emulators exits./

/ Argos is the first step to create a framework that will use /next/
/ generation honeypots/ to automatically identify and produce remedies for/
/ zero-day worms, and other similar attacks. /Next generation honeypots//
/ should not require that the honeypot's IP address remains un-advertised./
/ On the contrary, it should attempt to publicise its services and even/
/ actively generate traffic. In former honeypots this was often/
/ impossible, because malevolent and benevolent traffic could not be/
/ distinguished. Since Argos is explicitly signaling each possibly/
/ successful exploit attempt, we are now able to differentiate malicious/
/ attacks and innocuous traffic./

/ ---/

/ Dr. Herbert Bos/
/ Vrije Universiteit Amsterdam/
/ www.cs.vu.nl/~herbertb/




/ ___/
/ Qemu-devel mailing list/
/ [EMAIL PROTECTED]/
/ http://lists.nongnu.org/mailman/listinfo/qemu-devel/







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

[Qemu-devel] New BIOS project

2005-12-23 Thread Cesare Leonardi 
Maybe some of you already knows that, but seems that a new BIOS project 
is started and seems promising. It is principally related to Bochs, but, 
if it goes on, will have consequences also on Qemu.


I suggest to read the latest discussion on the bochs-developers mailing 
list and to visit the project site: http://bcos.hopto.org/bios.html.


Regards.

Cesare.


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