i.MX8 Coredump Required Key Not Available When do coredump

[liangzhang1]

Hi NXP,

Before we get started, please let me explain a little bit background. 

What we do?

We plan to introduce core dump service for the i.IM8 powered In-vehicle infotainment OS, which the upper layer OS is also powered by Android. The core dumper service is used to catch and generate `core` file for each running process unit. (not full ram dump, or kdump). The 'core_pattern' device node is used to setup the core file dumping pipeline.  For instance the nativedumper is trying to read core contents from pipe, first it should create file in local storage.

    write /proc/sys/kernel/core_pattern "|/system/bin/nativedumper %p %s %u %g"

What we expect to see?

However, when we trigger a segment fault crash in a running native process, i.e healthd. A `Required Key Not Available` error, also called ENOKEY return. After we googled around the internet, no significantly finding but some concept related to `Kernel keyring management` and key request system call stuffs. I'm not sure if it is right place to post our questions, i would appreciated if you could share  the same experience in catching `core` file in user-space. And how to git rid of `ENOKEY` break in core dump pipeline program. Thank you!

  I /system/bin/nativedumper: Total bytes in core dump: 4927488: Required key not available 

[Zhiming_Liu]

Hi

Did your os is trusty?

The write operation is encryption in trusty os.

You can see screenshot in attached file.

BR

[liangzhang1]

Really appreciated your resource sharing!

I guess we didn't introduce Trusty OS for our products as far as i know. Besides, there is very interesting findings in eMMC RPMB partition. eMMC RPMB: RPMB is a separate physical partition in the eMMC device designed for secure data storage. Every access to RPMB is authenticated and it allows the host to store data to this area in an authenticated and replay protected manner. and in Trusty OS, the RPMB partition is managed as the secure storage to store all critical data like lock/unlock status, rollback index, etc. 

In our case, the core file should be redirecting/writing to general resource-oriented partition, for instance, `/sdcard/CrashDump` or `/data/media/0/CrashDump`. I'm not sure if the Trusty OS security mechanism as you mentioned in doc, is also applied and working-as-design probably, finally block the write behavior from the `nativedumper` program. However, since the error messages shows that something abnormal in Key validation. I guess this is what a Security team know more details. 

[Zhiming_Liu]

Hi

You can post the same content in aosp community.I will give you answer after i ask my college in security.

BR

[liangzhang1]

Thanks.

The same message is under constructing and will be post in AOSP Community, we prefer to Google Group - Android-Porting. See android-porting - Google Groups. The new conversation in android-porting will be available soon.