From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id E7CBD3857C48 for ; Thu, 1 Dec 2022 13:56:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E7CBD3857C48 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=foss.arm.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=foss.arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1A390D6E; Thu, 1 Dec 2022 05:56:13 -0800 (PST) Received: from [10.57.5.109] (unknown [10.57.5.109]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 925933F73D; Thu, 1 Dec 2022 05:56:05 -0800 (PST) Message-ID: <2a819813-159b-5987-d9d3-c907aa7a5728@foss.arm.com> Date: Thu, 1 Dec 2022 13:55:55 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [PATCH][Newlib] arm: Restrict processor mode change when in hypervisor mode. Content-Language: en-GB To: Srinath Parvathaneni , newlib@sourceware.org Cc: nd@arm.com, richard.earnshaw@arm.com References: From: Richard Earnshaw In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3495.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,NICE_REPLY_A,SPF_HELO_NONE,SPF_NONE,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 30/11/2022 16:49, Srinath Parvathaneni wrote: > Hi All, > > In _stack_init function of crt0.S file, when the current mode is not user mode, > all the processor modes are parsed and the corresponding stack limit are set for > these modes for all A-profile and R-profile CPU's. But when the current processor > mode is hypervisor mode, changing to any other mode using CPSR will result in an > illegal instruction as per Arm-arm and simulator throws undefined instruction > exception. So under what circumstances can a program be started while in HYP mode? I may have got the wrong end of the stick (sorry, virtualization isn't my forte), but isn't the whole point of HYP mode trapping these attempted mode changes meant to allow the supervising OS to fake up the relevant behaviours? > This patch prevent the change of hypervisor mode to any other mode in _stack_init > function in crt0.S files. > > Regression tested on arm-none-eabi target for newlib and newlib-nano and found > no regressions. > > Ok for newlib master? > > Regards, > Srinath. > > libgloss/ChangeLog: > > 2022-11-28 Srinath Parvathaneni > > * arm/crt0.S (_stack_init): Add check for hypervisor mode. > > newlib/ChangeLog: > > 2022-11-28 Srinath Parvathaneni > > * libc/sys/arm/crt0.S (_stack_init): Add check for hypervisor mode. > > > ############### Attachment also inlined for ease of reply ############### > > > diff --git a/libgloss/arm/crt0.S b/libgloss/arm/crt0.S > index 78515180bf06f1da37669e4c7e6608c76e1b096d..e3c0ca00fd5d25e8059be07a0fb62490350b4dcb 100644 > --- a/libgloss/arm/crt0.S > +++ b/libgloss/arm/crt0.S > @@ -148,13 +148,17 @@ > /* M profile doesn't have CPSR register. */ > #if (__ARM_ARCH_PROFILE != 'M') > /* Following code is compatible for both ARM and Thumb ISA. */ > - mrs r4, CPSR > - /* Test mode bits - in User of all are 0. */ > - tst r4, #(CPSR_M_MASK) > + mrs r4, CPSR You've (incorrectly) changed the hard tab after 'mrs' to spaces. Please fix this and all the other cases where you've done this. By convention we have one hard tab after the mnemonic before the first operand. > + mov r3, sp /* Save input SP value. */ > + /* Test mode bits - in User mode all are 0. */ > + ands r1, r4, #(CPSR_M_MASK) > /* "eq" means r4 AND #0x0F is 0. */ > beq .Lskip_cpu_modes > > - mov r3, sp /* Save input SP value. */ > + /* Test mode bits - in Hypervisor Mode value is 0X0A. */ > + cmp r1, #(CPSR_M_HYP) > + /* "eq" means hypervisor mode and change of mode is not acceptable. */ > + beq .Lskip_cpu_hyp_mode Why the new label rather than jumping to skip_cpu_modes? This doesn't feel right as I'd expect us to want to take exactly the same path as when we enter in user mode. > > /* FIQ mode, interrupts disabled. */ > mov r1, #(CPSR_M_FIQ|CPSR_M_32BIT|CPSR_I_MASK|CPSR_F_MASK) > @@ -236,6 +240,7 @@ > sub sl, r3, #64 << 10 > #endif > #endif > +.Lskip_cpu_hyp_mode: > > FN_RETURN > FN_EH_END > diff --git a/newlib/libc/sys/arm/crt0.S b/newlib/libc/sys/arm/crt0.S > index 6b01d8a88b77f44b1ba495aa1f69156f12749527..b974c36c92c8f092643f63d2056927a107a1e85b 100644 > --- a/newlib/libc/sys/arm/crt0.S > +++ b/newlib/libc/sys/arm/crt0.S > @@ -148,13 +148,17 @@ > /* M profile doesn't have CPSR register. */ > #if (__ARM_ARCH_PROFILE != 'M') > /* Following code is compatible for both ARM and Thumb ISA. */ > - mrs r4, CPSR > - /* Test mode bits - in User of all are 0. */ > - tst r4, #(CPSR_M_MASK) > + mrs r4, CPSR > + mov r3, sp /* Save input SP value. */ > + /* Test mode bits - in User mode all are 0. */ > + ands r1, r4, #(CPSR_M_MASK) > /* "eq" means r4 AND #0x0F is 0. */ > - beq .Lskip_cpu_modes > + beq .Lskip_cpu_modes > > - mov r3, sp /* Save input SP value. */ > + /* Test mode bits - in Hypervisor Mode value is 0X0A. */ > + cmp r1, #(CPSR_M_HYP) > + /* "eq" means hypervisor mode and change of mode is not acceptable. */ > + beq .Lskip_cpu_hyp_mode > > /* FIQ mode, interrupts disabled. */ > mov r1, #(CPSR_M_FIQ|CPSR_M_32BIT|CPSR_I_MASK|CPSR_F_MASK) > @@ -236,6 +240,7 @@ > sub sl, r3, #64 << 10 > #endif > #endif > +.Lskip_cpu_hyp_mode: > > FN_RETURN > FN_EH_END R.