Hi Glenn,
I will be looking at the patches on the grub-devel this week. I will
send you my comments then.
Daniel
On Sun, Oct 18, 2020 at 01:23:25PM -0500, Glenn Washburn wrote:
> Daniel, Patrick,
>
> Have either of you had a chance to review this patch? Daniel, this is
> my interpretation of wh
On Fri, 9 Oct 2020 12:00:47 +0200
Patrick Steinhardt wrote:
> On Sat, Oct 03, 2020 at 05:55:34PM -0500, Glenn Washburn wrote:
> > This makes it more obvious to the reader that the disk referred to
> > is the source disk, as opposed to say the disk holding the
> > cryptodisk.
>
> Hum. I'm not sur
Hi Daniel,
On 2020.07.29 18:46, Daniel Kiper wrote:
I think this link [1] will explain my long absence... Sorry about that.
I am going to go back to GRUB work next week. I will triage all the patches
and take all (obvious) fixes. Then I will release rc1 ASAP... All new features
will be taken af
Heres an updated patch series which addresses comment from Patrick. The only
code change is adding a slot_key member to grub_luks2_keyslot and using that
instead of an extra out parameter to luks2_get_keyslot.
Glenn Washburn (10):
luks2: Fix use of incorrect index and some grub_error() messages.
The total_length field is named confusingly because length usually refers to
bytes, whereas in this case its really the total number of sectors on the
device. Also counter-intuitively, grub_disk_get_size returns the total
number of device native sectors. We need to convert the sectors from the
size
When looping over the digests and segments, the loop variable is j, but the
variable i is used to index in the the digests and segments json array. The
variable i is the keyslot index. Similarly, there are several grub_error()
statements using the wrong index in constructing the error string.
Sign
Use the keyslot key value in the keyslot json array rather than the index of
the keyslot in the json array. This is less confusing for the end user. For
example, say you have a LUKS2 device with a key in slot 1 and slot 4. When
using the password for slot 4 to unlock the device, the messages using
This should improve readability of code by providing clues as to what the
value represents.
Signed-off-by: Glenn Washburn
---
grub-core/disk/cryptodisk.c | 12 +++-
include/grub/types.h| 3 +++
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/grub-core/disk/crypto
This makes it more obvious to the reader that the disk referred to is the
source disk, as opposed to say the disk holding the cryptodisk.
Signed-off-by: Glenn Washburn
---
grub-core/disk/luks2.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/grub-cor
Introduce new variables keyslot_key, digest_key, and segment_key which
represent the integer key of the item in the respective associative array
when looping over the array items. This replaces using a generically
named variable named "idx" used for all three values. The parameter "i"
is renamed to
By default, dm-crypt internally uses an IV that corresponds to 512-byte
sectors, even when a larger sector size is specified. What this means is
that when using a larger sector size, the IV is incremented every sector.
However, the amount the IV is incremented is the number of 512 byte blocks
in a
When setting cipher IV mode, detection is done by prefix matching the
cipher IV mode part of the cipher mode string. Since "plain" matches
"plain64", we must check for "plain64" first. Otherwise, "plain64" will
be detected as "plain".
Signed-off-by: Glenn Washburn
Reviewed-by: Patrick Steinhard
This creates an alignment with grub_disk_t naming of the same field and is
more intuitive as to how it should be used.
Signed-off-by: Glenn Washburn
---
grub-core/disk/cryptodisk.c | 2 +-
grub-core/disk/geli.c | 2 +-
grub-core/disk/luks.c | 2 +-
grub-core/disk/luks2.c | 4 ++-
This makes it clear that the offset represents sectors, not bytes, in order
to improve readability.
Signed-off-by: Glenn Washburn
---
grub-core/disk/cryptodisk.c | 10 +-
grub-core/disk/geli.c | 2 +-
grub-core/disk/luks.c | 4 ++--
grub-core/disk/luks2.c | 4 ++--
in
[This bounced from the list for some reason, so I'm trying again.]
Hi Michal,
That's a really interesting proposal - thank you. I'm still thinking
about it and experimenting with it in SLOF.
Some thoughts:
> It has been pointed out in the plumbers session that the ELF note will
> cause problems
On Fri, Aug 21, 2020 at 12:37:20PM +1000, Daniel Axtens wrote:
> Signing grub for firmware that verifies an appended signature is a
> bit fiddly. I don't want people to have to figure it out from scratch
> so document it here.
>
> Signed-off-by: Daniel Axtens
> ---
> docs/grub.texi | 42
Hi Michael,
>> +@section Signing GRUB with an appended signature
>> +
>> +The @file{core.img} itself can be signed with a Linux kernel module-style
>> +appended signature.
>> +
>> +To support IEEE1275 platforms where the boot image is often loaded directly
>> +from a disk partition rather than fro
On Tue, Oct 20, 2020 at 03:51:11PM +1100, Daniel Axtens wrote:
> Hi Michael,
>
> >> +@section Signing GRUB with an appended signature
> >> +
> >> +The @file{core.img} itself can be signed with a Linux kernel module-style
> >> +appended signature.
> >> +
> >> +To support IEEE1275 platforms where th
18 matches
Mail list logo
