Re: Integrating a FreeBSD/GELI change

2017-04-01 Thread Eric McCorkle 
On 04/01/2017 09:57, Andrei Borzenkov wrote:

> 
> There was proposed patch that stored secret in environment variable that
> was later used by loader (I think; I am not sure whether loader part was
> actually implemented). Search this list for subject
> 
> Patch to support GELI passphrase passthrough​
> 
> from Kris Moore (October 2014)

That was the old method, which was replaced by the new key intake
metadata.  The old way is still supported for the time being, but may be
phased out eventually.



signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

[PATCH] acpi: add missing efi_call wrapper to acpi command

2017-04-01 Thread Andrei Borzenkov 
Fixed loading of ACPI tables on EFI (side effect was apparent memory
corruption ranging from unpredictable behavior to system reset).

Reported by Nando Eva 

---

@Nando: please test this patch. It fixed loading for me at least on
QEMU/OVMF. It conflicts with lsacpi patch, but you can actually
verify that RSDP was updated by using "lsefisystab" in grub.

@Vladimir: this looks like 2.02 material as it was obviously wrong.
It does not fix weird behavior on physical system (loss of partitions
afetr loading table using "acpi"); unfortunately, I cannot reproduce
it in QEMU which makes it rather hard to debug. This smells like yet
another meory corruption.

Also our ACPI table mangling code is not clean (e.g. Linux reports
FACS two times). Note that ACPI says normal and extended addresses
(i.e. DSDT/XDSDT and FACS/XFACS) are mutually exclusive, while we
set both to non-zero. This strictly speaking violates specs.

 grub-core/commands/acpi.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/grub-core/commands/acpi.c b/grub-core/commands/acpi.c
index b5c2f27..9f02f22 100644
--- a/grub-core/commands/acpi.c
+++ b/grub-core/commands/acpi.c
@@ -761,10 +761,10 @@ grub_cmd_acpi (struct grub_extcmd_context *ctxt, int 
argc, char **args)
 struct grub_efi_guid acpi = GRUB_EFI_ACPI_TABLE_GUID;
 struct grub_efi_guid acpi20 = GRUB_EFI_ACPI_20_TABLE_GUID;
 
-grub_efi_system_table->boot_services->install_configuration_table
-  (, grub_acpi_get_rsdpv2 ());
-grub_efi_system_table->boot_services->install_configuration_table
-  (, grub_acpi_get_rsdpv1 ());
+efi_call_2 
(grub_efi_system_table->boot_services->install_configuration_table,
+  , grub_acpi_get_rsdpv2 ());
+efi_call_2 
(grub_efi_system_table->boot_services->install_configuration_table,
+  , grub_acpi_get_rsdpv1 ());
   }
 #endif
 
-- 
tg: (8014b7b..) u/acpi-efi_call (depends on: master)

___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Integrating a FreeBSD/GELI change

2017-04-01 Thread Andrei Borzenkov 
01.04.2017 15:57, Eric McCorkle пишет:
> Hello,
> 
> I've been working on a series of changes designed to expand FreeBSD's
> full-disk encryption support via GELI (its preferred disk encryption
> mechanism).  One of the important parts of this landed in HEAD last night:
> 
> https://github.com/freebsd/freebsd/commit/6a205a32527153697eb4df4114ff0cd3c7cd6fd8
> 
> This adds a general mechanism for passing keys into the FreeBSD kernel
> at boot.  At present, this is used exclusively by the GELI subsystem.
> 
> FreeBSD currently supports full-disk encryption for i386 BIOS.  I am
> actively working on EFI support and would like to make sure that GRUB
> also supports full-disk encryption as well (as GRUB is our best option
> for a coreboot setup).
> 
> 
> Basically, to add support for this, I'd need to do two things:
> 
> 1) Ensure that GRUB can handle an entirely GELI-encrypted disk hosting a
> FreeBSD system (I suspect it can, but I've never done a GRUB/GELI setup
> before)
> 
> 2) An additional metadata item needs to get generated when booting the
> FreeBSD kernel that contains all the GELI keys.  (For those who don't
> know, FreeBSD has a kernel metadata mechanism that is used to pass some
> information into the kernel: for example, the EFI console on EFI, some
> BIOS information on i386 BIOS, and so on)
> 
> 
> I've never submitted a patch to GRUB before, so I'm interested in 1) how
> hard would this be,

I suppose like with any other software project of reasonable size.

