Hi,
I tried to build the Qt Virtualkeyboard example. I adapted the target.mk of the calculatorform example to point to the correct project file. Make fails at the project file at line 6 with missing separator. This part contains the following:
static { QT += svg QTPLUGIN += qtvirtualkeyboardplugin }
Is there an additional flag required? Manually running qmake && make works fine.
Regards, JK
Hi Johannes,
On 26.07.2017 14:42, Johannes Kliemann wrote:
Hi,
I tried to build the Qt Virtualkeyboard example. I adapted the target.mk of the calculatorform example to point to the correct project file. Make fails at the project file at line 6 with missing separator. This part contains the following:
static { QT += svg QTPLUGIN += qtvirtualkeyboardplugin }
Is there an additional flag required? Manually running qmake && make works fine.
the Genode build system does not run qmake, but includes the qmake project file as if it were a Makefile. This works well for simple project files, but if the project file uses qmake-specific syntax and these parts are relevant, they must be replaced with something that GNU make understands. In your case it would probably suffice to just delete the 'static {' line and the '}' line.
The 'QT' variable gets evaluated in [1] and there's no svg support right now. A port of the Qt5Svg library would include the following new files:
- repos/libports/lib/import/import-qt5_svg.mk - repos/libports/lib/mk/qt5_svg.mk - repos/libports/lib/mk/qt5_svg_generated.inc
The 'QTPLUGIN' variable does not get evaluated in the 'target_final.inc' file right now. To do that, I think you would need to add each part of the variable content to the LIBS variable (prefixed with 'qt5_'), resulting in 'LIBS += qt5_qtvirtualkeyboardplugin' in your case, and then build the plugin as a shared library, similar to the 'qt5_qjpeg' library.
I've attached the generated include files and a patch with the script used to generate the files, in case you need to change the configuration and regenerate them.
Regards, Christian
[1] https://github.com/genodelabs/genode/blob/master/repos/libports/src/app/qt5/...
Hi Christian,
thanks for your help, I was able to build the virtualkeyboard example for Genode [1].
Currently it fails run due to missing QtQuick dependencies. Beside that some called functions are not yet implemented but I think the missing dependencies make it fail in the first place.
[init -> basic] Warning: geteuid: geteuid not implemented [init -> basic] Warning: getuid: getuid not implemented [init -> basic] read_rtc: rtc not configured, returning 0 [init -> basic] Warning: getpid: getpid not implemented [init -> basic] read_rtc: rtc not configured, returning 0 [init -> basic] JIT is disabled for QML. Property bindings and animations will be very slow. Visit https://wiki.qt.io/V4 to learn about possible solutions for your platform. [init -> basic] Error: no plugin found for mmap(-1) [init -> basic] Warning: mmap not supported for file descriptor -1 [init -> basic] Error: no plugin found for mmap(-1) [init -> basic] Warning: mmap not supported for file descriptor -1 [init -> basic] Warning: issetugid called, not yet implemented, returning 1 [init -> basic] Warning: issetugid called, not yet implemented, returning 1 [init -> basic] Warning: issetugid called, not yet implemented, returning 1 [init -> basic] Warning: issetugid called, not yet implemented, returning 1 [init -> basic] qrc:/Basic.qml:30:1: module "QtQuick" is not installed [init -> basic] qrc:/Basic.qml:31:1: module "QtQuick.VirtualKeyboard" is not installed [init -> basic] qrc:/Basic.qml:30:1: module "QtQuick" is not installed [init -> basic] qrc:/Basic.qml:31:1: module "QtQuick.VirtualKeyboard" is not installed [init -> basic] QThread: Destroyed while thread is still running [init -> basic] Warning: getpid: getpid not implemented [init -> basic] Warning: kill: kill not implemented [init -> basic] Warning: _sigaction: _sigaction not implemented [init -> basic] Warning: getpid: getpid not implemented [init -> basic] Warning: kill: kill not implemented [init -> basic] Warning: 4 dangling allocations at allocator destruction time [init -> basic] Warning: 10 dangling allocations at allocator destruction time [init] child "basic" exited with exit value 1
How can I add QtQuick dependencies on Genode, is there already some code example?
Thanks and regards,
Johannes
[1]: https://github.com/jklmnn/genode/tree/qt_virtualkeyboard
Am 27.07.2017 um 00:18 schrieb Christian Prochaska:
Hi Johannes,
On 26.07.2017 14:42, Johannes Kliemann wrote:
Hi,
I tried to build the Qt Virtualkeyboard example. I adapted the target.mk of the calculatorform example to point to the correct project file. Make fails at the project file at line 6 with missing separator. This part contains the following:
static { QT += svg QTPLUGIN += qtvirtualkeyboardplugin }
Is there an additional flag required? Manually running qmake && make works fine.
the Genode build system does not run qmake, but includes the qmake project file as if it were a Makefile. This works well for simple project files, but if the project file uses qmake-specific syntax and these parts are relevant, they must be replaced with something that GNU make understands. In your case it would probably suffice to just delete the 'static {' line and the '}' line.
The 'QT' variable gets evaluated in [1] and there's no svg support right now. A port of the Qt5Svg library would include the following new files:
- repos/libports/lib/import/import-qt5_svg.mk
- repos/libports/lib/mk/qt5_svg.mk
- repos/libports/lib/mk/qt5_svg_generated.inc
The 'QTPLUGIN' variable does not get evaluated in the 'target_final.inc' file right now. To do that, I think you would need to add each part of the variable content to the LIBS variable (prefixed with 'qt5_'), resulting in 'LIBS += qt5_qtvirtualkeyboardplugin' in your case, and then build the plugin as a shared library, similar to the 'qt5_qjpeg' library.
I've attached the generated include files and a patch with the script used to generate the files, in case you need to change the configuration and regenerate them.
Regards, Christian
[1] https://github.com/genodelabs/genode/blob/master/repos/libports/src/app/qt5/...
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Thanks!
I added the QtQuick dependencies and created build files for the QtQuick VirtualKeyboard. Currently it fails to build with
In file included from ../../../../../contrib/qt5-bd7410b31ae57d778d9da6599c0a4e887fa44fa8/src/lib/qt5/qt-everywhere-opensource-src-5.8.0/qtvirtualkeyboard/src/virtualkeyboard/plugin.h:33:0, from moc_plugin.cpp:9: /media/jkliemann/40f41e9a-0a52-48f2-8434-36a2711b6c79/componolit/genode/contrib/qt5-bd7410b31ae57d778d9da6599c0a4e887fa44fa8/src/lib/qt5/qt-everywhere-opensource-src-5.8.0/qtdeclarative/include/QtQml/QtQml:3:30: fatal error: QtQml/QtQmlDepends: Datei oder Verzeichnis nicht gefunden #include <QtQml/QtQmlDepends>
This file seems to be autogenerated by the MOC but I cannot see what causes it to fail.
Do you have any idea?
Thanks and regards,
Johannes
Am 27.07.2017 um 14:02 schrieb Christian Prochaska:
Hi Johannes,
On 27.07.2017 13:50, Johannes Kliemann wrote:
How can I add QtQuick dependencies on Genode, is there already some code example?
there are two QtQuick examples in the libports repository: qt5_quicktest.run and qt5_samegame.run.
Regards, Christian
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Johannes,
On 27.07.2017 16:52, Johannes Kliemann wrote:
Thanks!
I added the QtQuick dependencies and created build files for the QtQuick VirtualKeyboard. Currently it fails to build with
In file included from ../../../../../contrib/qt5-bd7410b31ae57d778d9da6599c0a4e887fa44fa8/src/lib/qt5/qt-everywhere-opensource-src-5.8.0/qtvirtualkeyboard/src/virtualkeyboard/plugin.h:33:0, from moc_plugin.cpp:9: /media/jkliemann/40f41e9a-0a52-48f2-8434-36a2711b6c79/componolit/genode/contrib/qt5-bd7410b31ae57d778d9da6599c0a4e887fa44fa8/src/lib/qt5/qt-everywhere-opensource-src-5.8.0/qtdeclarative/include/QtQml/QtQml:3:30: fatal error: QtQml/QtQmlDepends: Datei oder Verzeichnis nicht gefunden #include <QtQml/QtQmlDepends>
This file seems to be autogenerated by the MOC but I cannot see what causes it to fail.
These dependency header files are generated together with the 'qt5_*_generated.inc' files and need to be patched into the source tree when preparing the port. For some reason they are currently missing in the patch for the 'qtdeclarative' module. I've added them in [1], together with the QtSvgDepends header file.
[1] https://github.com/cproc/genode/commit/12d865a742fbd4b55879a48dcefcacdc59ade...
Regards, Christian
Hi Christian,
after applying your commit and fixing the vpaths for the plugin directory it compiles but it still fails to find the qtvirtualkeyboardplugin.
qrc:/Basic.qml:31:1: module "QtQuick.VirtualKeyboard" is not installed
I can't find the problem at this point. The tar archive seems to be complete and the QtQuick2 plugin which also is in the archive is found correctly.
./qt/qml/ ./qt/qml/QtQuick.2/ ./qt/qml/QtQuick.2/qt5_qtquick2plugin.lib.so ./qt/qml/QtQuick.2/qmldir ./qt/qml/QtQuick.VirtualKeyboard/ ./qt/qml/QtQuick.VirtualKeyboard/qt5_qtvirtualkeyboardplugin.lib.so ./qt/qml/QtQuick.VirtualKeyboard/qmldir ./qt/qml/QtQuick.VirtualKeyboard.2/ ./qt/qml/QtQuick.VirtualKeyboard.2/qt5_qtvirtualkeyboardplugin.lib.so ./qt/qml/QtQuick.VirtualKeyboard.2/qmldir
(I tried both variants of the virtual keyboard directory but none of the worked.) My current state is under [1].
Thanks and regards, Johannes
[1]: https://github.com/jklmnn/genode/commit/ae3425c0ff2bbab0502f4216af8f89b17228...
Am 28.07.2017 um 13:26 schrieb Christian Prochaska:
Hi Johannes,
On 27.07.2017 16:52, Johannes Kliemann wrote:
Thanks!
I added the QtQuick dependencies and created build files for the QtQuick VirtualKeyboard. Currently it fails to build with
In file included from ../../../../../contrib/qt5-bd7410b31ae57d778d9da6599c0a4e887fa44fa8/src/lib/qt5/qt-everywhere-opensource-src-5.8.0/qtvirtualkeyboard/src/virtualkeyboard/plugin.h:33:0, from moc_plugin.cpp:9: /media/jkliemann/40f41e9a-0a52-48f2-8434-36a2711b6c79/componolit/genode/contrib/qt5-bd7410b31ae57d778d9da6599c0a4e887fa44fa8/src/lib/qt5/qt-everywhere-opensource-src-5.8.0/qtdeclarative/include/QtQml/QtQml:3:30: fatal error: QtQml/QtQmlDepends: Datei oder Verzeichnis nicht gefunden #include <QtQml/QtQmlDepends>
This file seems to be autogenerated by the MOC but I cannot see what causes it to fail.
These dependency header files are generated together with the 'qt5_*_generated.inc' files and need to be patched into the source tree when preparing the port. For some reason they are currently missing in the patch for the 'qtdeclarative' module. I've added them in [1], together with the QtSvgDepends header file.
[1] https://github.com/cproc/genode/commit/12d865a742fbd4b55879a48dcefcacdc59ade...
Regards, Christian
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Johannes,
On 31.07.2017 15:20, Johannes Kliemann wrote:
after applying your commit and fixing the vpaths for the plugin directory it compiles but it still fails to find the qtvirtualkeyboardplugin.
from looking at what gets built and installed with Qt for Linux, it seems there are actually multiple plugins involved that need to be ported to Genode: one Qt plugin (the one you ported) and multiple QtQuick plugins (QtQuick.Layouts, QtQuick.Virtualkeyboard.Styles, Qt.labs.folderlistmodel). The layout of the 'qml' directory must probably match the one on Linux (/usr/local/Qt-5.8.0/qml), with a 'qmldir' file in each sub directory, for the QtQuick plugins to be found. The Qt plugin was installed at '/usr/local/Qt-5.8.0/plugins/platforminputcontexts/libqtvirtualkeyboardplugin.so' on Linux, but I'm not sure if our Qt port can load non-QtQuick plugins with 'dlopen()' yet, so I would first try to use it as a static plugin, like it is done with the qjpeg plugin. This usually means adding an extra file to register the plugin at program start (see 'repos/libports/src/lib/qt5/qtbase/src/plugins/imageformats/jpeg/import_plugin.cc').
Regards, Christian
Hi, We have built a trap and emulation secure world application based on the genode tz_vmm demo, to run on the IMX53 QSB and Sabre Tablet. This allows us to handle applications like reliably turning on/off some peripherals. E.g. for Bluetooth radio, we make GPIO 3/4 secure in CSU. When Android tries to turn on Bluetooth, we get an external data abort in secure world for which we do nothing and give back control. Android gives up after a few retries. For other peripherals that use GPIO 3/4 and therefore share the CSU setting, we also get the external abort, but we emulate the instruction in secure world before giving back control to linux.
The current secure world has 27539 LOC. The baseline can be https://athena.smu.edu.sg/mobisys/backend/mobisys/assets/paper_list/pdf_vers..., which also turned on/off peripherals, rewriting normal world device drivers from secure world. It has only about 4K LoC in TCB (section 6 para 2 and 3).
Looking at the .d files in hw_imx53 with sloc, we get the following break-down. The bulk of the code is coming from genode OS framework. The question I have is: does the tz_vmm demo minimally use genode components? If yes, then maybe this is the best TCB size we can expect? If not, then what are some parts that can be cut down?
Thanks! Riju
Secure world user space component tz_vmm (~3.5K LoC) (1) loads and monitors the normal world linux in original genode demo, we added our instruction emulation code here - 1353 LoC (2) ARM instruction decoding library DARM - 2070 LoC
Hardware related files (~2.5K LoC) (1) for ARM, ARM_V7, ARM CORTEX_A8, IMX, IMX53, TRUSTZONE, CSU - 2316 LoC
Genode OS: (~19K LoC) http://genode.org/documentation/general-overview/index https://genode.org/documentation/api/base_index (1) C/C++ standard library functions, data structures, other programming utitlies - 2634 LoC (2) Memory allocation and management - 2710 LoC (3) Device access - 707 LoC (4) Thread and synchronization - 1768 LoC (5) CPU - 1286 LoC (6) Debugging - 1248 LoC (7) Inter-Process Communication - 2595 LoC (8) Client server framework - 406 LoC (9) Other stuff ....
Hello Riju,
The current secure world has 27539 LOC. The baseline can be https://athena.smu.edu.sg/mobisys/backend/mobisys/assets/paper_list/pdf_vers..., which also turned on/off peripherals, rewriting normal world device drivers from secure world. It has only about 4K LoC in TCB (section 6 para 2 and 3)> ... Looking at the .d files in hw_imx53 with sloc, we get the following break-down. The bulk of the code is coming from genode OS framework. The question I have is: does the tz_vmm demo minimally use genode components? If yes, then maybe this is the best TCB size we can expect? If not, then what are some parts that can be cut down?
The number of 27 KLOC is plausible. It may be possible to shave off some lines here and there. But this won't change the order of magnitude. As a reference for the complexity of a modern stand-alone microkernel, please consider the examples of seL4 or NOVA. Each has over 10 KLOC of code without including any user-level infrastructure.
I'd rather question the value of having components in the first place in your scenario. If your secure world consists of trusted components only and has a static feature set, what is the value of componentization? If there is no untrusted code in the secure world, the microkernel approach adds costs but no benefits. If so, one way to significantly reduce the complexity of your current implementation would be to co-locate the tz_vmm, init, and other custom components with Genode's core. This approach comes down to using Genode as a mere API, not as an OS. E.g., the interaction between components would become mere function calls.
The downside is two-fold: First, the forked implementation deviates from the regular Genode OS Framework, which implies development effort and ongoing maintenance costs. Second, it eliminates the modularity and scalability that the Genode OS Framework gives you.
As soon as 3rd-party device drivers, parsing code, or other forms of untrusted code enters the picture of the secure world, the microkernel approach (e.g., the use of Genode) becomes beneficial. Here the static TCB overhead of around 20 KLOC of the fundamental OS infrastructure (microkernel and the low-level user-land code) must be accepted, or alleviated by the means of formal verification as done by the seL4 project.
Cheers Norman
Hi Christian,
I tried to build the plugin statically but that seems to depend on static builds of its dependencies (which wouldn't be a big problem) and the QtQuick2 plugin itself.
I recreated the directory structure from Linux (qml/QtQuick/VirtualKeyboard/qmldir) but it still fails to find the plugin. Even if dynamically loading it is a problem, shouldn't Qt find the plugin first and then fail to load it?
Regards, Johannes
Am 02.08.2017 um 19:27 schrieb Christian Prochaska:
Hi Johannes,
On 31.07.2017 15:20, Johannes Kliemann wrote:
after applying your commit and fixing the vpaths for the plugin directory it compiles but it still fails to find the qtvirtualkeyboardplugin.
from looking at what gets built and installed with Qt for Linux, it seems there are actually multiple plugins involved that need to be ported to Genode: one Qt plugin (the one you ported) and multiple QtQuick plugins (QtQuick.Layouts, QtQuick.Virtualkeyboard.Styles, Qt.labs.folderlistmodel). The layout of the 'qml' directory must probably match the one on Linux (/usr/local/Qt-5.8.0/qml), with a 'qmldir' file in each sub directory, for the QtQuick plugins to be found. The Qt plugin was installed at '/usr/local/Qt-5.8.0/plugins/platforminputcontexts/libqtvirtualkeyboardplugin.so' on Linux, but I'm not sure if our Qt port can load non-QtQuick plugins with 'dlopen()' yet, so I would first try to use it as a static plugin, like it is done with the qjpeg plugin. This usually means adding an extra file to register the plugin at program start (see 'repos/libports/src/lib/qt5/qtbase/src/plugins/imageformats/jpeg/import_plugin.cc').
Regards, Christian
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Christian,
I finally got the plugin to load. What was missing was the correct initialization in QNitpickerIntegration. I have added the missing parts to load the QPlatformInputContext [1] and it now finds the qtvirtualkeyboardplugin.
It isn't completely working yet but at least the application shows up. What is missing are the dependencies. They require additional shared libs. I tried to create the according make fragments with your script but after applying qtbase_generated.patch the configure script fails to generate qmake with
You cannot make a shadow build from a source tree containing a previous build.
on a clean (except that patch) source tree. Do you have any idea about that?
Regards, Johannes
[1]: https://github.com/jklmnn/genode/commit/676df58996fe0f9958da49116ee5317edb82...
Am 09.08.2017 um 09:58 schrieb Johannes Kliemann:
Hi Christian,
I tried to build the plugin statically but that seems to depend on static builds of its dependencies (which wouldn't be a big problem) and the QtQuick2 plugin itself.
I recreated the directory structure from Linux (qml/QtQuick/VirtualKeyboard/qmldir) but it still fails to find the plugin. Even if dynamically loading it is a problem, shouldn't Qt find the plugin first and then fail to load it?
Regards, Johannes
Am 02.08.2017 um 19:27 schrieb Christian Prochaska:
Hi Johannes,
On 31.07.2017 15:20, Johannes Kliemann wrote:
after applying your commit and fixing the vpaths for the plugin directory it compiles but it still fails to find the qtvirtualkeyboardplugin.
from looking at what gets built and installed with Qt for Linux, it seems there are actually multiple plugins involved that need to be ported to Genode: one Qt plugin (the one you ported) and multiple QtQuick plugins (QtQuick.Layouts, QtQuick.Virtualkeyboard.Styles, Qt.labs.folderlistmodel). The layout of the 'qml' directory must probably match the one on Linux (/usr/local/Qt-5.8.0/qml), with a 'qmldir' file in each sub directory, for the QtQuick plugins to be found. The Qt plugin was installed at '/usr/local/Qt-5.8.0/plugins/platforminputcontexts/libqtvirtualkeyboardplugin.so' on Linux, but I'm not sure if our Qt port can load non-QtQuick plugins with 'dlopen()' yet, so I would first try to use it as a static plugin, like it is done with the qjpeg plugin. This usually means adding an extra file to register the plugin at program start (see 'repos/libports/src/lib/qt5/qtbase/src/plugins/imageformats/jpeg/import_plugin.cc').
Regards, Christian
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Johannes,
On 14.08.2017 16:03, Johannes Kliemann wrote:
I finally got the plugin to load. What was missing was the correct initialization in QNitpickerIntegration. I have added the missing parts to load the QPlatformInputContext [1] and it now finds the qtvirtualkeyboardplugin.
good to hear that!
It isn't completely working yet but at least the application shows up. What is missing are the dependencies. They require additional shared libs. I tried to create the according make fragments with your script but after applying qtbase_generated.patch the configure script fails to generate qmake with
You cannot make a shadow build from a source tree containing a previous build.
on a clean (except that patch) source tree. Do you have any idea about that?
Did you apply the 'qt5_create_generated_incs_with_preparation.patch' from a previous mail? The patch reordered the 'series' file, so that only the following Qt patches would be applied before the Qt configuration step:
qtbase_configuration.patch qtdeclarative_configuration.patch qttools_configuration.patch qtwebkit_fixes.patch qtwebkit_configuration.patch
Regards, Christian
Thanks, that worked. I forgot to use the whole patch when I tried to run it out of tree on a separate machine.
Regards, Johannes
Am 14.08.2017 um 16:40 schrieb Christian Prochaska:
Hi Johannes,
On 14.08.2017 16:03, Johannes Kliemann wrote:
I finally got the plugin to load. What was missing was the correct initialization in QNitpickerIntegration. I have added the missing parts to load the QPlatformInputContext [1] and it now finds the qtvirtualkeyboardplugin.
good to hear that!
It isn't completely working yet but at least the application shows up. What is missing are the dependencies. They require additional shared libs. I tried to create the according make fragments with your script but after applying qtbase_generated.patch the configure script fails to generate qmake with
You cannot make a shadow build from a source tree containing a previous build.
on a clean (except that patch) source tree. Do you have any idea about that?
Did you apply the 'qt5_create_generated_incs_with_preparation.patch' from a previous mail? The patch reordered the 'series' file, so that only the following Qt patches would be applied before the Qt configuration step:
qtbase_configuration.patch qtdeclarative_configuration.patch qttools_configuration.patch qtwebkit_fixes.patch qtwebkit_configuration.patch
Regards, Christian
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi,
On 08/04/2017 09:52 AM, rijurekha@...71... wrote:
Hi, We have built a trap and emulation secure world application based on the genode tz_vmm demo, to run on the IMX53 QSB and Sabre Tablet. This allows us to handle applications like reliably turning on/off some peripherals. E.g. for Bluetooth radio, we make GPIO 3/4 secure in CSU. When Android tries to turn on Bluetooth, we get an external data abort in secure world for which we do nothing and give back control. Android gives up after a few retries. For other peripherals that use GPIO 3/4 and therefore share the CSU setting, we also get the external abort, but we emulate the instruction in secure world before giving back control to linux.
The current secure world has 27539 LOC. The baseline can be https://athena.smu.edu.sg/mobisys/backend/mobisys/assets/paper_list/pdf_vers..., which also turned on/off peripherals, rewriting normal world device drivers from secure world. It has only about 4K LoC in TCB (section 6 para 2 and 3).
Looking at the .d files in hw_imx53 with sloc, we get the following break-down. The bulk of the code is coming from genode OS framework. The question I have is: does the tz_vmm demo minimally use genode components? If yes, then maybe this is the best TCB size we can expect? If not, then what are some parts that can be cut down?
I would say: yes our example "tz_vmm" uses a minimal set of the Genode OS framework. When comparing a statical setup for a very-specific use case (thereby probably linking everything together without anything in between) with a component-based OS like Genode, running drivers in separate components, with the ability of quite dynamic processing, then surely the static setup will always win in terms of LOC count. But adding 19K LOC for the possibility to easily extend your setup and to separate components from each other does not seem to be much overhead in my eyes.
Regards Stefan
Thanks! Riju
Secure world user space component tz_vmm (~3.5K LoC) (1) loads and monitors the normal world linux in original genode demo, we added our instruction emulation code here - 1353 LoC (2) ARM instruction decoding library DARM - 2070 LoC
Hardware related files (~2.5K LoC) (1) for ARM, ARM_V7, ARM CORTEX_A8, IMX, IMX53, TRUSTZONE, CSU - 2316 LoC
Genode OS: (~19K LoC) http://genode.org/documentation/general-overview/index https://genode.org/documentation/api/base_index (1) C/C++ standard library functions, data structures, other programming utitlies - 2634 LoC (2) Memory allocation and management - 2710 LoC (3) Device access - 707 LoC (4) Thread and synchronization - 1768 LoC (5) CPU - 1286 LoC (6) Debugging - 1248 LoC (7) Inter-Process Communication - 2595 LoC (8) Client server framework - 406 LoC (9) Other stuff ....
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
sorry for the duplicate. My mail client sort the last mails strangely, therefore I did not saw that Norman already answered to you in-depth.
On 08/28/2017 10:44 AM, Stefan Kalkowski wrote:
Hi,
On 08/04/2017 09:52 AM, rijurekha@...71... wrote:
Hi, We have built a trap and emulation secure world application based on the genode tz_vmm demo, to run on the IMX53 QSB and Sabre Tablet. This allows us to handle applications like reliably turning on/off some peripherals. E.g. for Bluetooth radio, we make GPIO 3/4 secure in CSU. When Android tries to turn on Bluetooth, we get an external data abort in secure world for which we do nothing and give back control. Android gives up after a few retries. For other peripherals that use GPIO 3/4 and therefore share the CSU setting, we also get the external abort, but we emulate the instruction in secure world before giving back control to linux.
The current secure world has 27539 LOC. The baseline can be https://athena.smu.edu.sg/mobisys/backend/mobisys/assets/paper_list/pdf_vers..., which also turned on/off peripherals, rewriting normal world device drivers from secure world. It has only about 4K LoC in TCB (section 6 para 2 and 3).
Looking at the .d files in hw_imx53 with sloc, we get the following break-down. The bulk of the code is coming from genode OS framework. The question I have is: does the tz_vmm demo minimally use genode components? If yes, then maybe this is the best TCB size we can expect? If not, then what are some parts that can be cut down?
I would say: yes our example "tz_vmm" uses a minimal set of the Genode OS framework. When comparing a statical setup for a very-specific use case (thereby probably linking everything together without anything in between) with a component-based OS like Genode, running drivers in separate components, with the ability of quite dynamic processing, then surely the static setup will always win in terms of LOC count. But adding 19K LOC for the possibility to easily extend your setup and to separate components from each other does not seem to be much overhead in my eyes.
Regards Stefan
Thanks! Riju
Secure world user space component tz_vmm (~3.5K LoC) (1) loads and monitors the normal world linux in original genode demo, we added our instruction emulation code here - 1353 LoC (2) ARM instruction decoding library DARM - 2070 LoC
Hardware related files (~2.5K LoC) (1) for ARM, ARM_V7, ARM CORTEX_A8, IMX, IMX53, TRUSTZONE, CSU - 2316 LoC
Genode OS: (~19K LoC) http://genode.org/documentation/general-overview/index https://genode.org/documentation/api/base_index (1) C/C++ standard library functions, data structures, other programming utitlies - 2634 LoC (2) Memory allocation and management - 2710 LoC (3) Device access - 707 LoC (4) Thread and synchronization - 1768 LoC (5) CPU - 1286 LoC (6) Debugging - 1248 LoC (7) Inter-Process Communication - 2595 LoC (8) Client server framework - 406 LoC (9) Other stuff ....
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
-
unknown＠example.com -
Christian Prochaska -
Johannes Kliemann -
Norman Feske -
Stefan Kalkowski