linux-kernel - Re: [RFC kvmtool 18/31] arm64: Populate initial realm contents

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7f442447-f69f-5cca-1a3b-fae0910eef23@gmail.com>
Date:   Mon, 2 Oct 2023 11:28:17 +0200
From:   Piotr Sawicki <piotr.sawickas@...il.com>
To:     Suzuki K Poulose <suzuki.poulose@....com>
Cc:     Alexandru Elisei <alexandru.elisei@....com>,
        Andrew Jones <andrew.jones@...ux.dev>,
        Christoffer Dall <christoffer.dall@....com>,
        Fuad Tabba <tabba@...gle.com>,
        Jean-Philippe Brucker <jean-philippe@...aro.org>,
        Joey Gouly <Joey.Gouly@....com>, Marc Zyngier <maz@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Oliver Upton <oliver.upton@...ux.dev>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Quentin Perret <qperret@...gle.com>,
        Steven Price <steven.price@....com>,
        Thomas Huth <thuth@...hat.com>, Will Deacon <will@...nel.org>,
        Zenghui Yu <yuzenghui@...wei.com>, linux-coco@...ts.linux.dev,
        kvmarm@...ts.cs.columbia.edu, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC kvmtool 18/31] arm64: Populate initial realm contents



Hi Suzuki

> Hi Piotr
> 
> On 02/03/2023 14:03, Piotr Sawicki wrote:
>> Hi,
>>
>>> From: Alexandru Elisei <alexandru.elisei@....com>
>>>
>>> Populate the realm memory with the initial contents, which include
>>> the device tree blob, the kernel image, and initrd, if specified,
>>> or the firmware image.
>>>
>>> Populating an image in the realm involves two steps:
>>>   a) Mark the IPA area as RAM - INIT_IPA_REALM
>>>   b) Load the contents into the IPA - POPULATE_REALM
>>>
>>> Wherever we know the actual size of an image in memory, we make
>>> sure the "memory area" is initialised to RAM.
>>> e.g., Linux kernel image size from the header which includes the bss 
>>> etc.
>>> The "file size" on disk for the Linux image is much smaller.
>>> We mark the region of size Image.header.size as RAM (a), from the kernel
>>> load address. And load the Image file into the memory (b) above.
>>> At the moment we only detect the Arm64 Linux Image header format.
>>>
>>> Since we're already touching the code that copies the
>>> initrd in guest memory, let's do a bit of cleaning and remove a
>>> useless local variable.
>>>
>>> Signed-off-by: Alexandru Elisei <alexandru.elisei@....com>
>>> [ Make sure the Linux kernel image area is marked as RAM ]
>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@....com>
> 
> 
>>> diff --git a/arm/kvm.c b/arm/kvm.c
>>> index acb627b2..57c5b5f7 100644
>>> --- a/arm/kvm.c
>>> +++ b/arm/kvm.c
>>> @@ -6,6 +6,7 @@
>>>   #include "kvm/fdt.h"
>>>   #include "arm-common/gic.h"
>>> +#include <asm/realm.h>
>>>   #include <sys/resource.h>
>>> @@ -167,6 +168,9 @@ bool kvm__arch_load_kernel_image(struct kvm *kvm, 
>>> int fd_kernel, int fd_initrd,
>>>       pr_debug("Loaded kernel to 0x%llx (%llu bytes)",
>>>            kvm->arch.kern_guest_start, kvm->arch.kern_size);
>>
>>
>> I've noticed that multiple calling of the measurement test from the 
>> kvm-unit-tests suite results in different Realm Initial Measurements, 
>> although the kernel image is always the same.
>>
>> After short investigation, I've found that the RIM starts being 
>> different while populating the last 4kB chunk of the kernel image.
>> The issue occurs when the image size is not aligned to the page size 
>> (4kB).
>>
>> After zeroing the unused area of the last chunk, the measurements 
>> become repeatable.
>>
> 
> That is a good point. We could memset() the remaining bits of the 4K 
> page to 0. I will make this change.

It looks that this is somewhat related to the implementation of the 9p 
filesystem (Linux host and/or the FVP emulator).

I'm getting this issue only when the initrd and the guest kernel images 
are located in the shared folder that uses the 9p filesystem. Moving 
those files to the ramdisk (e.g. to the /root folder) and running lkvm 
tool on them resolves the issue.

Kind regards,
Piotr Sawicki