> 2) where should I look in the source code, and

GELI is in grub-core/disk/geli.c, generic framework for device
encryption (which GELI plugs in) in grub-core/disk/cryptodisk.c and
FreeBSD loader in grub-core/loader/i386/bsd*.

There was proposed patch that stored secret in environment variable that
was later used by loader (I think; I am not sure whether loader part was
actually implemented). Search this list for subject

Patch to support GELI passphrase passthrough​

from Kris Moore (October 2014)

> 3) what is the procedure for submitting patches like this?
>

Just send patches to this list. Better inline using git send-email to
make it easier to comment.



signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Integrating a FreeBSD/GELI change

2017-04-01 Thread Eric McCorkle 
Hello,

I've been working on a series of changes designed to expand FreeBSD's
full-disk encryption support via GELI (its preferred disk encryption
mechanism).  One of the important parts of this landed in HEAD last night:

https://github.com/freebsd/freebsd/commit/6a205a32527153697eb4df4114ff0cd3c7cd6fd8

This adds a general mechanism for passing keys into the FreeBSD kernel
at boot.  At present, this is used exclusively by the GELI subsystem.

FreeBSD currently supports full-disk encryption for i386 BIOS.  I am
actively working on EFI support and would like to make sure that GRUB
also supports full-disk encryption as well (as GRUB is our best option
for a coreboot setup).


Basically, to add support for this, I'd need to do two things:

1) Ensure that GRUB can handle an entirely GELI-encrypted disk hosting a
FreeBSD system (I suspect it can, but I've never done a GRUB/GELI setup
before)

2) An additional metadata item needs to get generated when booting the
FreeBSD kernel that contains all the GELI keys.  (For those who don't
know, FreeBSD has a kernel metadata mechanism that is used to pass some
information into the kernel: for example, the EFI console on EFI, some
BIOS information on i386 BIOS, and so on)


I've never submitted a patch to GRUB before, so I'm interested in 1) how
hard would this be, 2) where should I look in the source code, and 3)
what is the procedure for submitting patches like this?


Best,
Eric



signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Re: Loading DSDT table using 'acpi' or some memory write command?

2017-04-01 Thread Andrei Borzenkov 
29.03.2017 20:45, Nando Eva пишет:
>> How exactly do you find RSDP? On EFI RSDP should be retrieved from EFI
>> Configuration Table, which grub tries to update. Please give as much
>> details as possible.
> 
> Good point. I can get the RSDP from tools like 'ru.efi' or even with 'r-w 
> everything'.
> However, 'lsacpi' won't tell me the new RSDP address after doing a 'acpi 
> dsdt.aml'.
> 
> Is there anyway of finding it out using the grub shell, or chainloading EFI 
> shell (or chainload grubx64.efi from EFI shell and exiting in case grub's 
> chainloading is restoring the ACPI tables)?
> 

Please test attached patch. It adds printing of table addresses as well
as "lsacpi --scan" option that forces fetching RSDP from firmware.

It looks like on EFI our call to InstallConfigurationTable does not
work; after "acpi ..." "lsacpi --scan" still displays old RSDP and
tables (although grub itself would use new one).

I also have rather weird issue that after "acpi dsdt.aml" I lose
partitions (only hard disk itself is visible). This is on real hardware
(Dell Latitude E5450).


From: Andrei Borzenkov 
Subject: [PATCH] lsacpi: print table address and allow bypassing stored pointers

1. Print memory address for each table, similat to what Linux kernel does.

2. Add "--scan" option to ignore stored RSDP address (after acpi command)
and use normal platform-specific way to search for it.

This provides for better debugging results of replacing tables with acpi.

---
 grub-core/commands/acpi.c| 34 --
 grub-core/commands/acpihalt.c|  4 +-
 grub-core/commands/lsacpi.c  | 86 ++--
 grub-core/efiemu/i386/pc/cfgtables.c |  4 +-
 grub-core/loader/multiboot_mbi2.c|  6 +--
 include/grub/acpi.h  | 12 -
 6 files changed, 109 insertions(+), 37 deletions(-)

diff --git a/grub-core/commands/acpi.c b/grub-core/commands/acpi.c
index b5c2f27..4163a78 100644
--- a/grub-core/commands/acpi.c
+++ b/grub-core/commands/acpi.c
@@ -100,22 +100,28 @@ static grub_size_t dsdt_size = 0;
 static grub_uint32_t facs_addr = 0;
 
 struct grub_acpi_rsdp_v20 *
