30 Jun
2021
30 Jun
'21
4:41 p.m.
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>> >