From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id +Uk3ADMWfWAnaQAAWB0awg (envelope-from ) for ; Mon, 19 Apr 2021 01:33:39 -0400 Received: by simark.ca (Postfix, from userid 112) id E58331F104; Mon, 19 Apr 2021 01:33:38 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 3EDC31E54D for ; Mon, 19 Apr 2021 01:33:38 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DE08C3953420; Mon, 19 Apr 2021 05:33:37 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DE08C3953420 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1618810417; bh=Ridfw5TYXpOogLhGfod9wZ6N7HQfnAogEeAFd5Bz9zw=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=ZpJAnYGl5tRK0l3CJ8nb1lcdcl2XFoykZ29+U1/xMWmY/EH68Ts2HbjeNIteW7SI4 O8Pr2eNO0DR7uqdZhOinUxGojk8Er2YRexOR+i4LtP/tdQWUDRtdOBt7y6lraxFwlC VJ0IItfJ7ZZeWD2rPdL+LEI9ESnjKPc/ydPuoYR4= Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by sourceware.org (Postfix) with ESMTP id 16BE13953420 for ; Mon, 19 Apr 2021 05:33:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 16BE13953420 Received: from vapier (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 3FDA8340E35; Mon, 19 Apr 2021 05:33:30 +0000 (UTC) Date: Mon, 19 Apr 2021 01:33:30 -0400 To: Jim Wilson Subject: Re: [PATCH 16/24] RISC-V sim: Check sbrk argument. Message-ID: Mail-Followup-To: Jim Wilson , gdb-patches@sourceware.org, Kito Cheng References: <20210417175831.16413-1-jimw@sifive.com> <20210417175831.16413-17-jimw@sifive.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210417175831.16413-17-jimw@sifive.com> X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Mike Frysinger via Gdb-patches Reply-To: Mike Frysinger Cc: Kito Cheng , gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 17 Apr 2021 10:58, Jim Wilson wrote: > + { > + if (cpu->a0 >= DEFAULT_MEM_SIZE) > + cpu->a0 = -1; > + else > + cpu->endbrk = cpu->a0; > + } this incorrectly assumes that DEFAULT_MEM_SIZE is always the limit when it's not: that is simply the default memory size if the user hasn't specified one. so it could be larger or smaller. if it were larger, it'd mean the program would fail w/OOM even if the user had configured the sim specifically to have more resources. if it were smaller, it'd return success when the memory isn't actually available. your best bet probably is to just probe the memory and see if it exists. look at how sim_core_read_buffer is used in riscv/interp.c:sim_open. it would mean the code would fail if the user had MMIO at much higher addresses and then the program passed that address here, but making the code more precise is kind of hard, especially when you consider the user could just create a bunch of random memory stripes. 0000-1000: RAM 1000-2000: Nothing 2000-3000: RAM 3000-4000: Nothing 4000-5000: RAM 5000-6000: Nothing 6000-7000: RAM ... easier to just document this brk behavior and call it a day rather than try to protect against overtly pathological scenarios. -mike