Hi all,
It seems that on v2.0 there is a problem with FLIH handling during execution of SPM thread.
1. A partition #1 is running with unprivileged attribute (CONTROL.nPRIV = 1). 2. It requests PSA API (for example psa_call). 3. psa_call is serviced via SVC. prepare_to_thread_mode_spm schedules handling of psa_call in SPM thread mode (by prepare_to_thread_mode_spm). 4. prepare_to_thread_mode_spm saves CONTROL to saved_control. Than set CONTROL.nPRIV = 0 (privileged for SPM thread). 5. Exit from SVC starts execution of tfm_spm_client_psa_call in SPM thread (privileged). 6. SPM thread is interrupted by FLIH IRQ. 7. FLIH IRQ handler calls spm_handle_interrupt. 8. spm_handle_interrupt switches boundary to prepare environment for FLIH handler (partition #2) and schedules execution of FLIH handler. 9. FLIH handler is executed. 10. tfm_flih_return_to_isr is called on exit from FLIH handler. It restores boundary of partition #1 and set CONTROL.nPRIV = 1. Than returns to FLIH IRQ handler. 11. FLIH IRQ handler exit to SPM thread that has been interrupted on step #6. 12. SPM thread have no enough permissions, because it's running with CONTROL.nPRIV equal to 1 (unprivileged). So, processing environment is unprivileged and tfm_spm_client_psa_call fails on accessing restricted resource.
Does my understanding correct? If yes it means that we should fix exit from FLIH to SPM thread.
Regards, Roman.
Hi Roman,
Thank you for sharing your findings. Let us check and back with comments.
Thanks and best regards, Anton
From: Roman.Mazurak--- via TF-M tf-m@lists.trustedfirmware.org Sent: Friday, February 16, 2024 11:20 AM To: tf-m@lists.trustedfirmware.org Cc: Bohdan.Hunko@infineon.com; Chris.Brand@infineon.com Subject: [TF-M] SPM thread and FLIH
Hi all,
It seems that on v2.0 there is a problem with FLIH handling during execution of SPM thread.
1. A partition #1 is running with unprivileged attribute (CONTROL.nPRIV = 1). 2. It requests PSA API (for example psa_call). 3. psa_call is serviced via SVC. prepare_to_thread_mode_spm schedules handling of psa_call in SPM thread mode (by prepare_to_thread_mode_spm). 4. prepare_to_thread_mode_spm saves CONTROL to saved_control. Than set CONTROL.nPRIV = 0 (privileged for SPM thread). 5. Exit from SVC starts execution of tfm_spm_client_psa_call in SPM thread (privileged). 6. SPM thread is interrupted by FLIH IRQ. 7. FLIH IRQ handler calls spm_handle_interrupt. 8. spm_handle_interrupt switches boundary to prepare environment for FLIH handler (partition #2) and schedules execution of FLIH handler. 9. FLIH handler is executed. 10. tfm_flih_return_to_isr is called on exit from FLIH handler. It restores boundary of partition #1 and set CONTROL.nPRIV = 1. Than returns to FLIH IRQ handler. 11. FLIH IRQ handler exit to SPM thread that has been interrupted on step #6. 12. SPM thread have no enough permissions, because it's running with CONTROL.nPRIV equal to 1 (unprivileged). So, processing environment is unprivileged and tfm_spm_client_psa_call fails on accessing restricted resource.
Does my understanding correct? If yes it means that we should fix exit from FLIH to SPM thread.
Regards, Roman.
Hi Roman,
Thank you for reporting this issue.
I didn't yet have the time to reproduce the scenario you posted, but looking at the code, here is what I see: The function tfm_hal_activate_boundary, that is called by tfm_flih_return_to_isr seems to be restoring the privilege level for the active secure partition, regardless of whether unprivileged partition code, or privileged SPM code was executing when the interrupt became active.
The problem seems that with the current logic SPM considers the CONTROL.nPRIV mechanism to be an independent thing from the mechanism that provides isolation between secure partitions. However, it is not true, as the HAL implementations are using this same CONTROL.nPRIV mechanism to realise isolation.
This should probably be fixed in tfm_flih_return_to_isr, setting CONTROL.nPRIV=0 if the interrupted code was privileged. A getter on this could be added to tfm_svcalls.h.
As you already seem to have the environment on reproducing the issue/testing a potential fix, would you mind creating a patch for this? If not, I can create it myself.
Best Regards, Mate
________________________________ From: Anton Komlev via TF-M tf-m@lists.trustedfirmware.org Sent: 19 February 2024 12:58 To: Roman.Mazurak@infineon.com Roman.Mazurak@infineon.com; tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org Cc: Bohdan.Hunko@infineon.com Bohdan.Hunko@infineon.com; Chris.Brand@infineon.com Chris.Brand@infineon.com Subject: [TF-M] Re: SPM thread and FLIH
Hi Roman,
Thank you for sharing your findings. Let us check and back with comments.
Thanks and best regards,
Anton
From: Roman.Mazurak--- via TF-M tf-m@lists.trustedfirmware.org Sent: Friday, February 16, 2024 11:20 AM To: tf-m@lists.trustedfirmware.org Cc: Bohdan.Hunko@infineon.com; Chris.Brand@infineon.com Subject: [TF-M] SPM thread and FLIH
Hi all,
It seems that on v2.0 there is a problem with FLIH handling during execution of SPM thread.
1. A partition #1 is running with unprivileged attribute (CONTROL.nPRIV = 1). 2. It requests PSA API (for example psa_call). 3. psa_call is serviced via SVC. prepare_to_thread_mode_spm schedules handling of psa_call in SPM thread mode (by prepare_to_thread_mode_spm). 4. prepare_to_thread_mode_spm saves CONTROL to saved_control. Than set CONTROL.nPRIV = 0 (privileged for SPM thread). 5. Exit from SVC starts execution of tfm_spm_client_psa_call in SPM thread (privileged). 6. SPM thread is interrupted by FLIH IRQ. 7. FLIH IRQ handler calls spm_handle_interrupt. 8. spm_handle_interrupt switches boundary to prepare environment for FLIH handler (partition #2) and schedules execution of FLIH handler. 9. FLIH handler is executed. 10. tfm_flih_return_to_isr is called on exit from FLIH handler. It restores boundary of partition #1 and set CONTROL.nPRIV = 1. Than returns to FLIH IRQ handler. 11. FLIH IRQ handler exit to SPM thread that has been interrupted on step #6. 12. SPM thread have no enough permissions, because it’s running with CONTROL.nPRIV equal to 1 (unprivileged). So, processing environment is unprivileged and tfm_spm_client_psa_call fails on accessing restricted resource.
Does my understanding correct? If yes it means that we should fix exit from FLIH to SPM thread.
Regards,
Roman.
Hi Mate,
It would be nice if you will provide a fix for this. Probably you have better idea how to integrate it with SPM.
I will be able to test it on our platform and provide a feedback.
Best Regards, Roman.
From: Mate Toth-Pal Mate.Toth-Pal@arm.com Sent: Monday, February 19, 2024 17:51 To: Mazurak Roman (CSS ICW SW FW 3) Roman.Mazurak@infineon.com; tf-m@lists.trustedfirmware.org; Anton Komlev Anton.Komlev@arm.com Cc: Hunko Bohdan (CSS ICW SW FW 3) Bohdan.Hunko@infineon.com; Brand Chris (CSS ICW SW) Chris.Brand@infineon.com; nd nd@arm.com Subject: Re: SPM thread and FLIH
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safehttps://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx.
Hi Roman,
Thank you for reporting this issue.
I didn't yet have the time to reproduce the scenario you posted, but looking at the code, here is what I see: The function tfm_hal_activate_boundary, that is called by tfm_flih_return_to_isr seems to be restoring the privilege level for the active secure partition, regardless of whether unprivileged partition code, or privileged SPM code was executing when the interrupt became active.
The problem seems that with the current logic SPM considers the CONTROL.nPRIV mechanism to be an independent thing from the mechanism that provides isolation between secure partitions. However, it is not true, as the HAL implementations are using this same CONTROL.nPRIV mechanism to realise isolation.
This should probably be fixed in tfm_flih_return_to_isr, setting CONTROL.nPRIV=0 if the interrupted code was privileged. A getter on this could be added to tfm_svcalls.h.
As you already seem to have the environment on reproducing the issue/testing a potential fix, would you mind creating a patch for this? If not, I can create it myself.
Best Regards, Mate
________________________________ From: Anton Komlev via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: 19 February 2024 12:58 To: Roman.Mazurak@infineon.commailto:Roman.Mazurak@infineon.com <Roman.Mazurak@infineon.commailto:Roman.Mazurak@infineon.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Cc: Bohdan.Hunko@infineon.commailto:Bohdan.Hunko@infineon.com <Bohdan.Hunko@infineon.commailto:Bohdan.Hunko@infineon.com>; Chris.Brand@infineon.commailto:Chris.Brand@infineon.com <Chris.Brand@infineon.commailto:Chris.Brand@infineon.com> Subject: [TF-M] Re: SPM thread and FLIH
Hi Roman,
Thank you for sharing your findings. Let us check and back with comments.
Thanks and best regards,
Anton
From: Roman.Mazurak--- via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Friday, February 16, 2024 11:20 AM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: Bohdan.Hunko@infineon.commailto:Bohdan.Hunko@infineon.com; Chris.Brand@infineon.commailto:Chris.Brand@infineon.com Subject: [TF-M] SPM thread and FLIH
Hi all,
It seems that on v2.0 there is a problem with FLIH handling during execution of SPM thread.
1. A partition #1 is running with unprivileged attribute (CONTROL.nPRIV = 1). 2. It requests PSA API (for example psa_call). 3. psa_call is serviced via SVC. prepare_to_thread_mode_spm schedules handling of psa_call in SPM thread mode (by prepare_to_thread_mode_spm). 4. prepare_to_thread_mode_spm saves CONTROL to saved_control. Than set CONTROL.nPRIV = 0 (privileged for SPM thread). 5. Exit from SVC starts execution of tfm_spm_client_psa_call in SPM thread (privileged). 6. SPM thread is interrupted by FLIH IRQ. 7. FLIH IRQ handler calls spm_handle_interrupt. 8. spm_handle_interrupt switches boundary to prepare environment for FLIH handler (partition #2) and schedules execution of FLIH handler. 9. FLIH handler is executed. 10. tfm_flih_return_to_isr is called on exit from FLIH handler. It restores boundary of partition #1 and set CONTROL.nPRIV = 1. Than returns to FLIH IRQ handler. 11. FLIH IRQ handler exit to SPM thread that has been interrupted on step #6. 12. SPM thread have no enough permissions, because it's running with CONTROL.nPRIV equal to 1 (unprivileged). So, processing environment is unprivileged and tfm_spm_client_psa_call fails on accessing restricted resource.
Does my understanding correct? If yes it means that we should fix exit from FLIH to SPM thread.
Regards,
Roman.
Hi Roman,
I created a patch that I believe fixes the issue you reported below. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/27308
Review comments on the are welcome.
Best Regards, Mate ________________________________ From: Roman.Mazurak@infineon.com Roman.Mazurak@infineon.com Sent: 11 March 2024 11:38 To: Mate Toth-Pal Mate.Toth-Pal@arm.com; tf-m@lists.trustedfirmware.org tf-m@lists.trustedfirmware.org; Anton Komlev Anton.Komlev@arm.com Cc: Bohdan.Hunko@infineon.com Bohdan.Hunko@infineon.com; Chris.Brand@infineon.com Chris.Brand@infineon.com; nd nd@arm.com Subject: RE: SPM thread and FLIH
Hi Mate,
It would be nice if you will provide a fix for this. Probably you have better idea how to integrate it with SPM.
I will be able to test it on our platform and provide a feedback.
Best Regards,
Roman.
From: Mate Toth-Pal Mate.Toth-Pal@arm.com Sent: Monday, February 19, 2024 17:51 To: Mazurak Roman (CSS ICW SW FW 3) Roman.Mazurak@infineon.com; tf-m@lists.trustedfirmware.org; Anton Komlev Anton.Komlev@arm.com Cc: Hunko Bohdan (CSS ICW SW FW 3) Bohdan.Hunko@infineon.com; Brand Chris (CSS ICW SW) Chris.Brand@infineon.com; nd nd@arm.com Subject: Re: SPM thread and FLIH
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safehttps://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx.
Hi Roman,
Thank you for reporting this issue.
I didn't yet have the time to reproduce the scenario you posted, but looking at the code, here is what I see:
The function tfm_hal_activate_boundary, that is called by tfm_flih_return_to_isr seems to be restoring the privilege level for the active secure partition, regardless of whether unprivileged partition code, or privileged SPM code was executing when the interrupt became active.
The problem seems that with the current logic SPM considers the CONTROL.nPRIV mechanism to be an independent thing from the mechanism that provides isolation between secure partitions. However, it is not true, as the HAL implementations are using this same CONTROL.nPRIV mechanism to realise isolation.
This should probably be fixed in tfm_flih_return_to_isr, setting CONTROL.nPRIV=0 if the interrupted code was privileged. A getter on this could be added to tfm_svcalls.h.
As you already seem to have the environment on reproducing the issue/testing a potential fix, would you mind creating a patch for this? If not, I can create it myself.
Best Regards,
Mate
________________________________
From: Anton Komlev via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: 19 February 2024 12:58 To: Roman.Mazurak@infineon.commailto:Roman.Mazurak@infineon.com <Roman.Mazurak@infineon.commailto:Roman.Mazurak@infineon.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Cc: Bohdan.Hunko@infineon.commailto:Bohdan.Hunko@infineon.com <Bohdan.Hunko@infineon.commailto:Bohdan.Hunko@infineon.com>; Chris.Brand@infineon.commailto:Chris.Brand@infineon.com <Chris.Brand@infineon.commailto:Chris.Brand@infineon.com> Subject: [TF-M] Re: SPM thread and FLIH
Hi Roman,
Thank you for sharing your findings. Let us check and back with comments.
Thanks and best regards,
Anton
From: Roman.Mazurak--- via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Friday, February 16, 2024 11:20 AM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: Bohdan.Hunko@infineon.commailto:Bohdan.Hunko@infineon.com; Chris.Brand@infineon.commailto:Chris.Brand@infineon.com Subject: [TF-M] SPM thread and FLIH
Hi all,
It seems that on v2.0 there is a problem with FLIH handling during execution of SPM thread.
1. A partition #1 is running with unprivileged attribute (CONTROL.nPRIV = 1). 2. It requests PSA API (for example psa_call). 3. psa_call is serviced via SVC. prepare_to_thread_mode_spm schedules handling of psa_call in SPM thread mode (by prepare_to_thread_mode_spm). 4. prepare_to_thread_mode_spm saves CONTROL to saved_control. Than set CONTROL.nPRIV = 0 (privileged for SPM thread). 5. Exit from SVC starts execution of tfm_spm_client_psa_call in SPM thread (privileged). 6. SPM thread is interrupted by FLIH IRQ. 7. FLIH IRQ handler calls spm_handle_interrupt. 8. spm_handle_interrupt switches boundary to prepare environment for FLIH handler (partition #2) and schedules execution of FLIH handler. 9. FLIH handler is executed. 10. tfm_flih_return_to_isr is called on exit from FLIH handler. It restores boundary of partition #1 and set CONTROL.nPRIV = 1. Than returns to FLIH IRQ handler. 11. FLIH IRQ handler exit to SPM thread that has been interrupted on step #6. 12. SPM thread have no enough permissions, because it’s running with CONTROL.nPRIV equal to 1 (unprivileged). So, processing environment is unprivileged and tfm_spm_client_psa_call fails on accessing restricted resource.
Does my understanding correct? If yes it means that we should fix exit from FLIH to SPM thread.
Regards,
Roman.
Hi Mate,
Thanks for your patch. I'm going to validate it next week and will let you know.
Best regards, Roman.
From: Mate Toth-Pal Mate.Toth-Pal@arm.com Sent: Monday, March 18, 2024 16:23 To: Mazurak Roman (CSS ICW SW FW 3) Roman.Mazurak@infineon.com; tf-m@lists.trustedfirmware.org; Anton Komlev Anton.Komlev@arm.com Cc: Hunko Bohdan (CSS ICW SW FW 3) Bohdan.Hunko@infineon.com; Brand Chris (CSS ICW SW) Chris.Brand@infineon.com; nd nd@arm.com Subject: Re: SPM thread and FLIH
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safehttps://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx.
Hi Roman,
I created a patch that I believe fixes the issue you reported below. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/27308
Review comments on the are welcome.
Best Regards, Mate ________________________________ From: Roman.Mazurak@infineon.commailto:Roman.Mazurak@infineon.com <Roman.Mazurak@infineon.commailto:Roman.Mazurak@infineon.com> Sent: 11 March 2024 11:38 To: Mate Toth-Pal <Mate.Toth-Pal@arm.commailto:Mate.Toth-Pal@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org>; Anton Komlev <Anton.Komlev@arm.commailto:Anton.Komlev@arm.com> Cc: Bohdan.Hunko@infineon.commailto:Bohdan.Hunko@infineon.com <Bohdan.Hunko@infineon.commailto:Bohdan.Hunko@infineon.com>; Chris.Brand@infineon.commailto:Chris.Brand@infineon.com <Chris.Brand@infineon.commailto:Chris.Brand@infineon.com>; nd <nd@arm.commailto:nd@arm.com> Subject: RE: SPM thread and FLIH
Hi Mate,
It would be nice if you will provide a fix for this. Probably you have better idea how to integrate it with SPM.
I will be able to test it on our platform and provide a feedback.
Best Regards,
Roman.
From: Mate Toth-Pal <Mate.Toth-Pal@arm.commailto:Mate.Toth-Pal@arm.com> Sent: Monday, February 19, 2024 17:51 To: Mazurak Roman (CSS ICW SW FW 3) <Roman.Mazurak@infineon.commailto:Roman.Mazurak@infineon.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org; Anton Komlev <Anton.Komlev@arm.commailto:Anton.Komlev@arm.com> Cc: Hunko Bohdan (CSS ICW SW FW 3) <Bohdan.Hunko@infineon.commailto:Bohdan.Hunko@infineon.com>; Brand Chris (CSS ICW SW) <Chris.Brand@infineon.commailto:Chris.Brand@infineon.com>; nd <nd@arm.commailto:nd@arm.com> Subject: Re: SPM thread and FLIH
Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safehttps://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx.
Hi Roman,
Thank you for reporting this issue.
I didn't yet have the time to reproduce the scenario you posted, but looking at the code, here is what I see:
The function tfm_hal_activate_boundary, that is called by tfm_flih_return_to_isr seems to be restoring the privilege level for the active secure partition, regardless of whether unprivileged partition code, or privileged SPM code was executing when the interrupt became active.
The problem seems that with the current logic SPM considers the CONTROL.nPRIV mechanism to be an independent thing from the mechanism that provides isolation between secure partitions. However, it is not true, as the HAL implementations are using this same CONTROL.nPRIV mechanism to realise isolation.
This should probably be fixed in tfm_flih_return_to_isr, setting CONTROL.nPRIV=0 if the interrupted code was privileged. A getter on this could be added to tfm_svcalls.h.
As you already seem to have the environment on reproducing the issue/testing a potential fix, would you mind creating a patch for this? If not, I can create it myself.
Best Regards,
Mate
________________________________
From: Anton Komlev via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: 19 February 2024 12:58 To: Roman.Mazurak@infineon.commailto:Roman.Mazurak@infineon.com <Roman.Mazurak@infineon.commailto:Roman.Mazurak@infineon.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Cc: Bohdan.Hunko@infineon.commailto:Bohdan.Hunko@infineon.com <Bohdan.Hunko@infineon.commailto:Bohdan.Hunko@infineon.com>; Chris.Brand@infineon.commailto:Chris.Brand@infineon.com <Chris.Brand@infineon.commailto:Chris.Brand@infineon.com> Subject: [TF-M] Re: SPM thread and FLIH
Hi Roman,
Thank you for sharing your findings. Let us check and back with comments.
Thanks and best regards,
Anton
From: Roman.Mazurak--- via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> Sent: Friday, February 16, 2024 11:20 AM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: Bohdan.Hunko@infineon.commailto:Bohdan.Hunko@infineon.com; Chris.Brand@infineon.commailto:Chris.Brand@infineon.com Subject: [TF-M] SPM thread and FLIH
Hi all,
It seems that on v2.0 there is a problem with FLIH handling during execution of SPM thread.
1. A partition #1 is running with unprivileged attribute (CONTROL.nPRIV = 1). 2. It requests PSA API (for example psa_call). 3. psa_call is serviced via SVC. prepare_to_thread_mode_spm schedules handling of psa_call in SPM thread mode (by prepare_to_thread_mode_spm). 4. prepare_to_thread_mode_spm saves CONTROL to saved_control. Than set CONTROL.nPRIV = 0 (privileged for SPM thread). 5. Exit from SVC starts execution of tfm_spm_client_psa_call in SPM thread (privileged). 6. SPM thread is interrupted by FLIH IRQ. 7. FLIH IRQ handler calls spm_handle_interrupt. 8. spm_handle_interrupt switches boundary to prepare environment for FLIH handler (partition #2) and schedules execution of FLIH handler. 9. FLIH handler is executed. 10. tfm_flih_return_to_isr is called on exit from FLIH handler. It restores boundary of partition #1 and set CONTROL.nPRIV = 1. Than returns to FLIH IRQ handler. 11. FLIH IRQ handler exit to SPM thread that has been interrupted on step #6. 12. SPM thread have no enough permissions, because it's running with CONTROL.nPRIV equal to 1 (unprivileged). So, processing environment is unprivileged and tfm_spm_client_psa_call fails on accessing restricted resource.
Does my understanding correct? If yes it means that we should fix exit from FLIH to SPM thread.
Regards,
Roman.
tf-m@lists.trustedfirmware.org
-
Anton Komlev -
Mate Toth-Pal -
Roman.Mazurak＠infineon.com