Share a variable of Core with other components

Jaemin Park jmpark81 at ...9...
Mon Feb 5 01:59:16 CET 2018


Hi,

I attempted to implement a read-only method to share a variable of Core.

My attempt showed me an error as follows:
Error: init -> tz_vmm ->  ep: raised unhandled data abort DFSR=0x1008
ISFR=0x7 DFAR=0xc000 ip=0x70010c40 sp=0xe02fef00

My implementation is as follows(blue-colored parts):

1) Core(repos/base/src/core/main.cc)

static unsigned char core_data[32]; /* data I'd like to share */

int main()
{
          ...
          Pd_connection init_pd("init");
          Core_child *init = new (env()->heap())
            Core_child(Rom_session_client(init_rom_session_cap).dataspace(),
                        init_pd, init_ram_session_cap, init_cpu.cap(),
                        local_services);

         /* allocate dataspace used for creating shared memory between core
and init */
342     Dataspace_capability ds = env()->ram_session()->alloc(4096);
343     void* local_addr = env()->rm_session()->attach(ds);
344     Genode::printf("local_addr=0x%p\n", local_addr);
345     Genode::memcpy((void*)local_addr, (const void*) core_data, 32);
346
347     /* add to ROM FS */
348     Rom_module *rom_module = new (platform()->core_mem_alloc())
349         Rom_module((addr_t)local_addr, 4096, "core_data");
350     platform()->rom_fs()->insert(rom_module);
351
          platform()->wait_for_exit();
          ...
}

2) tz_vmm(repos/os/src/server/tz_vmm/spec/imx53/main.cc)

int main()
{
149     /* obtain core_data */
150     Dataspace_capability ds;
151     try{
152         static Genode::Rom_connection rom("core_data");
153         ds = rom.dataspace();
154     }catch(...){
155         error("ROM module \"core_data\" not present");}
156
157     void* core_data =
158         (void*) Genode::env()->rm_session()->attach(ds);
159     Genode::size_t size = Genode::Dataspace_client(ds).size();
160     static unsigned char local_data[32];
161     Genode::memcpy((void*)local_data, (const void*)core_data, size);
/* data abort happens here */
162     Genode::env()->rm_session()->detach(measurement);

           static Vm vm("linux", cmdline_tablet,
                     Trustzone::NONSECURE_RAM_BASE,
Trustzone::NONSECURE_RAM_SIZE,
                     KERNEL_OFFSET, MACH_TYPE_QSB);
         static Vmm::Vmm vmm(&vm);
         ...
}

Is there any comment on my implementation?
Any comment comments would be highly appreciated.

JaeminPark


On Fri, Feb 2, 2018 at 9:49 PM, Jaemin Park <jmpark81 at ...9...> wrote:

> Hi,
>
> I really appreciate your kind and quick response.
>
> In my case, a one-way read-only fashion is enough.
> I'd like to share an information that other components can read only.
>
> If you can give me an example or any reference code published in the git
> repository, please let me know.
>
> Sorry for a newbie's request.
>
> JaeminPark
>
> On Fri, Feb 2, 2018 at 6:27 PM, Stefan Kalkowski <
> stefan.kalkowski at ...1...> wrote:
>
>> Hi Jaemin,
>>
>> On Fri, Feb 02, 2018 at 11:28:53AM +0900, Jaemin Park wrote:
>> > Hi,
>> >
>> > I'd like to ask a question about a way to "share a variable of Core with
>> > other components".
>> >
>> > I'm using i.MX53 QSB, so this question is based on 'base-hw'
>> implementation.
>> >
>> > Suppose that 'Core' has a variable "A" and makes it visible to other
>> > components like 'Init' or else.
>> >
>> > For this, I added a routine to use a Dataspace_capability for "A" in
>> main()
>> > of 'Core' as follows:
>> > *[repos/base/src/core/main.cc]*
>> > *Dataspace_capability ds = env()->ram_session()->alloc(4096);*
>> > *unsigned char *local_addr = env()->rm_session()->attach(ds);*
>> >
>> > However, I faced a difficulty to implement an RPC to delegate(share) the
>> > Dataspace_capability to other components.
>> >
>> > Is there any simple or proper way to share "A" of 'Core' with other
>> > components?
>> > If possible, please give me an example.
>>
>> Well, in general there are only few examples where core 'shares'
>> memory with other components. Due to core being the security critical
>> kernel component, it is a bad idea to widen the interface to it too
>> much. Apart from this disclaimer, there are some information needed to
>> be exported from core to specific components, e.g., platform
>> information like ACPI etc. from the booting infrastructure exported to
>> the platform driver. Those information are shared in a one-way
>> read-only fashion. Therefore, it is enough to create a dataspace
>> within core, and export it as a ROM module using a dedicated name for
>> it. The user-level component can open that dataspace using the normal
>> ROM session interface of core.
>>
>> If you want to share information bi-directional this approach
>> obviously is no way. On the other hand it is not recommended at all to
>> import data into the kernel beyond the existing system calls.
>> An exception is the VM session interface of base-hw's core, which
>> exports a dataspace to the VMM component used to reflect the machine
>> register set of the VM under control of the VMM. Those register
>> contents can be altered by the VMM, e.g., after doing some device
>> emulation, and is taken by the kernel to reload the registers when
>> switching to the VM again. Of course, when sharing data in such a way
>> both sides need to synchronize before accessing the shared data.
>> Because core/kernel cannot block on any user-level component, signals
>> are used to hint the VMM about a change of the VM state, whereby the
>> VMM calls core via IPC (VM session interface) to mark that the VM
>> state handling has finished, and the VM is re-runnable.
>>
>> I hope this clarifies your question. If not you may explain your
>> use-case in more details.
>>
>> Best regards
>> Stefan
>>
>> >
>> > Any comment comments would be highly appreciated.
>> >
>> > JaeminPark
>>
>> > ------------------------------------------------------------
>> ------------------
>> > 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 at lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/genode-main
>>
>>
>> --
>> Stefan Kalkowski
>> Genode labs
>>
>> https://github.com.skalk | https://genode.org
>>
>> ------------------------------------------------------------
>> ------------------
>> 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 at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/genode-main
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20180205/77104f77/attachment.html>


More information about the users mailing list