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.
GPG one can read the file in chunks and then
keep in memory only hash of every chunk to prevent TOCTOU.
But then the question is when is our makes sense
versus signing individual files. I can see uses like signing
squashfs.
We probably need a "secure device" flag
somewhere long term