On Tue, 01 Jun 2021 14:34:05 +0100,
Dongjiu Geng <gengdongjiu1(a)gmail.com> wrote:
>
> Marc Zyngier <maz(a)kernel.org> 于2021年6月1日周二 下午6:09写道：
> >
> > On Tue, 01 Jun 2021 10:53:49 +0100,
> > Dongjiu Geng <gengdongjiu1(a)gmail.com> wrote:
> > >
> > > Mark Rutland <mark.rutland(a)arm.com> 于2021年6月1日周二 下午5:19写道：
> > > >
> > > > On Fri, May 28, 2021 at 05:26:51PM +0800, Dongjiu Geng wrote:
> > > > > Hi All,
> > > > > when Linux kernel boot from EL1, there is no method to let
> > > > > kernel to enter EL2 to enable hypervisor. so I want to add an SMC
> > > > > interface between kernel and EL3 ATF to let kernel can set the
> > > > > hypervisor vector table, then can enter EL2 to enable hypervisor, as
> > > > > shown in [1].
> > > > > Do you agree? Otherwise there is no method to enter EL2 hypervisor
> > > > > when kernel boot from EL1, because the hypervisor vector
> > > > > table(vbar_el2) is unknown.
> > > >
> > > > The kernel already supported being booted at EL2, where it will install
> > > > itself as the hypervisor (and will drop to EL1 if required). EL2 is the
> > > > preferred boot mode, as we document in:
> > > >
> > > > https://www.kernel.org/doc/html/latest/arm64/booting.html
> > > >
> > > > ... where we say:
> > > >
> > > > | The CPU must be in either EL2 (RECOMMENDED in order to have access to
> > > > | the virtualisation extensions) or non-secure EL1.
> > > >
> > > > We *strongly* prefer this over adding new ABIs to transition from EL1 to
> > > > EL2. Please boot the kernel at EL2 if you want to use KVM.
> > >
> > > Thanks for the answer.
> > > If use KVM, it should boot from EL2. But if the hypervisor is not
> > > KVM, such as Jailhouse hypervisor and some Chip manufacturer boot the
> > > host kernel from EL1(not follow above rule), it seems there is not way
> > > to enter the Jailhouse hypervisor.
> >
> > We only deal with two cases:
> > - either the kernel uses its own, built-in hypervisor: it boots at
> > EL2, and installs itself.
> >
> > - or there is a pre-existing hypervisor, and the kernel boots at EL1.
> >
> > In the past, Jailhouse used the exact same entry points as KVM. What
> > has changed?
>
> Jailhouse use the __hyp_stub_vectors vector table[1] in linux
> kernel arch/arm64/kernel/hyp-stub.S to re-set his own's hypervisor
> vector table, but if linux kernel is boot from EL1，it can not use the
> entry points(__hyp_stub_vectors). I agree Linux kernel is recommended
> boot from EL2, but some custer's boards not follow this rule.
So Jailhouse doesn't have this problem when used as intended.
>
> [1]:
> ENTRY(__hyp_stub_vectors)
> ventry el2_sync_invalid // Synchronous EL2t
> ventry el2_irq_invalid // IRQ EL2t
> ventry el2_fiq_invalid // FIQ EL2t
> ventry el2_error_invalid // Error EL2t
>
> ventry el2_sync_invalid // Synchronous EL2h
> ventry el2_irq_invalid // IRQ EL2h
> ventry el2_fiq_invalid // FIQ EL2h
> ventry el2_error_invalid // Error EL2h
>
> ventry el1_sync // Synchronous 64-bit EL1
> ventry el1_irq_invalid // IRQ 64-bit EL1
> ventry el1_fiq_invalid // FIQ 64-bit EL1
> ventry el1_error_invalid // Error 64-bit EL1
>
> ventry el1_sync_invalid // Synchronous 32-bit EL1
> ventry el1_irq_invalid // IRQ 32-bit EL1
> ventry el1_fiq_invalid // FIQ 32-bit EL1
> ventry el1_error_invalid // Error 32-bit EL1
> ENDPROC(__hyp_stub_vectors)
>
> >
> > Finally, if you can change the firmware to install the EL2 vectors,
> > you can also change it to enter the kernel at EL2. I suggest you do
> > that instead.
>
> I agree with you, but needs to change customer‘s board, I will try to
> discuess with customer.
In both cases, you'll need to change your customer's firmware.
It seems to me that there is no reason for the arm64 boot protocol to
change and adopt weird, wonderful and proprietary privilege escalation
methods.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
On Tue, 01 Jun 2021 10:53:49 +0100,
Dongjiu Geng <gengdongjiu1(a)gmail.com> wrote:
>
> Mark Rutland <mark.rutland(a)arm.com> 于2021年6月1日周二 下午5:19写道：
> >
> > On Fri, May 28, 2021 at 05:26:51PM +0800, Dongjiu Geng wrote:
> > > Hi All,
> > > when Linux kernel boot from EL1, there is no method to let
> > > kernel to enter EL2 to enable hypervisor. so I want to add an SMC
> > > interface between kernel and EL3 ATF to let kernel can set the
> > > hypervisor vector table, then can enter EL2 to enable hypervisor, as
> > > shown in [1].
> > > Do you agree? Otherwise there is no method to enter EL2 hypervisor
> > > when kernel boot from EL1, because the hypervisor vector
> > > table(vbar_el2) is unknown.
> >
> > The kernel already supported being booted at EL2, where it will install
> > itself as the hypervisor (and will drop to EL1 if required). EL2 is the
> > preferred boot mode, as we document in:
> >
> > https://www.kernel.org/doc/html/latest/arm64/booting.html
> >
> > ... where we say:
> >
> > | The CPU must be in either EL2 (RECOMMENDED in order to have access to
> > | the virtualisation extensions) or non-secure EL1.
> >
> > We *strongly* prefer this over adding new ABIs to transition from EL1 to
> > EL2. Please boot the kernel at EL2 if you want to use KVM.
>
> Thanks for the answer.
> If use KVM, it should boot from EL2. But if the hypervisor is not
> KVM, such as Jailhouse hypervisor and some Chip manufacturer boot the
> host kernel from EL1(not follow above rule), it seems there is not way
> to enter the Jailhouse hypervisor.
We only deal with two cases:
- either the kernel uses its own, built-in hypervisor: it boots at
EL2, and installs itself.
- or there is a pre-existing hypervisor, and the kernel boots at EL1.
In the past, Jailhouse used the exact same entry points as KVM. What
has changed?
Finally, if you can change the firmware to install the EL2 vectors,
you can also change it to enter the kernel at EL2. I suggest you do
that instead.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
On Fri, May 28, 2021 at 05:26:51PM +0800, Dongjiu Geng wrote:
> Hi All,
> when Linux kernel boot from EL1, there is no method to let
> kernel to enter EL2 to enable hypervisor. so I want to add an SMC
> interface between kernel and EL3 ATF to let kernel can set the
> hypervisor vector table, then can enter EL2 to enable hypervisor, as
> shown in [1].
> Do you agree? Otherwise there is no method to enter EL2 hypervisor
> when kernel boot from EL1, because the hypervisor vector
> table(vbar_el2) is unknown.
The kernel already supported being booted at EL2, where it will install
itself as the hypervisor (and will drop to EL1 if required). EL2 is the
preferred boot mode, as we document in:
https://www.kernel.org/doc/html/latest/arm64/booting.html
... where we say:
| The CPU must be in either EL2 (RECOMMENDED in order to have access to
| the virtualisation extensions) or non-secure EL1.
We *strongly* prefer this over adding new ABIs to transition from EL1 to
EL2. Please boot the kernel at EL2 if you want to use KVM.
Thanks,
Mark.
>
>
>
> [1]:
> el1_sync:
> cmp x0, #SMC_SET_VECTORS
> b.ne 2f
> msr vbar_el2, x1
> b 9f
>
> 2: cmp x0, #SMC_SOFT_RESTART
> b.ne 3f
> mov x0, x2
> mov x2, x4
> mov x4, x1
> mov x1, x3
> br x4 // no return
>
> 3: cmp x0, #SMC_RESET_VECTORS
> beq 9f // Nothing to reset!
>
> ldr x0, =SMC_STUB_ERR
> eret
>
> 9: mov x0, xzr
> eret
> ENDPROC(el1_sync)
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel(a)lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi All,
We are using the snprintf() (which uses vsnprintf() and unsigned_num_print()) from libc of ATF version 2.4and running into an issue for printing a number into a string where even if I provide large enough string to hold the number, it does not print it. I don't see that issue with it when I try to print a string using the same snprintf().I understand that, as per the documentation use of snprintf is "banned or discouraged". But for the use case,that we are using for, it is safe enough to use it assuming that it does it what it is supposed to do.
I am not sure if this is a known bug or what, but upon a further inspection, I found that there seems be a small bugin the unsigned_num_print() for one of the 'if' condition given below which is causing the issue in terms of calculatingthe available space in the string.
if (*chars_printed < n) {
.... do the prinring....}
I believe it is supposed to be
if (*chars_printed <= n) { ----------------->> Notice '<=' instead of '<' }
Any comment on whether this is on purpose or really a small bug?
The calling routine (vsnprintf) is already reducing 'n' by 1 for the terminating null character.
Thank you very much for your support.-hiren
On 4/19/21 11:11 AM, Jan Kiszka via TF-A wrote:
> On 19.04.21 17:21, Michal Simek wrote:
>> On 4/18/21 8:44 PM, Jan Kiszka wrote:
>>> when SPD or DEBUG is enabled, TF-A is moved to RAM on the zynqmp (as it
>>> longer fits into OCM). U-Boot happens to avoid that region, but the
>>> kernel's DTB has no reservation entry, and Linux will trigger an
>>> exception when accessing that region during early boot.
>>>
>>> Can we improve this - without requiring the user to manually add a
>>> reservation to the DTB? Should we unconditionally reserve
>>> 0x1000..0x7ffff in all BL33 DTBs? Or is there a chance to communicate
>>> that need? Or some way to detect in BL33 whether it is needed?
>>
>> Normally this ddr region should be also protected by security IPs that
>> NS has no access there.
>> It means in Xilinx flow this can be (and should be) propagated via
>> device-tree generator to final DTS file that you don't need to touch it
>> by hand.
>> I am not aware about any way that NS can query secure world what memory
>> can be used. And not sure if there is any standard way to do so.
>>
>
> OK, understood. But then, to be safe, shouldn't the upstream "static"
> default DT contain an exclusion of that region so that it won't get
> stuck if it is in use? Would block half a meg, but when you have a
> custom platform that does not need that, you can and will provide your
> own DT anyway.
Ideally, the static DTS is a description of the hardware only, and not
of runtime constraints imposed by the firmware. If BL31 needs to reserve
some memory, it can add that reservation to the DTB at runtime. The
fdt_add_reserved_memory() function is available for this purpose. For an
example, see the code used by the rpi4[0] or sun50i_h616[1] platforms.
If you later load a DTB from disk for use by Linux, you will need to
copy the reserved-memory nodes from the U-Boot DTB to the loaded DTB.
Regards,
Samuel
[0]:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/rpi/r…
[1]:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/allwi…
Hi,
The last time I checked injecting an SError from a higher to lower EL is a bad idea since the latter could be running with SErrors masked.
EL3 could check this before injecting but then there is no consistent contract with the lower EL about reporting of these errors. SDEI does not suffer from the same problem.
+James who knows more from the OS/Hypervisor perspective.
cheers,
Achin
________________________________
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Soby Mathew via TF-A <tf-a(a)lists.trustedfirmware.org>
Sent: 25 May 2021 09:59
To: Pali Rohár <pali(a)kernel.org>
Cc: kabel(a)kernel.org <kabel(a)kernel.org>; tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>
Subject: Re: [TF-A] Rethrow SError from EL3 to kernel on arm64
[+tf-a list]
Hi Pali,
There are 2 philosophies for handing SError in the system, kernel first and firmware first. Assuming you want to stick with firmware first handling (i.e scr_el3.ea is set to 1), then as you mentioned, there are 2 ways to notify the kernel for delegating the error handling: SDEI and SError injection back to kernel. Upstream TF-A only supports SDEI at the moment.
For SError injection back to lower EL, you have to setup the hardware state via software at higher EL in such a way that it appears that the fault was taken to the exception vector at the lower exception level. The pseudocode function AArch64.TakeException() in ARM ARM shows the behavior when the PE takes an exception to an Exception level using AArch64 in Non-debug state. This behaviour has to replicated and it involves the higher EL setting up the PSTATE registers correctly and values in other registers for the lower EL (spsr, elr and fault syndrome registers) and jumping to the right offset point to by the vbar_elx of the lower EL. To the lower EL is appears as a SError has triggered at its exception vector and it can proceed with the fault handling.
Best Regards
Soby Mathew
> -----Original Message-----
> From: Pali Rohár <pali(a)kernel.org>
> Sent: Monday, May 24, 2021 6:07 PM
> To: Soby Mathew <Soby.Mathew(a)arm.com>
> Subject: Rethrow SError from EL3 to kernel on arm64
>
> Hello Soby!
>
> I have found following discussion in Armada 3720 PCIe SError issue:
> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-
> a/+/1541/comment/ca882427_d142bde2/
>
> TF-A on Armada 3720 redirects all SErrors to EL3 and panic in TF-A handler.
> You wrote in that discussion:
>
> Ideally you need to signal the SError back to kernel from EL3 using
> SDEI or inject the SError to the lower EL and the kernel can decide to
> die or not.
>
> And I would like to ask you, could you help me with implementation of this
> SError rethrow functionality? Because I have absolutely no idea how to do it
> and catching all SErrors in EL3 is causing issues because some of them can be
> handled and recovered by kernel.
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
[+tf-a list]
Hi Pali,
There are 2 philosophies for handing SError in the system, kernel first and firmware first. Assuming you want to stick with firmware first handling (i.e scr_el3.ea is set to 1), then as you mentioned, there are 2 ways to notify the kernel for delegating the error handling: SDEI and SError injection back to kernel. Upstream TF-A only supports SDEI at the moment.
For SError injection back to lower EL, you have to setup the hardware state via software at higher EL in such a way that it appears that the fault was taken to the exception vector at the lower exception level. The pseudocode function AArch64.TakeException() in ARM ARM shows the behavior when the PE takes an exception to an Exception level using AArch64 in Non-debug state. This behaviour has to replicated and it involves the higher EL setting up the PSTATE registers correctly and values in other registers for the lower EL (spsr, elr and fault syndrome registers) and jumping to the right offset point to by the vbar_elx of the lower EL. To the lower EL is appears as a SError has triggered at its exception vector and it can proceed with the fault handling.
Best Regards
Soby Mathew
> -----Original Message-----
> From: Pali Rohár <pali(a)kernel.org>
> Sent: Monday, May 24, 2021 6:07 PM
> To: Soby Mathew <Soby.Mathew(a)arm.com>
> Subject: Rethrow SError from EL3 to kernel on arm64
>
> Hello Soby!
>
> I have found following discussion in Armada 3720 PCIe SError issue:
> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-
> a/+/1541/comment/ca882427_d142bde2/
>
> TF-A on Armada 3720 redirects all SErrors to EL3 and panic in TF-A handler.
> You wrote in that discussion:
>
> Ideally you need to signal the SError back to kernel from EL3 using
> SDEI or inject the SError to the lower EL and the kernel can decide to
> die or not.
>
> And I would like to ask you, could you help me with implementation of this
> SError rethrow functionality? Because I have absolutely no idea how to do it
> and catching all SErrors in EL3 is causing issues because some of them can be
> handled and recovered by kernel.
Thanks, Gary, and to everybody who contributed to this release!
I’d like to quickly remind everybody that, as part of the v2.5 release, the Trusted Firmware-A project formally adopted the Conventional Commits v1.0.0<https://www.conventionalcommits.org/en/v1.0.0/> specification to enable us to radically reduce our time-to-release in the future. Thank you to everybody who took part in the discussions that allowed us to integrate this, and to those whose concerns I hope we have by now satisfied.
As part of this effort, we have introduced a commit verification check to the existing Gerrit-triggered CI job. Where before this applied only to Arm employees, this now includes everybody (even you, reader of this email). This will no doubt require some initial mental reorientation as it did for our Arm-based guinea pigs, but I hope that this it will become a non-issue in short time.
To aid in the transition, we are also now packaging additional tooling, namely Commitizen<https://commitizen-tools.github.io/commitizen/> and commitlint<https://commitlint.js.org/#/>, to make writing conformant commits easier, the installation instructions for which have been integrated into the v2.5 prerequisites page<https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/prerequi…>. These tools are optional, but highly recommended if you do find your commits being rejected by the CI.
Please note that patches currently awaiting review on Gerrit will need to adhere to this specification before merging (this should only take a minute).
If you missed previous communications or are unfamiliar with Conventional Commits, here is a brief summary of the format that commit messages are now expected to take:
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
Where the <type> is one of:
* feat: A new feature
* fix: A bug fix
* docs: Documentation only changes
* style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
* refactor: A code change that neither fixes a bug nor adds a feature
* perf: A code change that improves performance
* test: Adding missing tests or correcting existing tests
* build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
* ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
* chore: Other changes that don't modify src or test files
* revert: Reverts a previous commit
And the [optional scope] consists of an optional parentheses-wrapped scope of your choosing, similarly to how many contributors prefixed their commits previously.
A real-world example:
docs(prerequisites): add `--no-save` to `npm install`
To avoid the mistake fixed by the previous commit, ensure users install
the Node.js dependencies without polluting the lock file by passing
`--no-save` to the `npm install` line.
Change-Id: I10b5cc17b9001fc2e26deee02bf99ce033a949c1
Signed-off-by: Chris Kay <chris.kay(a)arm.com>
If you have the time, please do read up on the specification for additional details – I promise it’s short.
So long, and happy committing. 😊
Regards,
Chris
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Gary Morrison via TF-A <tf-a(a)lists.trustedfirmware.org>
Date: Thursday, 20 May 2021 at 15:59
To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>
Subject: [TF-A] Trusted Firmware version 2.5 is now available
Trusted Firmware version 2.5 is now available and can be found here:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tag/?h=v2.5https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tag/?h=v2.5https://git.trustedfirmware.org/hafnium/hafnium.git/tag/?h=v2.5https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/tag/?h=v2.5
Please refer to the read-the-docs and change log for further information.
Regards,
Gary Morrison -- Arm
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
