From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JlMu9-0005UP-E7 for qemu-devel@nongnu.org; Mon, 14 Apr 2008 07:31:21 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JlMu7-0005Sc-Md for qemu-devel@nongnu.org; Mon, 14 Apr 2008 07:31:21 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JlMu7-0005SR-Hd for qemu-devel@nongnu.org; Mon, 14 Apr 2008 07:31:19 -0400 Received: from www.seclab.tuwien.ac.at ([128.130.60.29] helo=mail.seclab.tuwien.ac.at) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JlMu7-0007Er-2Q for qemu-devel@nongnu.org; Mon, 14 Apr 2008 07:31:19 -0400 Received: from ckol.seclab.tuwien.ac.at (ckol.seclab.tuwien.ac.at [128.130.60.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.seclab.tuwien.ac.at (Postfix) with ESMTP id 26DD431248 for ; Mon, 14 Apr 2008 13:30:55 +0200 (CEST) From: Clemens Kolbitsch Date: Mon, 14 Apr 2008 13:32:04 +0200 References: <200804141216.08755.ck@iseclab.org> In-Reply-To: <200804141216.08755.ck@iseclab.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200804141332.05347.ck@iseclab.org> Subject: [Qemu-devel] Re: dyngen_code in 16 bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Monday 14 April 2008 12:16:08 you wrote: > Hi! > For a research project I extended Qemu to include some extra code inside > the op_XXX instructions that increased the generated TB-code's size to > quite some extend... > > Now I have a problem when having block chaining enabled (that I don't want > to disable for performance reasons :-/): The code_gen_buffer sometimes > contains code areas that span more than 0xffff bytes, however, dyngen and > all functions related to it use 16 bit pointers, etc. Therefore, e.g. the > dyngen_code function uses the 16 bit pointers to overwrite certain params > and of course destroys the TB-code. > > When working with x86 hosts and guests (both 32 bit), is there a specific > reason for all these pointers to be 16 bits or has it just been a safe > assumption up to now?? I have tried rewriting the code to use 32 bit, but > keep getting segfaults... however, of course, I might have missed some code > still. Hi again! I have further modified the code replacing 16 bit pointers with 32 bits (e.g. cpu_gen_code(CPUState *env, TranslationBlock *tb, int max_code_size, int *gen_code_size_ptr) to cpu_gen_code(CPUState *env, TranslationBlock *tb, unsigned int max_code_size, unsigned int *gen_code_size_ptr) ) (note the signed/unsigned) and the problems seem to be gone. ATTENTION: dyngen_code returns a signed integer!! Although _normal_ code does not generate that big TBs, there is a bug if it does... consider the following code from translate-all.c: gen_code_size = dyngen_code(gen_code_buf, tb->tb_next_offset, #ifdef USE_DIRECT_JUMP tb->tb_jmp_offset, #else NULL, #endif gen_opc_buf, gen_opparam_buf, gen_labels); } *gen_code_size_ptr = gen_code_size; if (gen_code_buf + gen_code_size > code_gen_buffer + CODE_GEN_BUFFER_SIZE) { printf("gen_code_buffer overflow!\n"); exit(1); } gen_code_size is signed as well --> if we handle large buffers, the return value will eventually be negative, causing the security-check below to fail, although it shouldn't!!! Do you think it is worth writing a patch?? (Because a sane configuration of MAX_OP_PER_INSTR and OPC_BUF_SIZE can circumvent the problem...). If you do think so, I'll post my patch, as soon as I get around making one (I'm using a _very_ modified version right now...) Cheers