-grub_acpi_get_rsdpv2 (void)
+grub_acpi_get_rsdpv2 (int scan)
 {
-  if (rsdpv2_new)
-return rsdpv2_new;
-  if (rsdpv1_new)
-return 0;
+  if (!scan)
+{
+  if (rsdpv2_new)
+	return rsdpv2_new;
+  if (rsdpv1_new)
+	return 0;
+}
   return grub_machine_acpi_get_rsdpv2 ();
 }
 
 struct grub_acpi_rsdp_v10 *
-grub_acpi_get_rsdpv1 (void)
+grub_acpi_get_rsdpv1 (int scan)
 {
-  if (rsdpv1_new)
-return rsdpv1_new;
-  if (rsdpv2_new)
-return 0;
+  if (!scan)
+{
+  if (rsdpv1_new)
+	return rsdpv1_new;
+  if (rsdpv2_new)
+	return 0;
+}
   return grub_machine_acpi_get_rsdpv1 ();
 }
 
@@ -198,8 +204,8 @@ grub_acpi_create_ebda (void)
   *((grub_uint16_t *) targetebda) = ebda_kb_len + 1;
   target = targetebda;
 
-  v1 = grub_acpi_get_rsdpv1 ();
-  v2 = grub_acpi_get_rsdpv2 ();
+  v1 = grub_acpi_get_rsdpv1 (0);
+  v2 = grub_acpi_get_rsdpv2 (0);
   if (v2 && v2->length > 40)
 v2 = 0;
 
@@ -762,9 +768,9 @@ grub_cmd_acpi (struct grub_extcmd_context *ctxt, int argc, char **args)
 struct grub_efi_guid acpi20 = GRUB_EFI_ACPI_20_TABLE_GUID;
 
 grub_efi_system_table->boot_services->install_configuration_table
-  (, grub_acpi_get_rsdpv2 ());
+  (, grub_acpi_get_rsdpv2 (0));
 grub_efi_system_table->boot_services->install_configuration_table
-  (, grub_acpi_get_rsdpv1 ());
+  (, grub_acpi_get_rsdpv1 (0));
   }
 #endif
 
diff --git a/grub-core/commands/acpihalt.c b/grub-core/commands/acpihalt.c
index 9cc7f18..d7c51e1 100644
--- a/grub-core/commands/acpihalt.c
+++ b/grub-core/commands/acpihalt.c
@@ -395,11 +395,11 @@ grub_acpi_halt (void)
   grub_uint32_t port = 0;
   int sleep_type = -1;
 
-  rsdp2 = grub_acpi_get_rsdpv2 ();
+  rsdp2 = grub_acpi_get_rsdpv2 (0);
   if (rsdp2)
 rsdp1 = &(rsdp2->rsdpv1);
   else
-rsdp1 = grub_acpi_get_rsdpv1 ();
+rsdp1 = grub_acpi_get_rsdpv1 (0);
   grub_dprintf ("acpi", "rsdp1=%p\n", rsdp1);
   if (!rsdp1)
 return;
diff --git a/grub-core/commands/lsacpi.c b/grub-core/commands/lsacpi.c
index 0824914..34c1220 100644
--- a/grub-core/commands/lsacpi.c
+++ b/grub-core/commands/lsacpi.c
@@ -43,6 +43,7 @@ print_strn (grub_uint8_t *str, grub_size_t len)
 static void
 disp_acpi_table (struct grub_acpi_table_header *t)
 {
+  grub_printf ("%p: ", t);
   print_field (t->signature);
   grub_printf ("%4" PRIuGRUB_UINT32_T "B rev=%u chksum=0x%02x (%s) OEM=", t->length, t->revision, t->checksum,
 	   grub_byte_checksum (t, t->length) == 0 ? "valid" : "invalid");
@@ -59,7 +60,6 @@ disp_madt_table (struct grub_acpi_madt *t)
   struct grub_acpi_madt_entry_header *d;
   grub_uint32_t len;
 
-  disp_acpi_table (>hdr);
   grub_printf ("Local APIC=%08" PRIxGRUB_UINT32_T "  Flags=%08"
 	   PRIxGRUB_UINT32_T "\n",
 	   t->lapic_addr, t->flags);
@@ -174,6 +174,61 @@ disp_madt_table (struct grub_acpi_madt