Signature for .cell files

13 views
Skip to first unread message

Ralf Ramsauer

unread,
Aug 12, 2015, 7:59:04 AM8/12/15
to jailho...@googlegroups.com
Hi,

I'm pretty new to jailhouse and I made some bloody mistakes which were hard for me to debug. I tried to enable jailhouse using a cell descriptor instead of using the jailhouse_system. Of course, jailhouse failed. The error message was "Invalid argument" which might mean anything. I first understood what went wrong after I had a look into the code.

I saw that the firmware files of jailhouse contain a signature or call it magic byte(s) "JAILHOUS". This is important, as loading an arbitrary file as firmware would probably lead to a kernel panic. Just a guess - but what do you think about inserting a similar signature inside the system and cell descriptors? A header might then look like
struct {
        __u64 magic;
        struct jailhouse_system header;
        ...
} __attribute__((packed)) config = {
        .magic = JAILHOUSE_SYSTEM_MAGIC;
        .header = {
        ...
Only little additional code would be needed and jailhouse could output a proper error message if it would be able to differentiate between system and cell descriptors. It's not about sanity checking the configuration, it's rather preventing users to make bloody mistakes.

  Ralf
-- 
Ralf Ramsauer
GPG: 0x8F10049B

Jan Kiszka

unread,
Aug 12, 2015, 8:44:00 AM8/12/15
to Ralf Ramsauer, jailho...@googlegroups.com
Hi Ralf,
To differentiate, you would need at least two different magics. I'm not
totally opposed to this, specifically as we could filter things out at
driver level already.

As I said in a related discussion [1], the ideal case would be some
platform identification ID, so that the hypervisor could not only check,
if a config is a system description but also if it fits to the actual
system. Unfortunately, I haven't found something suitable even on x86
yet, not to speak of ARM.

Jan

[1] http://thread.gmane.org/gmane.linux.jailhouse/3470

--
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Ralf Ramsauer

unread,
Aug 12, 2015, 9:00:43 AM8/12/15
to jailho...@googlegroups.com
Hi,
Absolutely, so why not using two magics? You could even filter things
out in userspace before propagating the .cell binary to the jailhouse
device and just skip the magic. Then there would be no modifications at
driver level.
>
> As I said in a related discussion [1], the ideal case would be some
> platform identification ID, so that the hypervisor could not only check,
> if a config is a system description but also if it fits to the actual
> system. Unfortunately, I haven't found something suitable even on x86
> yet, not to speak of ARM.
I see, this would be ideal.
But that's not in contradiction with a signature, which would identify a
system or cell description as such. Additionally, those sanity checks
could be stacked on top of it.

Ralf
Ralf Ramsauer
GPG: 0x8F10049B


Jan Kiszka

unread,
Aug 12, 2015, 10:40:52 AM8/12/15
to Ralf Ramsauer, jailho...@googlegroups.com
Please preserve the CC list.

On 2015-08-12 15:00, Ralf Ramsauer wrote:
> Hi,
>
> On 08/12/15 14:43, Jan Kiszka wrote:
>> Hi Ralf,
>>
>> On 2015-08-12 13:58, Ralf Ramsauer wrote:
>>> Hi,
>>>
>>> I'm pretty new to jailhouse and I made some bloody mistakes which were
>>> hard for me to debug. I tried to enable jailhouse using a cell
>>> descriptor instead of using the jailhouse_system. Of course, jailhouse
>>> failed. The error message was "Invalid argument" which might mean
>>> anything. I first understood what went wrong after I had a look into the
>>> code.
>>>
>>> I saw that the firmware files of jailhouse contain a signature or call
>>> it magic byte(s) "JAILHOUS". This is important, as loading an arbitrary
>>> file as firmware would probably lead to a kernel panic. Just a guess -
>>> but what do you think about inserting a similar signature inside the
>>> system and cell descriptors? A header might then look like
>>>
>>> struct {
>>> __u64 magic;
>>> struct jailhouse_system header;
>>> ...
>>> } __attribute__((packed)) config = {
>>> .magic = JAILHOUSE_SYSTEM_MAGIC;
>>> .header = {

BTW, magics should become part of the respective jailhouse structures then.

>>> ...
>>>
>>> Only little additional code would be needed and jailhouse could output a
>>> proper error message if it would be able to differentiate between system
>>> and cell descriptors. It's not about sanity checking the configuration,
>>> it's rather preventing users to make bloody mistakes.
>> To differentiate, you would need at least two different magics. I'm not
>> totally opposed to this, specifically as we could filter things out at
>> driver level already.
> Absolutely, so why not using two magics? You could even filter things
> out in userspace before propagating the .cell binary to the jailhouse
> device and just skip the magic. Then there would be no modifications at
> driver level.

Do you want to give some patch a try?

Jan

Ralf Ramsauer

unread,
Aug 12, 2015, 12:34:09 PM8/12/15
to Jan Kiszka, jailho...@googlegroups.com
Hi,

On 08/12/15 16:40, Jan Kiszka wrote:
> Please preserve the CC list.
sorry, my bad.
Yes, I think defining them in cell-config.h is a good location. Using a
__u64 value might be a good idea, that's easier to set and compare than
a string.
>
>>>> ...
>>>>
>>>> Only little additional code would be needed and jailhouse could output a
>>>> proper error message if it would be able to differentiate between system
>>>> and cell descriptors. It's not about sanity checking the configuration,
>>>> it's rather preventing users to make bloody mistakes.
>>> To differentiate, you would need at least two different magics. I'm not
>>> totally opposed to this, specifically as we could filter things out at
>>> driver level already.
>> Absolutely, so why not using two magics? You could even filter things
>> out in userspace before propagating the .cell binary to the jailhouse
>> device and just skip the magic. Then there would be no modifications at
>> driver level.
> Do you want to give some patch a try?
Why not, let's give it a try.

Ralf
>
> Jan
Reply all
Reply to author
Forward
0 new messages