grub-devel.gnu.org archive mirror
 help / color / mirror / Atom feed
From: Andrei Borzenkov <arvidjaar@gmail.com>
To: Samee Zahur <szahur@google.com>
Cc: bug-grub <bug-grub@gnu.org>,
	The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: Patch: Allow Ext4 partitions with encrypted directories.
Date: Sun, 6 Nov 2016 10:08:31 +0300	[thread overview]
Message-ID: <ff7f1fd9-f487-0909-ab23-b5b8a767851f@gmail.com> (raw)
In-Reply-To: <CAP=G5icnk-kdsurFdP_5UcL5QNhr7SvWv0w7suG+j+mWvs9xSQ@mail.gmail.com>

03.11.2016 20:24, Samee Zahur пишет:
>> Hmm ... I had to sign contributor agreement that transfers copyright
>> to FSF. Not that I care personally but that may be problem ...
> 
> Yeah, I don't personally care either. If someone at FSF raises an issue, I
> can reach out to legal experts here. But this is not the first time Google
> (C) has been checked into GRUB. We patch FSF GNU code all the time.
> 
>> And what happens when grub does see encrypted content? Returning
>> garbage is not an option here.
> 
> Good question. The files simply won't be found. The filenames are also
> garbled, so GRUB won't find the files it's looking for.
> 

Do you mean that if grub tries to open this garbled name it succeeds? Is
it possible to detect that directory is encrypted? Then we should refuse
to access this directory with clear explanation.

> On Thu, Nov 3, 2016 at 8:16 AM, Andrei Borzenkov <arvidjaar@gmail.com>
> wrote:
> 
>> On Wed, Nov 2, 2016 at 12:22 AM, Samee Zahur <szahur@google.com> wrote:
>>> Ext4 filesystem now allows users to choose directory trees to be stored
>>> encrypted. However, GRUB refuses to boot from such partitions, even if
>> none
>>> of the boot-critical files are actually affected. The following patch
>> fixes
>>> this. It was tested on the latest release version of ext4.
>>>
>>> Please let me know if more information is needed.
>>>
>>> diff --git a/grub-core/fs/ext2.c b/grub-core/fs/ext2.c
>>> index cdce63b..eca10e4 100644
>>> --- a/grub-core/fs/ext2.c
>>> +++ b/grub-core/fs/ext2.c
>>> @@ -2,6 +2,7 @@
>>>  /*
>>>   *  GRUB  --  GRand Unified Bootloader
>>>   *  Copyright (C) 2003,2004,2005,2007,2008,2009  Free Software
>> Foundation,
>>> Inc.
>>> + *  Copyright (C) 2016 Google, Inc.
>>>   *
>>
>> Hmm ... I had to sign contributor agreement that transfers copyright
>> to FSF. Not that I care personally but that may be problem ...
>>
>>>   *  GRUB is free software: you can redistribute it and/or modify
>>>   *  it under the terms of the GNU General Public License as published by
>>> @@ -102,6 +103,7 @@ GRUB_MOD_LICENSE ("GPLv3+");
>>>  #define EXT4_FEATURE_INCOMPAT_64BIT            0x0080
>>>  #define EXT4_FEATURE_INCOMPAT_MMP              0x0100
>>>  #define EXT4_FEATURE_INCOMPAT_FLEX_BG          0x0200
>>> +#define EXT4_FEATURE_INCOMPAT_ENCRYPT          0x10000
>>>
>>>  /* The set of back-incompatible features this driver DOES support. Add
>> (OR)
>>>   * flags here as the related features are implemented into the driver.
>> */
>>> @@ -120,9 +122,12 @@ GRUB_MOD_LICENSE ("GPLv3+");
>>>   * mmp:            Not really back-incompatible - was added as such to
>>>   *                 avoid multiple read-write mounts. Safe to ignore for
>>> this
>>>   *                 RO driver.
>>> + * encrypt:        We assume boot files are not encrypted (grub config,
>>> kernel,
>>> + *                 initramd etc.). If we are wrong, boot will fail as it
>>> should.
>>>   */
>>
>> Do not assume users won't try to access something else.
>>
>>>  #define EXT2_DRIVER_IGNORED_INCOMPAT ( EXT3_FEATURE_INCOMPAT_RECOVER \
>>> -                                    | EXT4_FEATURE_INCOMPAT_MMP)
>>> +                                    | EXT4_FEATURE_INCOMPAT_MMP     \
>>> +                                    | EXT4_FEATURE_INCOMPAT_ENCRYPT)
>>>
>>
>> And what happens when grub does see encrypted content? Returning
>> garbage is not an option here.
>>
>>>
>>>  #define EXT3_JOURNAL_MAGIC_NUMBER      0xc03b3998U
>>>
>>>
>>> _______________________________________________
>>> Bug-grub mailing list
>>> Bug-grub@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/bug-grub
>>>
>>
> 



  reply	other threads:[~2016-11-06  7:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAP=G5ieRUztQ=kaVg9oFOeAdqUvqgU=e8J7MJ1Si9QP1hGCThw@mail.gmail.com>
2016-11-03 15:16 ` Patch: Allow Ext4 partitions with encrypted directories Andrei Borzenkov
2016-11-03 17:24   ` Samee Zahur
2016-11-06  7:08     ` Andrei Borzenkov [this message]
2016-11-08 19:31       ` Samee Zahur

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ff7f1fd9-f487-0909-ab23-b5b8a767851f@gmail.com \
    --to=arvidjaar@gmail.com \
    --cc=bug-grub@gnu.org \
    --cc=grub-devel@gnu.org \
    --cc=szahur@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).