Исправление
sanyo1234,
(текущая версия)
:
Приложения в TZ и сама TOS разрабатываются поставщиком системного софта, а не производителем процессора.
It is possible for a chipmaker to implement ARM TrustZone in a way that restricts developer access to the secure world. Here are a few ways they could do this:
Not provide secure world OS or drivers - The chipmaker would have to provide their own proprietary OS and drivers to run in the secure world. Without these, developers couldn't create and run their own secure world code.
Lock down secure world flash - The chipmaker could configure the secure world flash storage to be read-only or inaccessible to developers. This prevents uploading third-party secure world code.
Disable secure world interfaces - The chipmaker can leave out or disable interfaces like the Secure Monitor that switches between normal and secure world. This would prevent developers from interacting with the secure world entirely.
Restrict secure world debugging - Debugging and test interfaces for the secure world could be disabled or locked down. This hampers developers' ability to view, trace, and test secure world code.
Proprietary tooling - The chipmaker could require proprietary compilers, debuggers, emulators that are needed to build secure world code. Without access to these tools, developers can't create secure world apps.
So by carefully controlling access to secure world resources and interfaces, a chipmaker could in theory enable TrustZone in a way that keeps it isolated for their own use.
There are worries that companies could be compelled to secretly implant backdoors for government access into secure zones.
In general, any closed source secure environment has some level of risk that hidden backdoors could exist.
И какие механизмы для слежки по-твоему предоставляет TZ?
А ты сам не знаешь ? ;)
Исправление
sanyo1234,
:
Приложения в TZ и сама TOS разрабатываются поставщиком системного софта, а не производителем процессора.
it is possible for a chipmaker to implement ARM TrustZone in a way that restricts developer access to the secure world. Here are a few ways they could do this:
Not provide secure world OS or drivers - The chipmaker would have to provide their own proprietary OS and drivers to run in the secure world. Without these, developers couldn't create and run their own secure world code.
Lock down secure world flash - The chipmaker could configure the secure world flash storage to be read-only or inaccessible to developers. This prevents uploading third-party secure world code.
Disable secure world interfaces - The chipmaker can leave out or disable interfaces like the Secure Monitor that switches between normal and secure world. This would prevent developers from interacting with the secure world entirely.
Restrict secure world debugging - Debugging and test interfaces for the secure world could be disabled or locked down. This hampers developers' ability to view, trace, and test secure world code.
Proprietary tooling - The chipmaker could require proprietary compilers, debuggers, emulators that are needed to build secure world code. Without access to these tools, developers can't create secure world apps.
So by carefully controlling access to secure world resources and interfaces, a chipmaker could in theory enable TrustZone in a way that keeps it isolated for their own use.
There are worries that companies could be compelled to secretly implant backdoors for government access into secure zones.
In general, any closed source secure environment has some level of risk that hidden backdoors could exist.
И какие механизмы для слежки по-твоему предоставляет TZ?
А ты сам не знаешь ? ;)
Исправление
sanyo1234,
:
Приложения в TZ и сама TOS разрабатываются поставщиком системного софта, а не производителем процессора.
it is possible for a chipmaker to implement ARM TrustZone in a way that restricts developer access to the secure world. Here are a few ways they could do this:
Not provide secure world OS or drivers - The chipmaker would have to provide their own proprietary OS and drivers to run in the secure world. Without these, developers couldn't create and run their own secure world code.
Lock down secure world flash - The chipmaker could configure the secure world flash storage to be read-only or inaccessible to developers. This prevents uploading third-party secure world code.
Disable secure world interfaces - The chipmaker can leave out or disable interfaces like the Secure Monitor that switches between normal and secure world. This would prevent developers from interacting with the secure world entirely.
Restrict secure world debugging - Debugging and test interfaces for the secure world could be disabled or locked down. This hampers developers' ability to view, trace, and test secure world code.
Proprietary tooling - The chipmaker could require proprietary compilers, debuggers, emulators that are needed to build secure world code. Without access to these tools, developers can't create secure world apps.
So by carefully controlling access to secure world resources and interfaces, a chipmaker could in theory enable TrustZone in a way that keeps it isolated for their own use.
There are worries that companies could be compelled to secretly implant backdoors for government access into secure zones.
In general, any closed source secure environment has some level of risk that hidden backdoors could exist. But there are also disincentives for companies to implant backdoors which could expose them to major backlash or liability if revealed.
И какие механизмы для слежки по-твоему предоставляет TZ?
А ты сам не знаешь ? ;)
Исходная версия
sanyo1234,
:
Приложения в TZ и сама TOS разрабатываются поставщиком системного софта, а не производителем процессора.
it is possible for a chipmaker to implement ARM TrustZone in a way that restricts developer access to the secure world. Here are a few ways they could do this:
Not provide secure world OS or drivers - The chipmaker would have to provide their own proprietary OS and drivers to run in the secure world. Without these, developers couldn't create and run their own secure world code.
Lock down secure world flash - The chipmaker could configure the secure world flash storage to be read-only or inaccessible to developers. This prevents uploading third-party secure world code.
Disable secure world interfaces - The chipmaker can leave out or disable interfaces like the Secure Monitor that switches between normal and secure world. This would prevent developers from interacting with the secure world entirely.
Restrict secure world debugging - Debugging and test interfaces for the secure world could be disabled or locked down. This hampers developers' ability to view, trace, and test secure world code.
Proprietary tooling - The chipmaker could require proprietary compilers, debuggers, emulators that are needed to build secure world code. Without access to these tools, developers can't create secure world apps.
So by carefully controlling access to secure world resources and interfaces, a chipmaker could in theory enable TrustZone in a way that keeps it isolated for their own use.
И какие механизмы для слежки по-твоему предоставляет TZ?
А ты сам не знаешь ? ;)