From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx-rz-1.rrze.uni-erlangen.de (mx-rz-1.rrze.uni-erlangen.de [131.188.11.20]) by sourceware.org (Postfix) with ESMTPS id 43D4E3858D1E for ; Wed, 20 Mar 2024 15:49:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 43D4E3858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=fau.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=fau.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 43D4E3858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=131.188.11.20 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710949748; cv=none; b=n/nmKYVjo/9iVmcF45uaTlNRJdWHZxgH3ukpJzhvuQTP+TvzO+ziQpAig5dJNUdgtYJ6II7eYuIHzAGMzGQD276dJdXGvvOMEui+TnfN6Bte8GeQFm6NhnaYzOvkMmdi2ln/LG0slkT3S26UIU5ZbVWzKoMmN1PyhvAn62a7ZnM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710949748; c=relaxed/simple; bh=oM6RlejIKEN7+NgBYDJ2PLE48nWBQ7zScn+mEM3PH2s=; h=DKIM-Signature:Message-ID:Date:MIME-Version:To:From:Subject; b=AP9DGbqvMay8T7JzJSBsy94h/kSdKfZdsy/MSc6eUK6c2ohe0BNzbhJwiI0GAjalx0Us5Qk4hzMfh0YaCvYjaRvVDmboPSHvMEM1fsyznJ5fUuid3DovrVI5uPTBH4oWNXjs1WRNqtmv3zJOKB7C288sIUEyOZSsWrpHok7afGo= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from mx-rz-smart.rrze.uni-erlangen.de (mx-rz-smart.rrze.uni-erlangen.de [IPv6:2001:638:a000:1025::1e]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-rz-1.rrze.uni-erlangen.de (Postfix) with ESMTPS id 4V0Cgh4yHGz8shv for ; Wed, 20 Mar 2024 16:49:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fau.de; s=fau-2021; t=1710949744; bh=H9hRZKqwiQZg/bgpvy3xee07Qnc7RWNin/pg92D+s7Y=; h=Date:To:From:Subject:From:To:CC:Subject; b=eRcKiCJ/uRh+lKBIDwG2qnq5m6MGArsm3d+IO+1Unwvts06/4kHPHARKlL01bs8OX yBl2R47JivC+ZEERo+QNyXOYioiwWl+S7BPKKOIVUI08fF5SJ/fUhyuhzuao4yEq/E l7+zXCPTuA5Up9HOH9aehVpvG32GqZjT0eDOvZDSlb2raEcZJXu8t2wZnaTeWpLyAN UoAlf7DLwvr6mRkR9WI2fE5SnbFxelkOlLpZ1+aFI6G0MdqpU6QYn5QgciylFK71f8 z/ulI9CyiRE6oVIoN9/av+YTWe/RDzQ2TGs0PcE3gxF02V3cVNgt/YaCCO1pMuzEwg dvyPzcXy9u30w== X-Virus-Scanned: amavisd-new at boeck2.rrze.uni-erlangen.de (RRZE) X-RRZE-Flag: Not-Spam X-RRZE-Submit-IP: 10.21.55.43 Received: from [10.21.55.43] (faustud-010-021-055-043.pool.uni-erlangen.de [10.21.55.43]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: U2FsdGVkX19RcI2Iv6C791hkvZtYfADGebWG/6pPn9E=) by smtp-auth.uni-erlangen.de (Postfix) with ESMTPSA id 4V0Cgf3JZPz8sm5 for ; Wed, 20 Mar 2024 16:49:02 +0100 (CET) Message-ID: Date: Wed, 20 Mar 2024 16:49:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: gcc-help@gcc.gnu.org Content-Language: en-US From: Julian Zboril Subject: Missing __asan_stack_free in Custom KASAN Implementation Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hello, I am currently working on a Kernel Address Sanitizer implementation for my universities teaching operating system. My current goal is getting use-after-return detection to work (with a fake stack allocator). While gcc inserts the __asan_stack_malloc* calls seemingly fine, it does not add any __asan_stack_free* calls at all. It also does not detect my artificial example, which consists of returning a pointer to a (constant) integer on the stack. This causes an exception to be thrown, but no detection by the address sanitizer. It is possible that this is a direct consequence of my issue with __asan_stack_free*, as the allocator fills up quite quickly when the stack frames are not freed. These are the (ASan-related) flags I use for compilation: -fsanitize=kernel-address -DKASAN_OFFSET=$(KASAN_OFFSET) -DKASAN=1 --param asan-stack=1 --param asan-use-after-return=1 --param asan-instrumentation-with-call-threshold=0 -fsanitize-address-use-after-scope -fasan-shadow-offset=$(KASAN_OFFSET) The custom asan-runtime is built as an external static library archive. Any help or ideas would be greatly appreciated. Greetings, Julian