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
Hi,
let's say that messages will be stored to secure memory buffer. I expect there is going to be a need to access these messages. Is there any driver/protocol in place which can be used for it? Or even reading of this buffer can be consider as potential security hole.
Or any concept of one way virtual console which could be access from NS?
Thanks, Michal
On 6/23/21 3:18 PM, Mayur wrote:
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 mailto: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 <mailto:michal.simek@xilinx.com>> > Sent: Wednesday, June 23, 2021 9:16 AM > To: Varun Wadekar <vwadekar@nvidia.com <mailto:vwadekar@nvidia.com>>; Soby Mathew > <Soby.Mathew@arm.com <mailto:Soby.Mathew@arm.com>>; Michal Simek <michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>> > Cc: tf-a@lists.trustedfirmware.org <mailto: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 <mailto:Soby.Mathew@arm.com>> > > Sent: Tuesday, June 22, 2021 4:30 PM > > To: Michal Simek <michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>>; Varun Wadekar > > <vwadekar@nvidia.com <mailto:vwadekar@nvidia.com>> > > Cc: tf-a@lists.trustedfirmware.org <mailto: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 <mailto: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 <mailto:vwadekar@nvidia.com>>; Michal Simek > >> <michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>> > >> Cc: tf-a@lists.trustedfirmware.org <mailto: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 <mailto:michal.simek@xilinx.com>> > >>> Sent: Tuesday, June 22, 2021 7:24 AM > >>> To: Varun Wadekar <vwadekar@nvidia.com <mailto:vwadekar@nvidia.com>>; Michal Simek > >>> <michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>> > >>> Cc: tf-a@lists.trustedfirmware.org <mailto: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/ <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 <mailto: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 <mailto: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 <mailto:TF-A@lists.trustedfirmware.org> > >>>> > >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis> > >>>> t > >>>> s.trustedfirmware.org <http://s.trustedfirmware.org>%2Fmailman%2Flistinfo%2Ftf- > >> a&data=04%7C01%7C > >>>> > >> > vwadekar%40nvidia.com <http://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 <mailto:TF-A@lists.trustedfirmware.org> > >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis> > >> t > >> s.trustedfirmware.org <http://s.trustedfirmware.org>%2Fmailman%2Flistinfo%2Ftf- > a&data=04%7C01%7C > >> v > >> > wadekar%40nvidia.com <http://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 <mailto:TF-A@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a>
Hi,
+1 to Michal's comments.
Now we are talking about providing a UART port for every controller in the system. Although this would be a great scenario, it is not practical and not preferred/implemented by all platforms.
Tegra platforms implement a manager for the UART port, that also acts as the arbiter. All clients push their UART logs to the manager which makes sure that logs are not garbled.
-Varun
-----Original Message----- From: Michal Simek michal.simek@xilinx.com Sent: Wednesday, June 23, 2021 2:27 PM To: Mayur mayurvg@gmail.com; Soby Mathew Soby.Mathew@arm.com Cc: Michal Simek michal.simek@xilinx.com; Varun Wadekar vwadekar@nvidia.com; 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,
let's say that messages will be stored to secure memory buffer. I expect there is going to be a need to access these messages. Is there any driver/protocol in place which can be used for it? Or even reading of this buffer can be consider as potential security hole.
Or any concept of one way virtual console which could be access from NS?
Thanks, Michal
On 6/23/21 3:18 PM, Mayur wrote:
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 mailto: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 <mailto:michal.simek@xilinx.com>> > Sent: Wednesday, June 23, 2021 9:16 AM > To: Varun Wadekar <vwadekar@nvidia.com <mailto:vwadekar@nvidia.com>>; Soby Mathew > <Soby.Mathew@arm.com <mailto:Soby.Mathew@arm.com>>; Michal Simek <michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>> > Cc: tf-a@lists.trustedfirmware.org <mailto: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 <mailto:Soby.Mathew@arm.com>> > > Sent: Tuesday, June 22, 2021 4:30 PM > > To: Michal Simek <michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>>; Varun Wadekar > > <vwadekar@nvidia.com <mailto:vwadekar@nvidia.com>> > > Cc: tf-a@lists.trustedfirmware.org <mailto: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 <mailto: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 <mailto:vwadekar@nvidia.com>>; Michal Simek > >> <michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>> > >> Cc: tf-a@lists.trustedfirmware.org <mailto: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 <mailto:michal.simek@xilinx.com>> > >>> Sent: Tuesday, June 22, 2021 7:24 AM > >>> To: Varun Wadekar <vwadekar@nvidia.com <mailto:vwadekar@nvidia.com>>; Michal Simek > >>> <michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>> > >>> Cc: tf-a@lists.trustedfirmware.org <mailto: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/ <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 <mailto: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 <mailto: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 <mailto:TF-A@lists.trustedfirmware.org> > >>>> > >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis> > >>>> t > >>>> s.trustedfirmware.org <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fs.trustedfirmware.org%2F&data=04%7C01%7Cvwadekar%40nvidia.com%7C608ad69f28c14c62691008d9364a94ef%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637600516235208146%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=f%2B2wqQnnFDBSfu0UE9dYRNKHzsamKskQFYMvj05SC%2Bk%3D&reserved=0>%2Fmailman%2Flistinfo%2Ftf- > >> a&data=04%7C01%7C > >>>> > >> > vwadekar%40nvidia.com <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40nvidia.com%2F&data=04%7C01%7Cvwadekar%40nvidia.com%7C608ad69f28c14c62691008d9364a94ef%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637600516235208146%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4aiNFrFW03%2Fv6mZShMO%2F2VBGqgng4VoPE7Lm7%2FWiD58%3D&reserved=0>%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 <mailto:TF-A@lists.trustedfirmware.org> > >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis> > >> t > >> s.trustedfirmware.org <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fs.trustedfirmware.org%2F&data=04%7C01%7Cvwadekar%40nvidia.com%7C608ad69f28c14c62691008d9364a94ef%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637600516235208146%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=f%2B2wqQnnFDBSfu0UE9dYRNKHzsamKskQFYMvj05SC%2Bk%3D&reserved=0>%2Fmailman%2Flistinfo%2Ftf- > a&data=04%7C01%7C > >> v > >> > wadekar%40nvidia.com <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40nvidia.com%2F&data=04%7C01%7Cvwadekar%40nvidia.com%7C608ad69f28c14c62691008d9364a94ef%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637600516235208146%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4aiNFrFW03%2Fv6mZShMO%2F2VBGqgng4VoPE7Lm7%2FWiD58%3D&reserved=0>%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 <mailto:TF-A@lists.trustedfirmware.org> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-a&data=04%7C01%7Cvwadekar%40nvidia.com%7C608ad69f28c14c62691008d9364a94ef%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637600516235208146%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=y64P9mgLL%2FKacvds9CJE87DQ8ZvcuAXT6bkfudQcPr0%3D&reserved=0
Hi Varun,
where is that manager implemented? In TFA or in your private firmware? Is there specific channel for communication or you use smc based protocol from NS to Secure, any virtio? Doing this in a standard way across vendors would be the best solution.
Thanks, Michal
On 6/23/21 8:37 PM, Varun Wadekar wrote:
Hi,
+1 to Michal's comments.
Now we are talking about providing a UART port for every controller in the system. Although this would be a great scenario, it is not practical and not preferred/implemented by all platforms.
Tegra platforms implement a manager for the UART port, that also acts as the arbiter. All clients push their UART logs to the manager which makes sure that logs are not garbled.
-Varun
-----Original Message----- From: Michal Simek michal.simek@xilinx.com Sent: Wednesday, June 23, 2021 2:27 PM To: Mayur mayurvg@gmail.com; Soby Mathew Soby.Mathew@arm.com Cc: Michal Simek michal.simek@xilinx.com; Varun Wadekar vwadekar@nvidia.com; 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,
let's say that messages will be stored to secure memory buffer. I expect there is going to be a need to access these messages. Is there any driver/protocol in place which can be used for it? Or even reading of this buffer can be consider as potential security hole.
Or any concept of one way virtual console which could be access from NS?
Thanks, Michal
On 6/23/21 3:18 PM, Mayur wrote:
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 mailto: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 <mailto:michal.simek@xilinx.com>> > Sent: Wednesday, June 23, 2021 9:16 AM > To: Varun Wadekar <vwadekar@nvidia.com <mailto:vwadekar@nvidia.com>>; Soby Mathew > <Soby.Mathew@arm.com <mailto:Soby.Mathew@arm.com>>; Michal Simek <michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>> > Cc: tf-a@lists.trustedfirmware.org <mailto: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 <mailto:Soby.Mathew@arm.com>> > > Sent: Tuesday, June 22, 2021 4:30 PM > > To: Michal Simek <michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>>; Varun Wadekar > > <vwadekar@nvidia.com <mailto:vwadekar@nvidia.com>> > > Cc: tf-a@lists.trustedfirmware.org <mailto: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 <mailto: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 <mailto:vwadekar@nvidia.com>>; Michal Simek > >> <michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>> > >> Cc: tf-a@lists.trustedfirmware.org <mailto: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 <mailto:michal.simek@xilinx.com>> > >>> Sent: Tuesday, June 22, 2021 7:24 AM > >>> To: Varun Wadekar <vwadekar@nvidia.com <mailto:vwadekar@nvidia.com>>; Michal Simek > >>> <michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>> > >>> Cc: tf-a@lists.trustedfirmware.org <mailto: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/ <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 <mailto: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 <mailto: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 <mailto:TF-A@lists.trustedfirmware.org> > >>>> > >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis> > >>>> t > >>>> s.trustedfirmware.org <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fs.trustedfirmware.org%2F&data=04%7C01%7Cvwadekar%40nvidia.com%7C608ad69f28c14c62691008d9364a94ef%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637600516235208146%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=f%2B2wqQnnFDBSfu0UE9dYRNKHzsamKskQFYMvj05SC%2Bk%3D&reserved=0>%2Fmailman%2Flistinfo%2Ftf- > >> a&data=04%7C01%7C > >>>> > >> > vwadekar%40nvidia.com <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40nvidia.com%2F&data=04%7C01%7Cvwadekar%40nvidia.com%7C608ad69f28c14c62691008d9364a94ef%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637600516235208146%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4aiNFrFW03%2Fv6mZShMO%2F2VBGqgng4VoPE7Lm7%2FWiD58%3D&reserved=0>%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 <mailto:TF-A@lists.trustedfirmware.org> > >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis> > >> t > >> s.trustedfirmware.org <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fs.trustedfirmware.org%2F&data=04%7C01%7Cvwadekar%40nvidia.com%7C608ad69f28c14c62691008d9364a94ef%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637600516235208146%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=f%2B2wqQnnFDBSfu0UE9dYRNKHzsamKskQFYMvj05SC%2Bk%3D&reserved=0>%2Fmailman%2Flistinfo%2Ftf- > a&data=04%7C01%7C > >> v > >> > wadekar%40nvidia.com <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40nvidia.com%2F&data=04%7C01%7Cvwadekar%40nvidia.com%7C608ad69f28c14c62691008d9364a94ef%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637600516235208146%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4aiNFrFW03%2Fv6mZShMO%2F2VBGqgng4VoPE7Lm7%2FWiD58%3D&reserved=0>%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 <mailto:TF-A@lists.trustedfirmware.org> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-a&data=04%7C01%7Cvwadekar%40nvidia.com%7C608ad69f28c14c62691008d9364a94ef%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637600516235208146%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=y64P9mgLL%2FKacvds9CJE87DQ8ZvcuAXT6bkfudQcPr0%3D&reserved=0
Hi Michal,
I expect there is going to be a need to access these messages. Is there
any driver/protocol in place which can be used for it? Or even reading of this buffer can be considered as a potential security hole. I am not aware of any standard driver/protocol use to retrieve the secure buffer log. I think it will be a platform-specific implementation till we establish standard implementation.
Thanks, Mayur
On Wed, Jun 23, 2021 at 9:27 AM Michal Simek michal.simek@xilinx.com wrote:
Hi,
let's say that messages will be stored to secure memory buffer. I expect there is going to be a need to access these messages. Is there any driver/protocol in place which can be used for it? Or even reading of this buffer can be consider as potential security hole.
Or any concept of one way virtual console which could be access from NS?
Thanks, Michal
On 6/23/21 3:18 PM, Mayur wrote:
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 mailto: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 <mailto:michal.simek@xilinx.com>> > Sent: Wednesday, June 23, 2021 9:16 AM > To: Varun Wadekar <vwadekar@nvidia.com <mailto:vwadekar@nvidia.com>>; Soby Mathew > <Soby.Mathew@arm.com <mailto:Soby.Mathew@arm.com>>; Michal Simek <michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>> > Cc: tf-a@lists.trustedfirmware.org <mailto: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 notpractical.
> 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 isnot
> straight forward and platforms might choose to keep the code totoggle
> clock/reset out of TF-A. > > > > -Varun > > > > -----Original Message----- > > From: Soby Mathew <Soby.Mathew@arm.com <mailto:Soby.Mathew@arm.com>>
> > Sent: Tuesday, June 22, 2021 4:30 PM > > To: Michal Simek <michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>>; Varun Wadekar > > <vwadekar@nvidia.com <mailto:vwadekar@nvidia.com>> > > Cc: tf-a@lists.trustedfirmware.org <mailto: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 partof
> plat_crash_console_init(). > > > > HTH, > > Best Regards > > Soby Mathew > > > >> -----Original Message----- > >> From: TF-A <tf-a-bounces@lists.trustedfirmware.org <mailto: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 <mailto:vwadekar@nvidia.com>>; Michal Simek > >> <michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>> > >> Cc: tf-a@lists.trustedfirmware.org <mailto: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 expectthe
> >> same hooks should be added also to reset. > >> > >> And is TF-A informs your special firmware that for exampleserial
> >> 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 <mailto:michal.simek@xilinx.com>> > >>> Sent: Tuesday, June 22, 2021 7:24 AM > >>> To: Varun Wadekar <vwadekar@nvidia.com <mailto:vwadekar@nvidia.com>>; Michal Simek > >>> <michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>> > >>> Cc: tf-a@lists.trustedfirmware.org <mailto: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 aconcept
> >>> 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/ <https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/%3E
> >>> 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 <mailto: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 <mailto: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 allthe
> >> 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 <mailto:TF-A@lists.trustedfirmware.org> > >>>> > >>https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis < https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis%3E
> >>>> t > >>>> s.trustedfirmware.org <http://s.trustedfirmware.org>%2Fmailman%2Flistinfo%2Ftf- > >> a&data=04%7C01%7C > >>>> > >> > vwadekar%40nvidia.com <http://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 <mailto:TF-A@lists.trustedfirmware.org> > >>https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis < https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis%3E
> >> t > >> s.trustedfirmware.org <http://s.trustedfirmware.org>%2Fmailman%2Flistinfo%2Ftf- > a&data=04%7C01%7C > >> v > >> > wadekar%40nvidia.com <http://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 <mailto:TF-A@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a>
Hi There is a memory based console driver implemented for coreboot platform in TF-A , present in drivers/coreboot/cbmem_console.S. This is the producer side and I suspect the consumer side can be found in coreboot. Perhaps this can be adopted as a standard implementation if it fits the requirement.
Best Regards Soby Mathew
From: Mayur mayurvg@gmail.com Sent: Thursday, June 24, 2021 11:18 AM To: Michal Simek michal.simek@xilinx.com Cc: Soby Mathew Soby.Mathew@arm.com; Varun Wadekar vwadekar@nvidia.com; tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] PL011 clock handling between TF-A and Linux
Hi Michal,
I expect there is going to be a need to access these messages. Is there any driver/protocol in place which can be used for it? Or even reading of this buffer can be considered as a potential security hole.
I am not aware of any standard driver/protocol use to retrieve the secure buffer log. I think it will be a platform-specific implementation till we establish standard implementation.
Thanks, Mayur
On Wed, Jun 23, 2021 at 9:27 AM Michal Simek <michal.simek@xilinx.commailto:michal.simek@xilinx.com> wrote: Hi,
let's say that messages will be stored to secure memory buffer. I expect there is going to be a need to access these messages. Is there any driver/protocol in place which can be used for it? Or even reading of this buffer can be consider as potential security hole.
Or any concept of one way virtual console which could be access from NS?
Thanks, Michal
On 6/23/21 3:18 PM, Mayur wrote:
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.orgmailto:tf-a@lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.orgmailto: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<mailto:michal.simek@xilinx.com> <mailto:michal.simek@xilinx.com<mailto:michal.simek@xilinx.com>>> > Sent: Wednesday, June 23, 2021 9:16 AM > To: Varun Wadekar <vwadekar@nvidia.com<mailto:vwadekar@nvidia.com> <mailto:vwadekar@nvidia.com<mailto:vwadekar@nvidia.com>>>; Soby Mathew > <Soby.Mathew@arm.com<mailto:Soby.Mathew@arm.com> <mailto:Soby.Mathew@arm.com<mailto:Soby.Mathew@arm.com>>>; Michal Simek <michal.simek@xilinx.com<mailto:michal.simek@xilinx.com> <mailto:michal.simek@xilinx.com<mailto:michal.simek@xilinx.com>>> > Cc: tf-a@lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <mailto:tf-a@lists.trustedfirmware.org<mailto: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<mailto:Soby.Mathew@arm.com> <mailto:Soby.Mathew@arm.com<mailto:Soby.Mathew@arm.com>>> > > Sent: Tuesday, June 22, 2021 4:30 PM > > To: Michal Simek <michal.simek@xilinx.com<mailto:michal.simek@xilinx.com> <mailto:michal.simek@xilinx.com<mailto:michal.simek@xilinx.com>>>; Varun Wadekar > > <vwadekar@nvidia.com<mailto:vwadekar@nvidia.com> <mailto:vwadekar@nvidia.com<mailto:vwadekar@nvidia.com>>> > > Cc: tf-a@lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <mailto:tf-a@lists.trustedfirmware.org<mailto: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<mailto:tf-a-bounces@lists.trustedfirmware.org> <mailto:tf-a-bounces@lists.trustedfirmware.org<mailto: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<mailto:vwadekar@nvidia.com> <mailto:vwadekar@nvidia.com<mailto:vwadekar@nvidia.com>>>; Michal Simek > >> <michal.simek@xilinx.com<mailto:michal.simek@xilinx.com> <mailto:michal.simek@xilinx.com<mailto:michal.simek@xilinx.com>>> > >> Cc: tf-a@lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <mailto:tf-a@lists.trustedfirmware.org<mailto: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<mailto:michal.simek@xilinx.com> <mailto:michal.simek@xilinx.com<mailto:michal.simek@xilinx.com>>> > >>> Sent: Tuesday, June 22, 2021 7:24 AM > >>> To: Varun Wadekar <vwadekar@nvidia.com<mailto:vwadekar@nvidia.com> <mailto:vwadekar@nvidia.com<mailto:vwadekar@nvidia.com>>>; Michal Simek > >>> <michal.simek@xilinx.com<mailto:michal.simek@xilinx.com> <mailto:michal.simek@xilinx.com<mailto:michal.simek@xilinx.com>>> > >>> Cc: tf-a@lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org> <mailto:tf-a@lists.trustedfirmware.org<mailto: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/ <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<mailto:tf-a-bounces@lists.trustedfirmware.org> <mailto:tf-a-bounces@lists.trustedfirmware.org<mailto: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<mailto:tf-a@lists.trustedfirmware.org> <mailto:tf-a@lists.trustedfirmware.org<mailto: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<mailto:TF-A@lists.trustedfirmware.org> <mailto:TF-A@lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org>> > >>>> > >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis> > >>>> t > >>>> s.trustedfirmware.org<http://s.trustedfirmware.org> <http://s.trustedfirmware.org>%2Fmailman%2Flistinfo%2Ftf- > >> a&data=04%7C01%7C > >>>> > >> > vwadekar%40nvidia.com<http://40nvidia.com> <http://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<mailto:TF-A@lists.trustedfirmware.org> <mailto:TF-A@lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org>> > >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis> > >> t > >> s.trustedfirmware.org<http://s.trustedfirmware.org> <http://s.trustedfirmware.org>%2Fmailman%2Flistinfo%2Ftf- > a&data=04%7C01%7C > >> v > >> > wadekar%40nvidia.com<http://40nvidia.com> <http://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<mailto:TF-A@lists.trustedfirmware.org> <mailto:TF-A@lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a>
Hi,
The linux driver to communicate with the external firmware that manages clock and reset is present at https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/driver... and https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/driver...
The TF-A driver to communicate with the external firmware that manages clock and reset is present at https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/nvidia...
The linux driver to communicate with the external firmware that manages the combined UART is present at https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/driver....
The TF-A driver to communicate with the external firmware that manages the combined UART is present at https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/nvidia...
These managers are specific to Tegra and interact via a custom interface.
-Varun
-----Original Message----- From: Michal Simek michal.simek@xilinx.com Sent: Thursday, June 24, 2021 7:24 AM To: Varun Wadekar vwadekar@nvidia.com; Michal Simek michal.simek@xilinx.com; Mayur mayurvg@gmail.com; Soby Mathew Soby.Mathew@arm.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,
where is that manager implemented? In TFA or in your private firmware? Is there specific channel for communication or you use smc based protocol from NS to Secure, any virtio? Doing this in a standard way across vendors would be the best solution.
Thanks, Michal
On 6/23/21 8:37 PM, Varun Wadekar wrote:
Hi,
+1 to Michal's comments.
Now we are talking about providing a UART port for every controller in the system. Although this would be a great scenario, it is not practical and not preferred/implemented by all platforms.
Tegra platforms implement a manager for the UART port, that also acts as the arbiter. All clients push their UART logs to the manager which makes sure that logs are not garbled.
-Varun
-----Original Message----- From: Michal Simek michal.simek@xilinx.com Sent: Wednesday, June 23, 2021 2:27 PM To: Mayur mayurvg@gmail.com; Soby Mathew Soby.Mathew@arm.com Cc: Michal Simek michal.simek@xilinx.com; Varun Wadekar vwadekar@nvidia.com; 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,
let's say that messages will be stored to secure memory buffer. I expect there is going to be a need to access these messages. Is there any driver/protocol in place which can be used for it? Or even reading of this buffer can be consider as potential security hole.
Or any concept of one way virtual console which could be access from NS?
Thanks, Michal
On 6/23/21 3:18 PM, Mayur wrote:
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 mailto: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 <mailto:michal.simek@xilinx.com>> > Sent: Wednesday, June 23, 2021 9:16 AM > To: Varun Wadekar <vwadekar@nvidia.com <mailto:vwadekar@nvidia.com>>; Soby Mathew > <Soby.Mathew@arm.com <mailto:Soby.Mathew@arm.com>>; Michal Simek <michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>> > Cc: tf-a@lists.trustedfirmware.org <mailto: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 <mailto:Soby.Mathew@arm.com>> > > Sent: Tuesday, June 22, 2021 4:30 PM > > To: Michal Simek <michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>>; Varun Wadekar > > <vwadekar@nvidia.com <mailto:vwadekar@nvidia.com>> > > Cc: tf-a@lists.trustedfirmware.org <mailto: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 <mailto: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 <mailto:vwadekar@nvidia.com>>; Michal Simek > >> <michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>> > >> Cc: tf-a@lists.trustedfirmware.org <mailto: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 <mailto:michal.simek@xilinx.com>> > >>> Sent: Tuesday, June 22, 2021 7:24 AM > >>> To: Varun Wadekar <vwadekar@nvidia.com <mailto:vwadekar@nvidia.com>>; Michal Simek > >>> <michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>> > >>> Cc: tf-a@lists.trustedfirmware.org <mailto: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/ <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 <mailto: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 <mailto: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 <mailto:TF-A@lists.trustedfirmware.org> > >>>> > >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis> > >>>> t > >>>> s.trustedfirmware.org <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fs.trustedfirmware.org%2F&data=04%7C01%7Cvwadekar%40nvidia.com%7Ca90f9c6d3d7f4d65b90a08d936d89b7d%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637601126222992330%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=YNO%2BqZ1I8tYuBF60zOBd2J01byM7MdCR5LJ%2B5XOqz7o%3D&reserved=0>%2Fmailman%2Flistinfo%2Ftf- > >> a&data=04%7C01%7C > >>>> > >> > vwadekar%40nvidia.com <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40nvidia.com%2F&data=04%7C01%7Cvwadekar%40nvidia.com%7Ca90f9c6d3d7f4d65b90a08d936d89b7d%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637601126223002287%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=J%2Fsc%2F2ZQSKb6m1xx1K3IuM%2FXWq8Shrjan6xxsmes2bM%3D&reserved=0>%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 <mailto:TF-A@lists.trustedfirmware.org> > >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis> > >> t > >> s.trustedfirmware.org <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fs.trustedfirmware.org%2F&data=04%7C01%7Cvwadekar%40nvidia.com%7Ca90f9c6d3d7f4d65b90a08d936d89b7d%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637601126223002287%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SZx2gUM4TuLkt5EoXfZbLxfqvBkoS%2BbtbUgZUOC48iw%3D&reserved=0>%2Fmailman%2Flistinfo%2Ftf- > a&data=04%7C01%7C > >> v > >> > wadekar%40nvidia.com <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F40nvidia.com%2F&data=04%7C01%7Cvwadekar%40nvidia.com%7Ca90f9c6d3d7f4d65b90a08d936d89b7d%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637601126223002287%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=J%2Fsc%2F2ZQSKb6m1xx1K3IuM%2FXWq8Shrjan6xxsmes2bM%3D&reserved=0>%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 <mailto:TF-A@lists.trustedfirmware.org>https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis ts.trustedfirmware.org%2Fmailman%2Flistinfo%2Ftf-a&data=04%7C01%7 Cvwadekar%40nvidia.com%7Ca90f9c6d3d7f4d65b90a08d936d89b7d%7C43083d157 27340c1b7db39efd9ccc17a%7C0%7C0%7C637601126223002287%7CUnknown%7CTWFp bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M n0%3D%7C1000&sdata=bS4OcnGG76jcpb%2B0NdMhibNNZONkPyfBiK4ycuQ0hS0% 3D&reserved=0
Hi Soby,
is ARM going to design/spec any solution which can be used across SOCs?
Thanks, Michal
On 6/24/21 2:41 PM, Soby Mathew wrote:
Hi
There is a memory based console driver implemented for coreboot platform in TF-A , present in drivers/coreboot/cbmem_console.S. This is the producer side and I suspect the consumer side can be found in coreboot. Perhaps this can be adopted as a standard implementation if it fits the requirement.
Best Regards
Soby Mathew
*From:* Mayur mayurvg@gmail.com *Sent:* Thursday, June 24, 2021 11:18 AM *To:* Michal Simek michal.simek@xilinx.com *Cc:* Soby Mathew Soby.Mathew@arm.com; Varun Wadekar vwadekar@nvidia.com; tf-a@lists.trustedfirmware.org *Subject:* Re: [TF-A] PL011 clock handling between TF-A and Linux
Hi Michal,
I expect there is going to be a need to access these messages. Is there any driver/protocol in place which can be used for it? Or even reading of this buffer can be considered as a potential security hole.
I am not aware of any standard driver/protocol use to retrieve the secure buffer log. I think it will be a platform-specific implementation till we establish standard implementation.
Thanks, Mayur
On Wed, Jun 23, 2021 at 9:27 AM Michal Simek <michal.simek@xilinx.com mailto:michal.simek@xilinx.com> wrote:
Hi, let's say that messages will be stored to secure memory buffer. I expect there is going to be a need to access these messages. Is there any driver/protocol in place which can be used for it? Or even reading of this buffer can be consider as potential security hole. Or any concept of one way virtual console which could be access from NS? Thanks, Michal On 6/23/21 3:18 PM, Mayur wrote: > 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 <mailto:tf-a@lists.trustedfirmware.org> <mailto:tf-a@lists.trustedfirmware.org <mailto: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 <mailto:michal.simek@xilinx.com> > <mailto:michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>>> > > Sent: Wednesday, June 23, 2021 9:16 AM > > To: Varun Wadekar <vwadekar@nvidia.com <mailto:vwadekar@nvidia.com> > <mailto:vwadekar@nvidia.com <mailto:vwadekar@nvidia.com>>>; Soby Mathew > > <Soby.Mathew@arm.com <mailto:Soby.Mathew@arm.com> <mailto:Soby.Mathew@arm.com <mailto:Soby.Mathew@arm.com>>>; Michal Simek > <michal.simek@xilinx.com <mailto:michal.simek@xilinx.com> <mailto:michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>>> > > Cc: tf-a@lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> > <mailto:tf-a@lists.trustedfirmware.org <mailto: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 <mailto:Soby.Mathew@arm.com> <mailto:Soby.Mathew@arm.com <mailto:Soby.Mathew@arm.com>>> > > > Sent: Tuesday, June 22, 2021 4:30 PM > > > To: Michal Simek <michal.simek@xilinx.com <mailto:michal.simek@xilinx.com> > <mailto:michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>>>; Varun Wadekar > > > <vwadekar@nvidia.com <mailto:vwadekar@nvidia.com> <mailto:vwadekar@nvidia.com <mailto:vwadekar@nvidia.com>>> > > > Cc: tf-a@lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> > <mailto:tf-a@lists.trustedfirmware.org <mailto: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 <mailto:tf-a-bounces@lists.trustedfirmware.org> > <mailto:tf-a-bounces@lists.trustedfirmware.org <mailto: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 <mailto:vwadekar@nvidia.com> > <mailto:vwadekar@nvidia.com <mailto:vwadekar@nvidia.com>>>; Michal Simek > > >> <michal.simek@xilinx.com <mailto:michal.simek@xilinx.com> <mailto:michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>>> > > >> Cc: tf-a@lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> > <mailto:tf-a@lists.trustedfirmware.org <mailto: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 <mailto:michal.simek@xilinx.com> > <mailto:michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>>> > > >>> Sent: Tuesday, June 22, 2021 7:24 AM > > >>> To: Varun Wadekar <vwadekar@nvidia.com <mailto:vwadekar@nvidia.com> > <mailto:vwadekar@nvidia.com <mailto:vwadekar@nvidia.com>>>; Michal Simek > > >>> <michal.simek@xilinx.com <mailto:michal.simek@xilinx.com> <mailto:michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>>> > > >>> Cc: tf-a@lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> > <mailto:tf-a@lists.trustedfirmware.org <mailto: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/ <https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/> > <https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/ <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 <mailto:tf-a-bounces@lists.trustedfirmware.org> > <mailto:tf-a-bounces@lists.trustedfirmware.org <mailto: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 <mailto:tf-a@lists.trustedfirmware.org> > <mailto:tf-a@lists.trustedfirmware.org <mailto: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 <mailto:TF-A@lists.trustedfirmware.org> > <mailto:TF-A@lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org>> > > >>>> > > >> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis>> > > >>>> t > > >>>> s.trustedfirmware.org <http://s.trustedfirmware.org> > <http://s.trustedfirmware.org <http://s.trustedfirmware.org>>%2Fmailman%2Flistinfo%2Ftf- > > >> a&data=04%7C01%7C > > >>>> > > >> > > vwadekar%40nvidia.com <http://40nvidia.com> > <http://40nvidia.com <http://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 <mailto:TF-A@lists.trustedfirmware.org> > <mailto:TF-A@lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org>> > > >> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis>> > > >> t > > >> s.trustedfirmware.org <http://s.trustedfirmware.org> > <http://s.trustedfirmware.org <http://s.trustedfirmware.org>>%2Fmailman%2Flistinfo%2Ftf- > > a&data=04%7C01%7C > > >> v > > >> > > wadekar%40nvidia.com <http://40nvidia.com> > <http://40nvidia.com <http://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 <mailto:TF-A@lists.trustedfirmware.org> <mailto:TF-A@lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org>> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> > <https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a>> >
Hi Michal, No, there is no plan for doing this from Arm side. My suggestion would be to use the coreboot cbmem driver and there seems to be support for this in the linux kernel https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/driver... , but I haven't analyzed how this works with CBMEM in TF-A.
Best Regards Soby Mathew
-----Original Message----- From: Michal Simek michal.simek@xilinx.com Sent: Wednesday, June 30, 2021 10:51 AM To: Soby Mathew Soby.Mathew@arm.com; Mayur mayurvg@gmail.com; Michal Simek michal.simek@xilinx.com Cc: Varun Wadekar vwadekar@nvidia.com; tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] PL011 clock handling between TF-A and Linux
Hi Soby,
is ARM going to design/spec any solution which can be used across SOCs?
Thanks, Michal
On 6/24/21 2:41 PM, Soby Mathew wrote:
Hi
There is a memory based console driver implemented for coreboot platform in TF-A , present in drivers/coreboot/cbmem_console.S. This is the producer side and I suspect the consumer side can be found in
coreboot.
Perhaps this can be adopted as a standard implementation if it fits the requirement.
Best Regards
Soby Mathew
*From:* Mayur mayurvg@gmail.com *Sent:* Thursday, June 24, 2021 11:18 AM *To:* Michal Simek michal.simek@xilinx.com *Cc:* Soby Mathew Soby.Mathew@arm.com; Varun Wadekar vwadekar@nvidia.com; tf-a@lists.trustedfirmware.org *Subject:* Re: [TF-A] PL011 clock handling between TF-A and Linux
Hi Michal,
I expect there is going to be a need to access these messages. Is there
any driver/protocol in place which can be used for it? Or even reading of this buffer can be considered as a potential security hole.
I am not aware of any standard driver/protocol use to retrieve the secure buffer log. I think it will be a platform-specific implementation till we establish standard implementation.
Thanks, Mayur
On Wed, Jun 23, 2021 at 9:27 AM Michal Simek <michal.simek@xilinx.com mailto:michal.simek@xilinx.com> wrote:
Hi, let's say that messages will be stored to secure memory buffer. I expect there is going to be a need to access these messages. Is there any driver/protocol in place which can be used for it? Or even reading of this buffer can be consider as potential security hole. Or any concept of one way virtual console which could be access from NS? Thanks, Michal On 6/23/21 3:18 PM, Mayur wrote: > 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, UARTownership
> 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 <mailto:tf-a@lists.trustedfirmware.org> <mailto:tf-a@lists.trustedfirmware.org <mailto: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 <mailto:michal.simek@xilinx.com> > <mailto:michal.simek@xilinx.commailto:michal.simek@xilinx.com>>
> > Sent: Wednesday, June 23, 2021 9:16 AM > > To: Varun Wadekar <vwadekar@nvidia.com <mailto:vwadekar@nvidia.com> > <mailto:vwadekar@nvidia.com <mailto:vwadekar@nvidia.com>>>; Soby Mathew > > <Soby.Mathew@arm.com <mailto:Soby.Mathew@arm.com> <mailto:Soby.Mathew@arm.com <mailto:Soby.Mathew@arm.com>>>;Michal Simek
> <michal.simek@xilinx.com <mailto:michal.simek@xilinx.com> <mailto:michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>>> > > Cc: tf-a@lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> > <mailto:tf-a@lists.trustedfirmware.org <mailto: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 <mailto:Soby.Mathew@arm.com> <mailto:Soby.Mathew@arm.com <mailto:Soby.Mathew@arm.com>>> > > > Sent: Tuesday, June 22, 2021 4:30 PM > > > To: Michal Simek <michal.simek@xilinx.com <mailto:michal.simek@xilinx.com> > <mailto:michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>>>; Varun Wadekar > > > <vwadekar@nvidia.com <mailto:vwadekar@nvidia.com> <mailto:vwadekar@nvidia.com <mailto:vwadekar@nvidia.com>>> > > > Cc: tf-a@lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> > <mailto:tf-a@lists.trustedfirmware.org <mailto: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 <mailto:tf-a-bounces@lists.trustedfirmware.org> > <mailto:tf-a-bounces@lists.trustedfirmware.org <mailto: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 <mailto:vwadekar@nvidia.com> > <mailto:vwadekar@nvidia.com <mailto:vwadekar@nvidia.com>>>; Michal Simek > > >> <michal.simek@xilinx.com <mailto:michal.simek@xilinx.com> <mailto:michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>>> > > >> Cc: tf-a@lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> > <mailto:tf-a@lists.trustedfirmware.org <mailto: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 <mailto:michal.simek@xilinx.com> > <mailto:michal.simek@xilinx.commailto:michal.simek@xilinx.com>>
> > >>> Sent: Tuesday, June 22, 2021 7:24 AM > > >>> To: Varun Wadekar <vwadekar@nvidia.com <mailto:vwadekar@nvidia.com> > <mailto:vwadekar@nvidia.com <mailto:vwadekar@nvidia.com>>>; Michal Simek > > >>> <michal.simek@xilinx.com <mailto:michal.simek@xilinx.com> <mailto:michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>>> > > >>> Cc: tf-a@lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> > <mailto:tf-a@lists.trustedfirmware.org <mailto: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/https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/
> <https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/ <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 <mailto:tf-a-bounces@lists.trustedfirmware.org> > <mailto:tf-a-bounces@lists.trustedfirmware.org <mailto: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 <mailto:tf-a@lists.trustedfirmware.org> > <mailto:tf-a@lists.trustedfirmware.org <mailto: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 <mailto:TF-A@lists.trustedfirmware.org> > <mailto:TF-A@lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org>> > > >>>> > > >> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flishttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis>
> > >>>> t > > >>>> s.trustedfirmware.org <http://s.trustedfirmware.org> > <http://s.trustedfirmware.org <http://s.trustedfirmware.org>>%2Fmailman%2Flistinfo%2Ftf- > > >> a&data=04%7C01%7C > > >>>> > > >> > > vwadekar%40nvidia.com <http://40nvidia.com> > <http://40nvidia.comhttp://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 <mailto:TF-A@lists.trustedfirmware.org> > <mailto:TF-A@lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org>> > > >> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flishttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis>
> > >> t > > >> s.trustedfirmware.org <http://s.trustedfirmware.org> > <http://s.trustedfirmware.org <http://s.trustedfirmware.org>>%2Fmailman%2Flistinfo%2Ftf- > > a&data=04%7C01%7C > > >> v > > >> > > wadekar%40nvidia.com <http://40nvidia.com> > <http://40nvidia.comhttp://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 <mailto:TF-A@lists.trustedfirmware.org> <mailto:TF-A@lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org>> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> > <https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a>> >
Hi Soby,
ok.
Thanks, Michal
On 6/30/21 4:35 PM, Soby Mathew wrote:
Hi Michal, No, there is no plan for doing this from Arm side. My suggestion would be to use the coreboot cbmem driver and there seems to be support for this in the linux kernel https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/driver... , but I haven't analyzed how this works with CBMEM in TF-A.
Best Regards Soby Mathew
-----Original Message----- From: Michal Simek michal.simek@xilinx.com Sent: Wednesday, June 30, 2021 10:51 AM To: Soby Mathew Soby.Mathew@arm.com; Mayur mayurvg@gmail.com; Michal Simek michal.simek@xilinx.com Cc: Varun Wadekar vwadekar@nvidia.com; tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] PL011 clock handling between TF-A and Linux
Hi Soby,
is ARM going to design/spec any solution which can be used across SOCs?
Thanks, Michal
On 6/24/21 2:41 PM, Soby Mathew wrote:
Hi
There is a memory based console driver implemented for coreboot platform in TF-A , present in drivers/coreboot/cbmem_console.S. This is the producer side and I suspect the consumer side can be found in
coreboot.
Perhaps this can be adopted as a standard implementation if it fits the requirement.
Best Regards
Soby Mathew
*From:* Mayur mayurvg@gmail.com *Sent:* Thursday, June 24, 2021 11:18 AM *To:* Michal Simek michal.simek@xilinx.com *Cc:* Soby Mathew Soby.Mathew@arm.com; Varun Wadekar vwadekar@nvidia.com; tf-a@lists.trustedfirmware.org *Subject:* Re: [TF-A] PL011 clock handling between TF-A and Linux
Hi Michal,
I expect there is going to be a need to access these messages. Is there
any driver/protocol in place which can be used for it? Or even reading of this buffer can be considered as a potential security hole.
I am not aware of any standard driver/protocol use to retrieve the secure buffer log. I think it will be a platform-specific implementation till we establish standard implementation.
Thanks, Mayur
On Wed, Jun 23, 2021 at 9:27 AM Michal Simek <michal.simek@xilinx.com mailto:michal.simek@xilinx.com> wrote:
Hi, let's say that messages will be stored to secure memory buffer. I expect there is going to be a need to access these messages. Is there any driver/protocol in place which can be used for it? Or even reading of this buffer can be consider as potential security hole. Or any concept of one way virtual console which could be access from NS? Thanks, Michal On 6/23/21 3:18 PM, Mayur wrote: > 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, UARTownership
> 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 <mailto:tf-a@lists.trustedfirmware.org> <mailto:tf-a@lists.trustedfirmware.org <mailto: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 <mailto:michal.simek@xilinx.com> > <mailto:michal.simek@xilinx.commailto:michal.simek@xilinx.com>>
> > Sent: Wednesday, June 23, 2021 9:16 AM > > To: Varun Wadekar <vwadekar@nvidia.com <mailto:vwadekar@nvidia.com> > <mailto:vwadekar@nvidia.com <mailto:vwadekar@nvidia.com>>>; Soby Mathew > > <Soby.Mathew@arm.com <mailto:Soby.Mathew@arm.com> <mailto:Soby.Mathew@arm.com <mailto:Soby.Mathew@arm.com>>>;Michal Simek
> <michal.simek@xilinx.com <mailto:michal.simek@xilinx.com> <mailto:michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>>> > > Cc: tf-a@lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> > <mailto:tf-a@lists.trustedfirmware.org <mailto: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 <mailto:Soby.Mathew@arm.com> <mailto:Soby.Mathew@arm.com <mailto:Soby.Mathew@arm.com>>> > > > Sent: Tuesday, June 22, 2021 4:30 PM > > > To: Michal Simek <michal.simek@xilinx.com <mailto:michal.simek@xilinx.com> > <mailto:michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>>>; Varun Wadekar > > > <vwadekar@nvidia.com <mailto:vwadekar@nvidia.com> <mailto:vwadekar@nvidia.com <mailto:vwadekar@nvidia.com>>> > > > Cc: tf-a@lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> > <mailto:tf-a@lists.trustedfirmware.org <mailto: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 <mailto:tf-a-bounces@lists.trustedfirmware.org> > <mailto:tf-a-bounces@lists.trustedfirmware.org <mailto: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 <mailto:vwadekar@nvidia.com> > <mailto:vwadekar@nvidia.com <mailto:vwadekar@nvidia.com>>>; Michal Simek > > >> <michal.simek@xilinx.com <mailto:michal.simek@xilinx.com> <mailto:michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>>> > > >> Cc: tf-a@lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> > <mailto:tf-a@lists.trustedfirmware.org <mailto: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 <mailto:michal.simek@xilinx.com> > <mailto:michal.simek@xilinx.commailto:michal.simek@xilinx.com>>
> > >>> Sent: Tuesday, June 22, 2021 7:24 AM > > >>> To: Varun Wadekar <vwadekar@nvidia.com <mailto:vwadekar@nvidia.com> > <mailto:vwadekar@nvidia.com <mailto:vwadekar@nvidia.com>>>; Michal Simek > > >>> <michal.simek@xilinx.com <mailto:michal.simek@xilinx.com> <mailto:michal.simek@xilinx.com <mailto:michal.simek@xilinx.com>>> > > >>> Cc: tf-a@lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org> > <mailto:tf-a@lists.trustedfirmware.org <mailto: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/https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/
> <https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/ <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 <mailto:tf-a-bounces@lists.trustedfirmware.org> > <mailto:tf-a-bounces@lists.trustedfirmware.org <mailto: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 <mailto:tf-a@lists.trustedfirmware.org> > <mailto:tf-a@lists.trustedfirmware.org <mailto: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 <mailto:TF-A@lists.trustedfirmware.org> > <mailto:TF-A@lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org>> > > >>>> > > >> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flishttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis>
> > >>>> t > > >>>> s.trustedfirmware.org <http://s.trustedfirmware.org> > <http://s.trustedfirmware.org <http://s.trustedfirmware.org>>%2Fmailman%2Flistinfo%2Ftf- > > >> a&data=04%7C01%7C > > >>>> > > >> > > vwadekar%40nvidia.com <http://40nvidia.com> > <http://40nvidia.comhttp://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 <mailto:TF-A@lists.trustedfirmware.org> > <mailto:TF-A@lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org>> > > >> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flishttps://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis>
> > >> t > > >> s.trustedfirmware.org <http://s.trustedfirmware.org> > <http://s.trustedfirmware.org <http://s.trustedfirmware.org>>%2Fmailman%2Flistinfo%2Ftf- > > a&data=04%7C01%7C > > >> v > > >> > > wadekar%40nvidia.com <http://40nvidia.com> > <http://40nvidia.comhttp://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 <mailto:TF-A@lists.trustedfirmware.org> <mailto:TF-A@lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org>> > https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a> > <https://lists.trustedfirmware.org/mailman/listinfo/tf-a <https://lists.trustedfirmware.org/mailman/listinfo/tf-a>> >
tf-a@lists.trustedfirmware.org
-
Mayur -
Michal Simek -
Soby Mathew -
Varun Wadekar