From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id C8586384EF5F for ; Fri, 25 Nov 2022 16:23:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C8586384EF5F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.cz Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 160E221B08; Fri, 25 Nov 2022 16:23:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1669393428; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=g7lq5qAOsX8qiFq+du/Zi0YNK+X4sJg69YwPIvFGfIU=; b=3FVNI7b3Sb5vutvSUAHIksXWyh/xZETxv6i/1sXLAA7raQ8pPqKsNc25LkktiEz6m+okh4 hNaBW4fgs3LIz6lCT35eRIqtFxO275pv6cyDSXXzYVnnAf9xlomshCEVC69028rMc5BLp4 +JC/81/R69l6wjhBUp4UHMEB4l9xCZU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1669393428; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=g7lq5qAOsX8qiFq+du/Zi0YNK+X4sJg69YwPIvFGfIU=; b=5ACZwT8OcJmlJUcpX0S9M5rbZHqScTdrz96yaLq/gC66yicITpAoaa9BvwwntnXXcyjten MNCvRwPEWYK/jABg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id F042D1361C; Fri, 25 Nov 2022 16:23:47 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id COx6ORPsgGNPJgAAMHmgww (envelope-from ); Fri, 25 Nov 2022 16:23:47 +0000 Message-ID: Date: Fri, 25 Nov 2022 17:23:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: About -fasan-shadow-offset option Content-Language: en-US To: "tao.zeng@amlogic.com" , gcc References: <20221116170140711269217@amlogic.com> Cc: Jakub Jelinek From: =?UTF-8?Q?Martin_Li=c5=a1ka?= In-Reply-To: <20221116170140711269217@amlogic.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_50,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 11/16/22 10:01, tao.zeng@amlogic.com wrote: > Dear gcc: > Hello. Based on quick discussion with Jakub, we believe fasan-shadow-symbol=xxxx would be a non-trivial amount of work and we rather suggest doing a per-system build with investigated -fasan-shadow-offset. Cheers, Martin > I am developing a address sanitiser tools for u-boot. Basically refers compile options from kernel side. But there is a problem that I must set -fasan-shadow-offset with a pre-calculated value. Otherwise GCC compiler will use 0x1000000000 as default value for shadow offset and caused boot failed because this value is too large. > The problem is uboot do not have a fixed memory layout as kernel. Basically it will relocate to end of DDR size and running at that memory space. Usually memory map for uboot is virt=phys and there are lots of drivers do not do address translate for dma based on this mapping. But ddr size are different on each platform. So it's hard to handle shadow offset at this scenario. > My point is that can gcc add an option like -fasan-shadow-symbol=xxxx, here xxxx is a global variable and implementors can configure it's value based on platforms ddr size/malloc buffer size during initialize stage and this variable can be used for shadow address calculation during runtime. This may be more fitable compared than a fixed value during compile stage. And is there any other options to help my problem? > Waiting for your response asap. > Thanks. > > > > Thanks! > B.R. > Tao.Zeng@amlogic.com > > Address： Building E5, 2555 Xiupu Road, Pudong District, Shanghai, China > 公司地址：上海市浦东新区秀浦路2555号漕河泾康桥商务绿洲E5栋 >