From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx07-00178001.pphosted.com (mx08-00178001.pphosted.com [91.207.212.93]) by sourceware.org (Postfix) with ESMTPS id 106E53858C2C for ; Sat, 22 Oct 2022 08:11:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 106E53858C2C Received: from pps.filterd (m0046661.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 29M24ntu008051; Sat, 22 Oct 2022 10:11:35 +0200 Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com (PPS) with ESMTPS id 3kc7djs440-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 22 Oct 2022 10:11:35 +0200 Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 737EF10002A; Sat, 22 Oct 2022 10:11:30 +0200 (CEST) Received: from Webmail-eu.st.com (shfdag1node3.st.com [10.75.129.71]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 5E018214D1B; Sat, 22 Oct 2022 10:11:30 +0200 (CEST) Received: from [10.252.19.128] (10.252.19.128) by SHFDAG1NODE3.st.com (10.75.129.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Sat, 22 Oct 2022 10:11:29 +0200 Message-ID: <48df83b6-054f-6d0b-c1e3-076eef904eb3@foss.st.com> Date: Sat, 22 Oct 2022 10:11:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.3.3 Subject: Re: [PATCH v2] gdb/arm: Fix M-profile EXC_RETURN exception_domain_is_secure logic Content-Language: en-US To: Tomas Vanek , References: <1666426048-22477-1-git-send-email-vanekt@fbl.cz> From: Torbjorn SVENSSON In-Reply-To: <1666426048-22477-1-git-send-email-vanekt@fbl.cz> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.252.19.128] X-ClientProxiedBy: EQNCAS1NODE3.st.com (10.75.129.80) To SHFDAG1NODE3.st.com (10.75.129.71) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-10-21_04,2022-10-21_01,2022-06-22_01 X-Spam-Status: No, score=-11.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, 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 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: , X-List-Received-Date: Sat, 22 Oct 2022 08:15:34 -0000 Hi Tomas, On 2022-10-22 10:07, Tomas Vanek wrote: > Arm v8-M Architecture Reference Manual, > D1.2.95 EXC_RETURN, Exception Return Payload > describes ES bit: > > "ES, bit [0] > Exception Secure. The security domain the exception was taken to. > The possible values of this bit are: > 0 Non-secure. > 1 Secure" > > arm-tdep.c:3443, arm_m_exception_cache () function tests this bit: > > exception_domain_is_secure = (bit (lr, 0) == 0); > > The test is negated! Good catch! I'm not sure how I thought when I wrote this, but thanks for correcting it. > > Later on line 3553, the condition evaluates if an additional state > context is stacked: > > /* With the Security extension, the hardware saves R4..R11 too. */ > if (tdep->have_sec_ext && secure_stack_used > && (!default_callee_register_stacking || exception_domain_is_secure)) > > RM, B3.19 Exception entry, context stacking > reads: > RPLHM "In a PE with the Security Extension, on taking an exception, > the PE hardware: > ... > 2. If exception entry requires a transition from Secure state to > Non-secure state, the PE hardware extends the stack frame and also > saves additional state context." > > So we should test for !exception_domain_is_secure instead of non-negated > value! > These two bugs compensate each other so unstacking works correctly. > > But another test of exception_domain_is_secure (negated due to the > first bug) prevents arm_unwind_secure_frames to work as expected: > > /* Unwinding from non-secure to secure can trip security > measures. In order to avoid the debugger being > intrusive, rely on the user to configure the requested > mode. */ > if (secure_stack_used && !exception_domain_is_secure > && !arm_unwind_secure_frames) > > Test with GNU gdb (GDB) 13.0.50.20221016-git. > Stopped in a non-secure handler: > > (gdb) set arm unwind-secure-frames 0 > (gdb) bt > #0 HAL_SYSTICK_Callback () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/NonSecure/Src/nsmain.c:490 > #1 0x0804081c in SysTick_Handler () > at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/NonSecure/Src/nsstm32l5xx_it.c:134 > #2 > #3 HAL_GPIO_ReadPin (GPIOx=0x52020800, GPIO_Pin=8192) > at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Drivers/STM32L5xx_HAL_Driver/Src/stm32l5xx_hal_gpio.c:386 > #4 0x0c000338 in SECURE_Mode () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/main.c:86 > #5 0x080403f2 in main () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/NonSecure/Src/nsmain.c:278 > Backtrace stopped: previous frame inner to this frame (corrupt stack?) > > The frames #3 and #4 are secure. backtrace should stop before #3. > > Stopped in a secure handler: > > (gdb) bt > #0 HAL_SYSTICK_Callback () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/main.c:425 > #1 0x0c000b6a in SysTick_Handler () > at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/stm32l5xx_it.c:234 > warning: Non-secure to secure stack unwinding disabled. > #2 > > The exception from secure to secure erroneously stops unwinding. It should > continue as far as the security unlimited backtrace: > > (gdb) set arm unwind-secure-frames 1 > (gdb) si <-- used to rebuild frame cache after change of unwind-secure-frames Is there any way to make gdb rebuild the frame cache directly when doing the "set arm unwind-secure-frames"? Feels dirty to do a instruction step just to get the right trace... Regardless of the answer to the above question, it's not something to address in this patch. > 0x0c0008e6 425 if (SecureTimingDelay != 0U) > (gdb) bt > #0 0x0c0008e6 in HAL_SYSTICK_Callback () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/main.c:425 > #1 0x0c000b6a in SysTick_Handler () > at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/stm32l5xx_it.c:234 > #2 > #3 0x0c000328 in SECURE_Mode () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/main.c:88 > #4 0x080403f2 in main () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/NonSecure/Src/nsmain.c:278 > > Backtrace stopped: previous frame inner to this frame (corrupt stack?) > > Set exception_domain_is_secure to the value expected by its name. > Fix exception_domain_is_secure usage in the additional state context > stacking condition. > > v2: Corrected backtrace logs in commit message > > Signed-off-by: Tomas Vanek > --- > gdb/arm-tdep.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c > index 55295e1..20b6f3f 100644 > --- a/gdb/arm-tdep.c > +++ b/gdb/arm-tdep.c > @@ -3496,7 +3496,7 @@ struct frame_unwind arm_stub_unwind = { > { > secure_stack_used = (bit (lr, 6) != 0); > default_callee_register_stacking = (bit (lr, 5) != 0); > - exception_domain_is_secure = (bit (lr, 0) == 0); > + exception_domain_is_secure = (bit (lr, 0) != 0); > > /* Unwinding from non-secure to secure can trip security > measures. In order to avoid the debugger being > @@ -3606,7 +3606,7 @@ struct frame_unwind arm_stub_unwind = { > > /* With the Security extension, the hardware saves R4..R11 too. */ > if (tdep->have_sec_ext && secure_stack_used > - && (!default_callee_register_stacking || exception_domain_is_secure)) > + && (!default_callee_register_stacking || !exception_domain_is_secure)) > { > /* Read R4..R11 from the integer callee registers. */ > cache->saved_regs[4].set_addr (unwound_sp + 0x08); Kind regards, Torbjörn