Re: [PATCH] disk/loopback: Don't verify loopback images

[Dimitri John Ledkov]

On Tue, 2 Jun 2020 at 12:12, Vladimir 'phcoder' Serbinenko
<phcoder@gmail.com> wrote:
>
>
>
> On Mon, Jun 1, 2020, 15:21 Chris Coulson <chris.coulson@canonical.com> wrote:
>>
>> When a file is verified, the entire contents of the verified file are
>> loaded in to memory and retained until the file handle is closed. A
>> consequence of this is that opening a loopback image can incur a
>> significant memory cost.
>>
>> As loopback devices are just another disk implementation, don't treat
>> loopback images any differently to physical disk images, and skip
>> verification of them. Files opened from the filesystem within a loopback
>> image will still be passed to verifier modules where required.
>>
>> Signed-off-by: Chris Coulson <chris.coulson@canonical.com>
>> ---
>>  grub-core/disk/loopback.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/grub-core/disk/loopback.c b/grub-core/disk/loopback.c
>> index cdf9123fa..01267e577 100644
>> --- a/grub-core/disk/loopback.c
>> +++ b/grub-core/disk/loopback.c
>> @@ -93,7 +93,8 @@ grub_cmd_loopback (grub_extcmd_context_t ctxt, int argc, 
>> char **args)
>>      return grub_error (GRUB_ERR_BAD_ARGUMENT, N_("filename expected"));
>>
>>    file = grub_file_open (args[1], GRUB_FILE_TYPE_LOOPBACK
>> -                        | GRUB_FILE_TYPE_NO_DECOMPRESS);
>> +                        | GRUB_FILE_TYPE_NO_DECOMPRESS |
>> +                        GRUB_FILE_TYPE_SKIP_SIGNATURE);
>
> Maybe the verifier should rather decide to skip verification if fuller type 
> is loopback?

How would it be used then? For example, I imagine one can gpg sign the
.iso or a .squashfs and then assume everything inside it is trusted
(even if things inside are not signed).
However, I don't believe any verifier works this way today, nor not
sure it is desired versus signing individual things inside the
loopback device.

At the moment, without this patch, a lot of things break. It is common
to loopback mount .iso which currently eats all the RAM and machines
crash with out of memory. (I.e. loopback mounting 2.5GB .iso).
Similarly it is common to use things like WUBI, where .raw image file
is loopback mounted from NTFS. If one is doing secureboot and tpm is
present that again results in out of memory.

Taking the measurement / checksum / verifying the loopback device is
not a problem, but keeping it all in RAM is. And imho trusting
unsigned things inside verified loopback device is dubious too.

So yeah, probably it's something that verifiers should be able to
decide upon and perform intelligently. But at the moment, the only
practical answer for all of them is to skip.

-- 
Regards,

Dimitri.