Hi,
I tend to agree with Soby here. If the normal world and EL3 share the console, EL3 error messages/debug prints exposed to the normal world could be another potential attack vector. From a functionality perspective, will there not be contention issues on multi-core platforms and hence garbled output? I understand that using two separate UARTS may not be possible for many platforms, in which case a single UART can be shared during cold boot between EL3 and the normal world, while EL3 runtime messages can be logged to a secure memory buffer. Once boot exists EL3, UART ownership can be transferred to the normal world.
Thanks, Mayur
On Wed, Jun 23, 2021 at 5:00 AM Soby Mathew via TF-A < tf-a@lists.trustedfirmware.org> wrote:
Hi Michal, Sure, platform can choose to share but I was bringing up the potential attack vector of Non Secure being able to hang up EL3 if EL3 has runtime prints and the Non secure is able to disable or control the UART used by EL3. Typically , runtime logs are disabled on production builds so this might not be a problem anyway.
Regarding crash console, the plat_crash_console_init() can initialize a stack (either the EL3 runtime stack or a dedicated crash stack) and use C runtime to control clocks for crash logs. So the current assembly implementation should not be a gating factor for doing clock control if required.
Best Regards Soby Mathew
-----Original Message----- From: Michal Simek michal.simek@xilinx.com Sent: Wednesday, June 23, 2021 9:16 AM To: Varun Wadekar vwadekar@nvidia.com; Soby Mathew Soby.Mathew@arm.com; Michal Simek michal.simek@xilinx.com Cc: tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] PL011 clock handling between TF-A and Linux
Hi,
I agree with Varun. TF-A can use DCC console but it is not practical. Using second console is definitely an option but not all platforms and
also
monitoring two consoles is problematic.
Also OP-TEE is touching this primary console. Platform which are using
DT are
looking for chosen node (as backup) and read information about OS console from it.
Thanks, Michal
On 6/22/21 8:47 PM, Varun Wadekar wrote:
Hi Soby,
Even though in principle I agree with you, it is not practical to add
secure
only UART port to a platform. It is shared for multiple reasons - e.g.
lower
board cost. That is the case on all Tegra Jetson platforms.
This means that the secure world never owns the console - not even
during
cold boot. The crash console code is in assembly today. This makes implementing code to communicate to an external clock manager is not straight forward and platforms might choose to keep the code to toggle clock/reset out of TF-A.
-Varun
-----Original Message----- From: Soby Mathew Soby.Mathew@arm.com Sent: Tuesday, June 22, 2021 4:30 PM To: Michal Simek michal.simek@xilinx.com; Varun Wadekar vwadekar@nvidia.com Cc: tf-a@lists.trustedfirmware.org Subject: RE: [TF-A] PL011 clock handling between TF-A and Linux
External email: Use caution opening links or attachments
Hi Michal, The general security rule of thumb is, any UART `owned` by Secure
world (
including EL3) should not be accessible/or controlled by Non Secure and
this
includes control of the clocks as well. Hence sharing of UART /
management
of Secure world UART clocks by Linux seems problematic to me.
There are 3 types of consoles needed in TF-A. The first one is the
cold boot
console, the second one is runtime console and the 3rd is crash console.
The
cold boot console is initially owned by Secure world as part boot
process and
once execution is transferred to Non Secure, the ownership of the UART
also
is transferred.
Regarding clock expectations, the runtime UART is always expected to be
ON but then this depends on the TF-A build config as it is very rare to
have any
runtime logs from Secure world and hence this config may be restricted to development builds of TF-A. For the crash console, the clocks don't need
to
enabled all the time and any init needed can be performed as part of plat_crash_console_init().
HTH, Best Regards Soby Mathew
-----Original Message----- From: TF-A tf-a-bounces@lists.trustedfirmware.org On Behalf Of Michal Simek via TF-A Sent: Tuesday, June 22, 2021 2:03 PM To: Varun Wadekar vwadekar@nvidia.com; Michal Simek michal.simek@xilinx.com Cc: tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] PL011 clock handling between TF-A and Linux
Hi Varun,
do you have any links to that calls in Linux clk API? I expect the same hooks should be added also to reset.
And is TF-A informs your special firmware that for example serial driver is used by TF-A to increate refcount?
Thanks, Michal
On 6/22/21 2:03 PM, Varun Wadekar wrote:
Hi Michal,
Tegra platforms manage clocks/resets by special firmware. The firmware
internally manages refcount of users as you described.
AFAIR, we placed calls to the firmware in the linux clk APIs to
achieve this.
There was an effort to leverage runtime_pm for this too.
I think we wont be able to add guidance to TF-A for clock management as
most of it is platform dependent. We can add a generic guideline saying that a certain driver expects the platform to manage the
clock/reset
for the IP.
-Varun
-----Original Message----- From: Michal Simek michal.simek@xilinx.com Sent: Tuesday, June 22, 2021 7:24 AM To: Varun Wadekar vwadekar@nvidia.com; Michal Simek michal.simek@xilinx.com Cc: tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] PL011 clock handling between TF-A and Linux
External email: Use caution opening links or attachments
Hi Varun,
Xilinx is also managing it by special firmware. There is a concept of
protected-clocks documented via DT binding which is used by Qualcomm.
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/ tr ee/Documentation/devicetree/bindings/clock/clock-bindings.txt?h=next -2 0210621#n172
Are you also using this feature or simply don't let Linux know about these
clocks at all or simulate it via fixed-clock or so?
Or any registration is in place that firmware keep refcount of users and
don't let it change unless there is only one user of that clock?
Thanks, Michal
On 6/21/21 6:41 PM, Varun Wadekar wrote:
Hi Michal,
AFAIK, TF-A does not publish guidelines for clocks/resets for shared IP. It
is left to the platforms.
For Tegra platforms, the clocks/reset are managed by a central entity. TF-
A is expected to co-ordinate with this entity. Unfortunately, PL011 does not fall in this category and is expected to be kept on by the
previous
bootloader.
-Varun
-----Original Message----- From: TF-A tf-a-bounces@lists.trustedfirmware.org On Behalf Of Michal Simek via TF-A Sent: Monday, June 21, 2021 2:24 PM To: tf-a@lists.trustedfirmware.org Subject: [TF-A] PL011 clock handling between TF-A and Linux
External email: Use caution opening links or attachments
Hi,
recently we have hit the case where Linux has pl011 driver and using it as
a console. The same console is also used by TF-A. If you look at implementation details Linux pl011 driver has in pl011_console_write() clk_enable/clk_disable calls.
I can't see any clock handling for PL011 in TF-A that's why I guess that TF-A
expectation is that clocks are enabled and must be enabled all the time because pl011 is also used as crashed console.
That's why I would like to check with you what's the clock expectation in
these shared IP cases.
Do you have a requirement that firmware should keep refcount of IP
users and never disable clock when only one requires it?
Thanks, Michal -- TF-A mailing list TF-A@lists.trustedfirmware.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
t s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-
a&data=04%7C01%7C
vwadekar%40nvidia.com%7C9d5af04d3aba49b18cc808d935465267%7C4308 3
d1572
7340c1b7db39efd9ccc17a%7C0%7C0%7C637599398425726681%7CUnknow n%
7CTWFpb
GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
6Mn
0%3D%7C1000&sdata=%2BXFRPZTttom4rvT%2FmEcQnbgSa276PYuKbvo
H4VujRk8
%3D&reserved=0
-- TF-A mailing list TF-A@lists.trustedfirmware.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis t s.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-
a&data=04%7C01%7C
v
wadekar%40nvidia.com%7C957021cd030643da94bc08d935928f6b%7C4308 3d15727
3
40c1b7db39efd9ccc17a%7C0%7C0%7C637599725858916982%7CUnknown% 7CTWFpbGZ
s
b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn 0%3
D
%7C2000&sdata=S0D%2FZ5rk6Wr3xyIdCmol0eigIo%2FlGn%2B2WJODig %2FeDqU
% 3D&reserved=0
-- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a