Re: [Qemu-devel] QEMU GUI
In message: <[EMAIL PROTECTED]> Johannes Schindelin <[EMAIL PROTECTED]> writes: : > I personally don't like tcl as a language, and prefer to code in C++ for : > efficiency. : : Hmmm. "C++" and "efficiency" _does_ constitute a contradiction. Just think : "operator+()". Honestly, the most inefficient code I saw was done in C++. : You really should get a weapon's license before coding in C++. You can hunt game or foot with C++. Only one will feed your family :-) Warner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] MIPS instruction set configuration
Thiemo Seufer wrote: ... I recommend to go for a sufficiently flexible interface first, and then introduce it gradually in all appropriate places. A macro like: MIPS_OPC(ISA, ASE, CPU) which compares the arguments with the currently selected CPU emulation and throws an RI exception if the feature doesn't exist: ... case OPC_LD: MIPS_OPC(MIPS-III, 0, 0); ... break; ... ... My point is those MIPS_USES_*/MIPS_FEATURE_* should be abstracted better, that is, they should move in the implementation of the MIPS_OPC macro. I really like your proposals of MIPS_OPC() and better abstraction of MIPS_USES_*/MIPS_FEATURE_*! Do you think you can post a patch which introduces the basic parts of this functionality in the short term? Then we can use it as a starter for more improvements. This is not meant as an objection, I'm just drawing from experience with binutils, where it took some iterations (and wasted effort) to get it sufficiently right. You are right with your wasted effort argument above as well. However, my patch does not only introduce MIPS_USES_*/MIPS_FEATURE_*. It additionally introduces cpu_mips_set_model() (yes, I know, this can be improved as well, as Fabrice mentioned). So it shouldn't be to much wasted effort to keep the cpu_mips_set_model() and convert the three or four places of my MIPS_USES_*/MIPS_FEATURE_* to your MIPS_OPC abstraction (in case my patch is accepted ;) ). Btw, while talking about cpu_mips_set_model(): While thinking about it I found that we should try to keep the generic parts of cpu and model selection logic in sync with other architectures, I think at least with ARM (where possible). There will be differences in details like in instruction set splitting with your MIPS_OPC logic. But would be nice if we make generic improvements to e.g. cpu_mips_set_model() at MIPS, we make the same at ARM as well. ... Well, there is no CPU named "R4Kc". What qemu emulates today resembles mostly a 4kc, that is a MIPS32R1 CPU which has no FPU support. Yes, I understand this. But two things: First, in the current MIPS configuration FPU is enabled for "R4Kc". I think we shouldn't disable anything what is there at the moment, without giving an alternative for people using this (e.g. introducing an additional machine). And this only because there is no real world equivalent for this. Second, while I agree that there is no real world equivalent for this, I think this is one of the biggest advantages of a simulator like qemu: Your are able to configure and test machine and feature combinations which will never exist in real world really quickly. This second point is "the simulated machines should model the real world 110% exactly" vs "I don't need 100% simulation accuracy and wan't to be able to use configurations which are not possible in real world". Depends on how people will use qemu. I think while the first argument may be valid for x86 where people want to run e.g. Windows on Linux, for embedded processors like ARM or MIPS the second may be valid and interesting as well. Cheers Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] MIPS instruction set configuration
Fabrice Bellard wrote:
Dirk Behme wrote:
Fabrice Bellard wrote:
Each machine can add specific support for that (for example a -cpu
option). It is likely to come at least for the PC machines.
I add suggest one more parameter to cpu_mips_set_model() to specify
optional features. A function converting a CPU "string id" into an id
+ features would be interesting too.
Fabrice, do you will accept the patch if I remove the
MIPS_FEATURE_ISAx options and convert MIPS_FEATURE_NEC_EXT to
MIPS_FEATURE_NEC_VR5400 as described in my previous mail?
Yes. Even without I can accept it as it is better than what we
previously had.
Please find as promised in attachment the updated version of
this patch. It removes MIPS_FEATURE_ISAx for the moment and
renames MIPS_FEATURE_NEC_EXT to MIPS_FEATURE_NEC_VR5400.
Best regards
Dirk
--- ./hw/mips_r4k.c_orig2006-07-08 07:16:50.0 +0200
+++ ./hw/mips_r4k.c 2006-07-08 07:16:45.0 +0200
@@ -189,10 +189,10 @@ CPUReadMemoryFunc *io_read[] = {
&io_readl,
};
-void mips_r4k_init (int ram_size, int vga_ram_size, int boot_device,
-DisplayState *ds, const char **fd_filename, int snapshot,
-const char *kernel_filename, const char *kernel_cmdline,
-const char *initrd_filename)
+void mips_r4kc_init (int ram_size, int vga_ram_size, int boot_device,
+ DisplayState *ds, const char **fd_filename, int snapshot,
+ const char *kernel_filename, const char *kernel_cmdline,
+ const char *initrd_filename)
{
char buf[1024];
int64_t entry = 0;
@@ -203,6 +203,7 @@ void mips_r4k_init (int ram_size, int vg
long kernel_size;
env = cpu_init();
+cpu_mips_set_model(env, MIPS_R4Kc);
register_savevm("cpu", 0, 3, cpu_save, cpu_load, env);
/* allocate RAM */
@@ -284,8 +285,8 @@ void mips_r4k_init (int ram_size, int vg
}
}
-QEMUMachine mips_machine = {
-"mips",
-"mips r4k platform",
-mips_r4k_init,
+QEMUMachine mips_r4kc_machine = {
+"r4kc",
+"mips r4kc platform",
+mips_r4kc_init,
};
--- ./vl.h_orig 2006-07-08 07:16:51.0 +0200
+++ ./vl.h 2006-07-08 07:16:45.0 +0200
@@ -917,7 +917,7 @@ extern QEMUMachine core99_machine;
extern QEMUMachine heathrow_machine;
/* mips_r4k.c */
-extern QEMUMachine mips_machine;
+extern QEMUMachine mips_r4kc_machine;
/* shix.c */
extern QEMUMachine shix_machine;
--- ./target-mips/cpu.h_orig2006-07-08 07:16:50.0 +0200
+++ ./target-mips/cpu.h 2006-07-08 07:23:52.0 +0200
@@ -210,6 +210,8 @@ struct CPUMIPSState {
int bcond; /* Branch condition (if needed) */
int halted; /* TRUE if the CPU is in suspend state */
+
+uint32_t features; /* Internal CPU feature flags */
CPU_COMMON
};
@@ -275,5 +277,30 @@ enum {
int cpu_mips_exec(CPUMIPSState *s);
CPUMIPSState *cpu_mips_init(void);
uint32_t cpu_mips_get_clock (void);
+void cpu_mips_set_model(CPUMIPSState *env, uint32_t id);
+
+enum mips_features {
+MIPS_FEATURE_R4K_EXT = 0x1, /* instruction set extension for MIPS R4K */
+MIPS_FEATURE_NEC_VR5400 = 0x2, /* instruction set extension for NEC VR5400
CPUs */
+MIPS_FEATURE_FPU = 0x4, /* floating point instruction set */
+};
+
+#ifdef MIPS_USES_R4K_EXT
+#define mips_uses_r4k_ext() (env->features & MIPS_FEATURE_R4K_EXT)
+#else
+#define mips_uses_r4k_ext() 0
+#endif
+
+#ifdef MIPS_USES_NEC_VR5400
+#define mips_uses_nec_vr5400() (env->features & MIPS_FEATURE_NEC_VR5400)
+#else
+#define mips_uses_nec_vr5400() 0
+#endif
+
+#ifdef MIPS_USES_FPU
+#define mips_uses_fpu() (env->features & MIPS_FEATURE_FPU)
+#else
+#define mips_uses_fpu() 0
+#endif
#endif /* !defined (__MIPS_CPU_H__) */
--- ./target-mips/translate.c_orig 2006-07-08 07:16:50.0 +0200
+++ ./target-mips/translate.c 2006-07-08 07:22:48.0 +0200
@@ -1887,7 +1887,7 @@ static void gen_blikely(DisasContext *ct
gen_set_label(l1);
}
-static void decode_opc (DisasContext *ctx)
+static void decode_opc (CPUState *env, DisasContext *ctx)
{
int32_t offset;
int rs, rt, rd, sa;
@@ -1927,7 +1927,17 @@ static void decode_opc (DisasContext *ct
gen_arith(ctx, op1 | EXT_SPECIAL, rd, rs, rt);
break;
case 0x18 ... 0x1B: /* MULT / DIV */
-gen_muldiv(ctx, op1 | EXT_SPECIAL, rs, rt);
+ if(!sa) {
+gen_muldiv(ctx, op1 | EXT_SPECIAL, rs, rt);
+ } else {
+ if(mips_uses_nec_vr5400()) {
+ op1 = ctx->opcode & 0x7FF;
+ /* tbd: call handler for special NEC instructions */
+} else {
+ MIPS_INVAL("NEC extension");
+generate_exception(ctx, EXCP_RI);
+}
+}
break;
case 0x08 ... 0x09: /* Jumps */
gen_compute_branch(ctx, op1 | EXT_SPECIA
Re: [Qemu-devel] QEMU GUI
Hi, On Sat, 8 Jul 2006, Chris Wilson wrote: > I personally don't like tcl as a language, and prefer to code in C++ for > efficiency. Hmmm. "C++" and "efficiency" _does_ constitute a contradiction. Just think "operator+()". Honestly, the most inefficient code I saw was done in C++. You really should get a weapon's license before coding in C++. > GTK is also specific to Unix (not Mac) and Windows, and looks weird on > Windows, not very native. Again, hmmm. I do not agree with that "weird" argument. It is no more weird than _every single_ Windows version completely changing the look&feel, let alone the location of menu items. And they still do not provide anything akin to a "Help", because "Windows help" sure does not deserve that name. Rather "Welcome to hell" or something similar. An important point to make is, GTK is in C, which means that even Microsoft based compilers respect the same ABI as anyone else (that is probably the reason they advertise C++ and C#, and not C, even if everything they produce is still C compatible, which is very visible in their APIs). WxLib is in C++, which means you cannot link with g++ if the lib was compiled with MSVC, and vice-versa. Thank you very much. > > The main/only point of wx is that mimics quite well some sort of native > > look&feel, and that is just nice if you have to handle windows users or > > idiotic managers. > > Or platforms other than Windows and Unix. If in doubt, take Java. At least starting with Mustang, it really does a great job pleasing anyone married to their particular platform's look&feel. Plus, Java code really runs everwhere without recompiling. As opposed to C#, I might add. Ciao, Dscho ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU GUI
Hi Luca, Not wishing to start an argument, just to learn: On Wed, 5 Jul 2006, Luca Barbato wrote: The library is incompatible with itself depending on the configure time options (see string constructors vs unicode string constructors) It's perfectly possible to write code that compiles and works fine on Unicode and non-Unicode builds (with wxT() macros). Its ABI/API changes too often (ok, that is the result of they fixing lots of bugs that require radical changes, but they could haven't been on first place...) Not sure about ABI changes, but as far as I can see, they work hard to avoid incompatible API changes in stable branches, e.g. wx 2.6.x. Its architecture is a tad old. But if you change it, then you break backwards compatibility. You can't have it both ways. Besides, what's wrong with the "old" architecture? Try Qt or ewl/etk if you don't like the default tcl/tk look, all 4 are quite nicer architecture-wise and less painful to be handled as dependence. QT is only now free on Windows, and supports far fewer platforms than wx (no Mac support?). I personally don't like tcl as a language, and prefer to code in C++ for efficiency. MFC and winapi are surely worst than wx, gtk on the other hand is simple and relatively easy to learn. GTK is also specific to Unix (not Mac) and Windows, and looks weird on Windows, not very native. The main/only point of wx is that mimics quite well some sort of native look&feel, and that is just nice if you have to handle windows users or idiotic managers. Or platforms other than Windows and Unix. Cheers, Chris. -- _ ___ __ _ / __/ / ,__(_)_ | Chris Wilson < at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] New hardware emulation
Hi, Can I add code to model additional hardware in Qemu? Specifically, I want to add a tracing module that dumps out the virtual and physical address of the executing program's instruction and data accesses. (I can't figure out if Qemu models the mmu) Thanx __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: Have any ideas about how to detect whether a program is running inside QEMU?
On Fri, 07 Jul 2006 10:07:47 +0200, G Portokalidis wrote:
> Actually, i have also noticed this.
> It implies that an exploit might not succeed (this usually the case with
> most exploits), since the attacker supplied shellcode will not be at the
> "expected" location.
>
> My question is, does anybody know why this happens? Why this difference
> when running qemu with kqemu and without... I wonder if there is way to
> override this behaviour.
It's because kqemu is shadowing the IDT. kqemu happens to be using high
vaddr space to do this.
kqemu needs to shadow the IDT so that traps are delivered to it (instead
of directly to the guest).
Regards,
Anthony Liguori
>
> Cheers,
> G.
>
> PS: I'm also responsible for the qemu derivative Argos. We make sure that
> the attacker will never get to run his code to determine whether he is
> running withing a VM. Of course there always some type of attacks that we
> would not be able to detect.
>
> On 07/07/06, Kevin F. Quinn <[EMAIL PROTECTED]> wrote:
>> On Thu, 6 Jul 2006 16:46:40 -0400
>> Daniel Serpell <[EMAIL PROTECTED]> wrote:
>>
>> > But there is a way to detect virtual machines under x86, see
>> > http://invisiblethings.org/papers/redpill.html
>> >
>> > But if you run qemu without direct instruction copying, it won't work
>> > (and qemu will run slower), because qemu will correctly emulate the
>> > unprivileged instructions.
>>
>> Out of interest, sidt returns limit:base 07ff:c0372000 on my host, and
>> 07ff:f005 on a linux guest with kqemu, and 07ff:c04b5000 on the same
>> linux guest without kqemu, which illustrates the point.
>>
>> I used the following code:
>>
>> #include
>> int main(int argc, char **argv) {
>> unsigned char idtr[6];
>> __asm__ ("sidt %0" : "=m" (*&idtr));
>> fprintf(stdout,
>> "IDTR: limit %2.2x%2.2x base %2.2x%2.2x%2.2x%2.2x\n",
>> idtr[1],idtr[0],idtr[5],idtr[4],idtr[3],idtr[2]);
>> }
>> }
>> which doesn't need executable heap (my kernel is PaX-enabled), unlike
>> the redpill version, but is gcc-specific.
>>
>> --
>> Kevin F. Quinn
>>
>>
>> ___ Qemu-devel mailing list
>> Qemu-devel@nongnu.org
>> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>>
>>
>>
>>
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Why do qemumenu.bat show such error mess age?
When I had installed qemu(Host OS: win98),I execute qemumenu.bat.Unfortunately,qemumenu.bat shows lots of error messages,as follows: >Bad command or file name>Bad command or file name>Invalid directory>Syntax error>Syntax error>Bad command or file name>Syntax error>QEMU_BIOS_DIR=>Bad command or file name>=== QEMU Menu ^(v20041121^) ===> QEMU Menu (C) 2004 Garth Dahlstrom ([EMAIL PROTECTED])> QEMU (C) 2004 Fabrice Bellard>>QEMU Settings:> Memory ^(^MB^) BIOS DIR ^(^)> ISO/CD ^(^)> Network ^(^)>>Boot QEMU using image:>Bad command or file name>Syntax error>Bad command or file name>Syntax error> No image files found^^!^^! > (you must [C]reate an image to use QEMU) && echo.>>Settings/Toggles:> ^[C^]reate image file ^[M^]emory ^[I^]SO/CD ^[N^]etwork ^[Q^]uitStarting !QEMU_IMG! ...>>>^[ ^] qemu.exe -L "" -m -hda "!QEMU_IMG!" -enable-audio -localtime>Bad command or file name>Syntax error>Press any key to continue . . . Could you explain the reasons about these error messages ? Best regardsmathew 半 价 夏 日 特 卖，上 易 趣 ! ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PCI bridging
On Friday 07 July 2006 17:31, Palleni, F. - Franco - wrote: > Hi to All, > > i'm writing to propose a feature, I would like to insert in qemu > machine some hardware installed in host PC like a frame grabber, or > other special hardware. How do you thimk about this features? it sould > be implemented like kemu accelerator or somting like that. This has been discussed a coupe of times before[1]. Short answer is that it requires either guest OS support (and corresponding support in the guest OS drivers), or that the device does not use DMA. Paul [1] http://lists.gnu.org/archive/html/qemu-devel/2006-01/msg00082.html ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] PCI bridging
Hi to All, i'm writing to propose a feature, I would like to insert in qemu machine some hardware installed in host PC like a frame grabber, or other special hardware. How do you thimk about this features? it sould be implemented like kemu accelerator or somting like that. Regards Franco ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] add 'monitor' and 'mwait' instruction
Maybe there are some further issues in your setup. Could you please provide more detailed kernel messages (regarding the panic)? Thanks, Jo. maestro wrote: hello just tested the patch against 0.8.1 and current cvs and at least here it does not work: still Kernel panic - not syncing: Attempted to kill init! -- Joachim Henke http://he-jo.net/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Trapping ctrl-c
On Fri, 2006-07-07 at 11:00 -0400, WaxDragon wrote: > It's a nice idea, but awfully *nix specific. ;0) True, but it could be supplemented by the same idea when a user presses the close button on the gui window. That could work on all versions. -- Martin. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Trapping ctrl-c
It's a nice idea, but awfully *nix specific. ;0) On 7/7/06, Martin Garton <[EMAIL PROTECTED]> wrote: Hi, Now that ACPI is supported, does anyone agree that it would make sense to trap SIGINT (any perhaps SIGTERM) and use it to generate an acpi power button event? That way, operating systems that support it could shut down cleanly. This would be particularly useful when you have multiple qemu instances running with the vnc option and would mean the user does not have to use vnc multiple times to shut down but instead could just do "killall qemu" -- Martin. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- why does the size matter? ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Could not open kqemu and load bios.bin
赵刚 wrote: > When I use qemu,I encouner these error messages,as follows: > " > C:\Program Files\Qemu>qemu BL3.4-qemu.img > Could not open '\\.\kqemu' - QEMU acceleration layer not activated > qemu: could not load PC bios '/c/Program Files/Qemu/bios.bin' > " > In fact, the directory (C:\Program Files\Qemu) has the file:bios.bin. > > Could you explain the reasons about these error messages ? On Windows host you're required to specify the location of the bios-file (with -L parameter). For kqemu.sys to work with Windows you have to install the bundled .inf-file to get it working iirc. Jan ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Trapping ctrl-c
Hi, Now that ACPI is supported, does anyone agree that it would make sense to trap SIGINT (any perhaps SIGTERM) and use it to generate an acpi power button event? That way, operating systems that support it could shut down cleanly. This would be particularly useful when you have multiple qemu instances running with the vnc option and would mean the user does not have to use vnc multiple times to shut down but instead could just do "killall qemu" -- Martin. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Could not open kqemu and load bios.bin
When I use qemu,I encouner these error messages,as follows:"C:\Program Files\Qemu>qemu BL3.4-qemu.imgCould not open '\\.\kqemu' - QEMU acceleration layer not activatedqemu: could not load PC bios '/c/Program Files/Qemu/bios.bin'" In fact, the directory (C:\Program Files\Qemu) has the file:bios.bin. Could you explain the reasons about these error messages ? 半 价 夏 日 特 卖，上 易 趣 ! ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] add 'monitor' and 'mwait' instruction
Try zcat mwait.diff.gz | patch -p0 in the source directory. Am 07.07.2006 um 14:57 schrieb maestro: btw: when i patch < mwait.diff in the qemu-src directory patch cannot find the files to patch and asks me for their location - did i do anything wrong? -- Joachim Henke http://he-jo.net/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] add 'monitor' and 'mwait' instruction (update)
The last patch I sent, enabled the MONITOR cpuid flag for testing purposes. So Linux guests won't execute the 'hlt' instruction anymore. Since we don't really emulate an 'mwait' instruction, this leads to high cpu usage on the host, even when the guest cpu is idle. Please use the updated patch attached below. Sorry, Jo. Joachim Henke wrote: Could you please check, if the attached patch works for you? A quick test showed that Linux boots fine with the MONITOR flag set now. This patch adds 'monitor' and 'mwait' as nops, as suggested by Fabrice. -- Joachim Henke http://he-jo.net/ mwait.diff.gz Description: GNU Zip compressed data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] add 'monitor' and 'mwait' instruction
Am Freitag, den 07.07.2006, 14:30 +0200 schrieb Joachim Henke: > Could you please check, if the attached patch works for you? A quick > test showed that Linux boots fine with the MONITOR flag set now. > > This patch adds 'monitor' and 'mwait' as nops, as suggested by Fabrice. > hello just tested the patch against 0.8.1 and current cvs and at least here it does not work: still Kernel panic - not syncing: Attempted to kill init! im on a pentium D with ubuntu 6.06server as guest os (debian sarge host) cheers m btw: when i patch < mwait.diff in the qemu-src directory patch cannot find the files to patch and asks me for their location - did i do anything wrong? ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] add 'monitor' and 'mwait' instruction
Could you please check, if the attached patch works for you? A quick test showed that Linux boots fine with the MONITOR flag set now. This patch adds 'monitor' and 'mwait' as nops, as suggested by Fabrice. Regards, Jo. Am 06.07.2006 um 17:13 schrieb R. Armiento: Uncompressing Linux... Ok, booting the kernel ACPI: Unable to locate RSDP PCI: PIIX3: Enabling Passive Release on :00:01.0 Invalid operand: [#1] PREEMPT Modules linked in: CPU 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00010246 (2.6.15-23-386) EIP is at mwait_idle+0x16/0x30 [... register dump, etc ...] <0>Kernel panic - not syncing: Attempted to kill the id -- Joachim Henke http://he-jo.net/ mwait.diff.gz Description: GNU Zip compressed data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Pentium D with guest Ubuntu 6.06 server kernel panic with kqemu
R. Armiento wrote: The error looks very similar to the one reported here: http://www.mail-archive.com/qemu-devel@nongnu.org/msg03964.html But I believe that reported issue should not appear in recent qemu, since SSE3 is now emulated (right?). (At least the patch in the end of that thread seems to already be included in the sources?) Joachim Henke wrote: Yes, this patch was included, but it doesn't solve that problem. As this message [http://www.mail-archive.com/qemu-devel@nongnu.org/msg03972.html] states, the 'monitor' and the 'mwait' instructions have not been added. But your guest OS assumes them to be present, because your host cpu has the MONITOR flag set in CPUID. I see; so the issue I reported is in fact the exact same issue as the one reported in march. And the situation is that we are waiting for some kind soul to implement the monitor/mwait instructions (and according to Fabrice in that thread "doing nops should suffice"). (While I am able to boot with idle=halt, I'm still worried that some other software than Linux idle function will happen to also use the wrongly declared MONITOR feautre and crash the emulated host...) Best regards, Rickard ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] AFXS
It seems to me that AXFS (Advanced XIP File System) could be useful for Linux guest under QEMU. -Nigel begin:vcard fn:Nigel Horne n:Horne;Nigel org:NJH Music email;internet:[EMAIL PROTECTED] tel;fax:+44 870 705 9334 note:Skype: nigelhorne x-mozilla-html:FALSE version:2.1 end:vcard ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Pentium D with guest Ubuntu 6.06 server kernel panic with kqemu
On Fri, Jul 07 2006, Joachim Henke wrote: > Yes, this patch was included, but it doesn't solve that problem. As > this message [http://www.mail-archive.com/qemu-devel@nongnu.org/ > msg03972.html] states, the 'monitor' and the 'mwait' instructions > have not been added. But your guest OS assumes them to be present, > because your host cpu has the MONITOR flag set in CPUID. > > Jo. > > R. Armiento wrote: > >The error looks very similar to the one reported here: > > http://www.mail-archive.com/qemu-devel@nongnu.org/msg03964.html > >But I believe that reported issue should not appear in recent qemu, > >since SSE3 is now emulated (right?). (At least the patch in the end > >of that thread seems to already be included in the sources?) > > > >So, my hypothesis is that there is some other feature that appears > >in my host CPUID, which the booting linux image tries to make use > >of, but which qemu does not emulate. Until that gets fixed up, you can boot with idle=halt. -- Jens Axboe ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Pentium D with guest Ubuntu 6.06 server kernel panic with kqemu
Yes, this patch was included, but it doesn't solve that problem. As this message [http://www.mail-archive.com/qemu-devel@nongnu.org/ msg03972.html] states, the 'monitor' and the 'mwait' instructions have not been added. But your guest OS assumes them to be present, because your host cpu has the MONITOR flag set in CPUID. Jo. R. Armiento wrote: The error looks very similar to the one reported here: http://www.mail-archive.com/qemu-devel@nongnu.org/msg03964.html But I believe that reported issue should not appear in recent qemu, since SSE3 is now emulated (right?). (At least the patch in the end of that thread seems to already be included in the sources?) So, my hypothesis is that there is some other feature that appears in my host CPUID, which the booting linux image tries to make use of, but which qemu does not emulate. -- Joachim Henke http://he-jo.net/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Have any ideas about how to detect whether a program is running inside QEMU?
Actually, i have also noticed this.
It implies that an exploit might not succeed (this usually the case
with most exploits), since the attacker supplied shellcode will not be
at the "expected" location.
My question is, does anybody know why this happens? Why this
difference when running qemu with kqemu and without...
I wonder if there is way to override this behaviour.
Cheers,
G.
PS: I'm also responsible for the qemu derivative Argos. We make sure
that the attacker will never get to run his code to determine whether
he is running withing a VM. Of course there always some type of
attacks that we would not be able to detect.
On 07/07/06, Kevin F. Quinn <[EMAIL PROTECTED]> wrote:
On Thu, 6 Jul 2006 16:46:40 -0400
Daniel Serpell <[EMAIL PROTECTED]> wrote:
> But there is a way to detect virtual machines under x86, see
> http://invisiblethings.org/papers/redpill.html
>
> But if you run qemu without direct instruction copying, it won't
> work (and qemu will run slower), because qemu will correctly
> emulate the unprivileged instructions.
Out of interest, sidt returns limit:base 07ff:c0372000 on my
host, and 07ff:f005 on a linux guest with kqemu, and 07ff:c04b5000
on the same linux guest without kqemu, which illustrates the point.
I used the following code:
#include
int main(int argc, char **argv) {
unsigned char idtr[6];
__asm__ ("sidt %0" : "=m" (*&idtr));
fprintf(stdout,
"IDTR: limit %2.2x%2.2x base %2.2x%2.2x%2.2x%2.2x\n",
idtr[1],idtr[0],idtr[5],idtr[4],idtr[3],idtr[2]);
}
which doesn't need executable heap (my kernel is PaX-enabled), unlike
the redpill version, but is gcc-specific.
--
Kevin F. Quinn
___
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
