Re: [PATCH 0/6] Apple device properties

2016-07-27 Thread Rafael J. Wysocki
On Wednesday, July 27, 2016 01:20:41 PM Lukas Wunner wrote:
> Apple EFI drivers supply device properties which are needed to support
> Macs optimally.
> 
> This series extends the efistub to retrieve the device properties before
> ExitBootServices is called (patch [1/6]). They are assigned to devices
> in an fs_initcall (patch [5/6]). As a first use case, the Thunderbolt
> driver is amended to take advantage of the Device ROM supplied by EFI
> (patch [6/6]).

Can you please CC the whole series to linux-acpi for easier/better review?

Thanks,
Rafael


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


my ongoing attempt...

2016-07-27 Thread Dryden Personalis
I was checking out the patch attempt I had done in May and rebasing it 
on top of current Git.


There were lines in lvm.c I had thought about changing, just some 
housekeeping so to speak.


Turns out those very same things had already been changed by Andrei back 
in May 2015:


commit 5082ea618439fe59956d071777be0c9c74fbbcf5
Author: Andrei Borzenkov 
Date:   Wed May 13 09:47:17 2015 +0300

remove extra newlines in grub_util_* strings

grub_util_{info,warn,error} already add trailing newlines, so remove
them from format strings. Also trailing full stops are already 
added.




But Ubuntu (16.04) still ships with a version older than that, 
apparently.


I would never have fathomed such a thing, my apologies.


I also hope you don't mind me using a developer nick here. My real name 
has the initials of B.S., which is no problem in Dutch, but not so nice 
in English :P.


One of many reasons I guess.

Anyway I came across two minor things that should be no issue here:

=

diff --git a/include/grub/emu/hostdisk.h b/include/grub/emu/hostdisk.h
index e006f0b..2eb0f0c 100644
--- a/include/grub/emu/hostdisk.h
+++ b/include/grub/emu/hostdisk.h
@@ -1,4 +1,4 @@
-/* biosdisk.h - emulate biosdisk */
+/* hostdisk.h - emulate biosdisk */
 /*
  *  GRUB  --  GRand Unified Bootloader
  *  Copyright (C) 2002,2007  Free Software Foundation, Inc.
diff --git a/util/setup.c b/util/setup.c
index 8aa5a39..902e4a9 100644
--- a/util/setup.c
+++ b/util/setup.c
@@ -1,4 +1,4 @@
-/* grub-setup.c - make GRUB usable */
+/* setup.c - make GRUB usable */
 /*
  *  GRUB  --  GRand Unified Bootloader
  *  Copyright (C) 
1999,2000,2001,2002,2003,2004,2005,2006,2007,2008,2009,2010,2011  Free 
Software Foundation, Inc.


=

But I don't know what "emulate biosdisk" should be ;-).

Regards.
diff --git a/include/grub/emu/hostdisk.h b/include/grub/emu/hostdisk.h
index e006f0b..2eb0f0c 100644
--- a/include/grub/emu/hostdisk.h
+++ b/include/grub/emu/hostdisk.h
@@ -1,4 +1,4 @@
-/* biosdisk.h - emulate biosdisk */
+/* hostdisk.h - emulate biosdisk */
 /*
  *  GRUB  --  GRand Unified Bootloader
  *  Copyright (C) 2002,2007  Free Software Foundation, Inc.
diff --git a/util/setup.c b/util/setup.c
index 8aa5a39..902e4a9 100644
--- a/util/setup.c
+++ b/util/setup.c
@@ -1,4 +1,4 @@
-/* grub-setup.c - make GRUB usable */
+/* setup.c - make GRUB usable */
 /*
  *  GRUB  --  GRand Unified Bootloader
  *  Copyright (C) 1999,2000,2001,2002,2003,2004,2005,2006,2007,2008,2009,2010,2011  Free Software Foundation, Inc.
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel


XFSv5 with sparse inode chunks is not supported

2016-07-27 Thread Marcos Mello
Another XFSv5 feature missing from GRUB, introduced by kernel 4.2 [1] and
mkfs.xfs 4.2.0 (-i sparse=0|1) [2]. It is disabled by default in mkfs.xfs up to
current xfsprogs 4.7.0-rc and kernel code is experimental, thus not widely used.
But in kernel 4.8 will be marked as stable [3] and I guess mkfs.xfs will not
take long to enable it by default.

GRUB does not work with volumes created with "-i sparse=1":
(Xubuntu 16.04, 2.02-beta2 plus 1570140, a139188, d3ffeb9, b6e80c7, ff3c200,
049dcfa)

https://paste.fedoraproject.org/396243/

Savannah bug: http://savannah.gnu.org/bugs/?48645

[1] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e5376fc15acdd6b03b6d5223391842717148f0d7
[2] 
http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/cmds/xfsprogs.git;a=commitdiff;h=6003fd816c2e0c4ec2b6352571e14765cca62d07
[3] http://oss.sgi.com/archives/xfs/2016-07/msg00445.html
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel


Re: [GRUB PARTUUID PATCH 2/2] Update grub script template files

2016-07-27 Thread Nick Vinson


On 07/26/2016 10:01 PM, Andrei Borzenkov wrote:
> 20.06.2016 04:37, Nicholas Vinson пишет:
>> Update grub-mkconfig.in and 10_linux.in to support grub-probe's new
>> partuuid target.
>>
>> Signed-off-by: Nicholas Vinson 
>> ---
>>  util/grub-mkconfig.in   |  2 ++
>>  util/grub.d/10_linux.in | 11 +--
>>  2 files changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/util/grub-mkconfig.in b/util/grub-mkconfig.in
>> index f8496d2..fc42462 100644
>> --- a/util/grub-mkconfig.in
>> +++ b/util/grub-mkconfig.in
>> @@ -134,6 +134,7 @@ fi
>>  # Device containing our userland.  Typically used for root= parameter.
>>  GRUB_DEVICE="`${grub_probe} --target=device /`"
>>  GRUB_DEVICE_UUID="`${grub_probe} --device ${GRUB_DEVICE} --target=fs_uuid 
>> 2> /dev/null`" || true
>> +GRUB_DEVICE_PARTUUID="`${grub_probe} --device ${GRUB_DEVICE} 
>> --target=partuuid 2> /dev/null`" || true
>>  
>>  # Device containing our /boot partition.  Usually the same as GRUB_DEVICE.
>>  GRUB_DEVICE_BOOT="`${grub_probe} --target=device /boot`"
>> @@ -182,6 +183,7 @@ if [ "x${GRUB_ACTUAL_DEFAULT}" = "xsaved" ] ; then 
>> GRUB_ACTUAL_DEFAULT="`"${grub
>>  # override them.
>>  export GRUB_DEVICE \
>>GRUB_DEVICE_UUID \
>> +  GRUB_DEVICE_PARTUUID \
>>GRUB_DEVICE_BOOT \
>>GRUB_DEVICE_BOOT_UUID \
>>GRUB_FS \
>> diff --git a/util/grub.d/10_linux.in b/util/grub.d/10_linux.in
>> index de9044c..8081fdb 100644
>> --- a/util/grub.d/10_linux.in
>> +++ b/util/grub.d/10_linux.in
>> @@ -220,8 +220,15 @@ while [ "x$list" != "x" ] ; do
>>  gettext_printf "Found initrd image: %s\n" "${dirname}/${initrd}" >&2
>>elif test -z "${initramfs}" ; then
>>  # "UUID=" and "ZFS=" magic is parsed by initrd or initramfs.  Since 
>> there's
>> -# no initrd or builtin initramfs, it can't work here.
>> -linux_root_device_thisversion=${GRUB_DEVICE}
>> +# no initrd or builtin initramfs, it can't work here.  However, if
>> +# GRUB_DEVICE_PARTUUID is not empty we can use that here if
>> +# GRUD_DISABLE_LINUX_UUID is not set to true.
>> +if [ "x${GRUB_DISABLE_LINUX_UUID}" != "xtrue" ]
>> +&& [ "x${GRUB_DEVICE_PARTUUID}" != "x" ]; then
>> +linux_root_device_thisversion="PARTUUID=${GRUB_DEVICE_PARTUUID}"
> 
> Well, PARTUUID appeared first in 2.6.37 and MSDOS "UUID" in 3.10.
> Unfortunately we have no way to check for it, even as fragile as stored
> kernel config. So I am not sure we should do it by default. And if we
> add some extra knob to turn it on, as you mentioned yourself, you can
> simply add root=PARTUUID=xxx to stored kernel command line.

I've done that using /etc/default/grub and it works, but you end up with
two root=... entries in your kernel command line.  I could have gone
back and edited the grub.cfg to clean up the command-line.

I will adjust the logic so that using PARTUUID is an opt-in feature
instead of an opt-out feature.  Downstream distributions would then be
able to adjust GRUB's defaults in their own packaging and turn this
feature on by default if it made sense for them to do so.

> 
> One more consideration is that reinstalling in existing partition will
> invalidate FS UUID stored in grub.cfg which is arguably the right thing
> because you now have something different there, but PARTUUID will most
> likely remain the same.

I am sorry, but I am not sure I understand the issue you are raising here.

If I boot Linux without an initramfs, I must specify where the root
partition (or device, if the device has no partitions) is.  GRUB
currently does this by setting root to something like '/dev/sda3'.  That
said, this is a Linux limitation not GRUB's.  Linux is unable to use the
FS UUID this early in the boot process.

If I have an initramfs, I *may* be able to use the FS UUID.  In this
case, it all depends on the implementation of my initramfs.  However,
GRUB's current behavior is to assume that all initramfs implementations
understand how to handle UUIDs, that the UUID is the FS UUID, and are
able to mount rootfs properly.

I have no interest in debating if that behavior is correct or not, nor
do I have any interest in changing it.  As currently written, my patch
should favor the FS UUID when an initramfs is detected, the PARTUUID
when it is not, and the Linux device naming scheme when the UUID feature
is disabled or the PARTUUID could not be found.

The rationale for favoring PARTUUID over the linux device name is
because the PARTUUID would allow a system to boot if the device with the
root partition is ever renamed.  In other words, if the device was sda
when grub.cfg was created, but somehow became sdb (or the other way
around), the system would sill be able to boot because the kernel would
still be able to find /sbin/init.  Whereas with the linux device name,
the boot would fail because it would be looking at the wrong device for
/sbin/init (FS UUID provides the same protections, but in theory allows
use to reorder partitions on a single device and 

[PATCH 1/6] efi: Retrieve Apple device properties

2016-07-27 Thread Lukas Wunner
Retrieve device properties from EFI using Apple's proprietary protocol
with GUID 91BD12FE-F6C3-44FB-A5B7-5122AB303AE0, which looks like this:

typedef struct {
unsigned long signature; /* 0x1 */
efi_status_t (*get) (
IN struct apple_properties_protocol *this,
IN struct efi_generic_dev_path *device,
IN efi_char16_t *property_name,
OUT void *buffer,
IN OUT u32 *buffer_size);
/* EFI_SUCCESS, EFI_NOT_FOUND, EFI_BUFFER_TOO_SMALL */
efi_status_t (*set) (
IN struct apple_properties_protocol *this,
IN struct efi_generic_dev_path *device,
IN efi_char16_t *property_name,
IN void *property_value,
IN u32 property_value_len);
/* allocates copies of property name and value */
/* EFI_SUCCESS, EFI_OUT_OF_RESOURCES */
efi_status_t (*del) (
IN struct apple_properties_protocol *this,
IN struct efi_generic_dev_path *device,
IN efi_char16_t *property_name);
/* EFI_SUCCESS, EFI_NOT_FOUND */
efi_status_t (*get_all) (
IN struct apple_properties_protocol *this,
OUT void *buffer,
IN OUT u32 *buffer_size);
/* EFI_SUCCESS, EFI_BUFFER_TOO_SMALL */
} apple_properties_protocol;

Apple's EFI driver implementing this protocol, "AAPL,PathProperties",
is a per-device key/value store which is populated by other EFI drivers.
On macOS, these device properties are retrieved by the bootloader
/usr/standalone/i386/boot.efi. The extension AppleACPIPlatform.kext
subsequently merges them into the I/O Kit registry (see ioreg(8)) where
they can be queried by other kernel extensions and user space.

These device properties contain vital information which cannot be
obtained any other way (e.g. Thunderbolt Device ROM). EFI drivers also
use them to communicate the current device state so that OS drivers can
pick up where EFI drivers left (e.g. GPU mode setting).

The get_all() function conveniently fills a buffer with all properties
in marshalled form which can be passed to the kernel as a setup_data
payload. Note that the device properties will only be available if the
kernel is booted with the efistub. Distros should adjust their
installers to always use the efistub on Macs. grub with the "linux"
directive will not work unless the functionality of this commit is
duplicated in grub. (The "linuxefi" directive should work but is not
included upstream as of this writing.)

Thanks to osxreverser for this blog posting which was helpful in reverse
engineering Apple's EFI drivers and bootloader:
https://reverse.put.as/2016/06/25/apple-efi-firmware-passwords-and-the-scbo-myth/

If someone at Apple is reading this, please note there's a memory leak
in your implementation of the del() function as the property struct is
freed but the name and value allocations are not.

Cc: rever...@put.as
Cc: grub-devel@gnu.org
Cc: Matt Fleming 
Cc: Andreas Noever 
Tested-by: Lukas Wunner  [MacBookPro9,1]
Tested-by: Pierre Moreau  [MacBookPro11,3]
Signed-off-by: Lukas Wunner 
---
 arch/x86/boot/compressed/eboot.c  | 55 +++
 arch/x86/include/uapi/asm/bootparam.h |  1 +
 include/linux/efi.h   | 17 +++
 3 files changed, 73 insertions(+)

diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index ff574da..7262ee4 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -571,6 +571,55 @@ free_handle:
efi_call_early(free_pool, pci_handle);
 }
 
+static void retrieve_apple_device_properties(struct boot_params *params)
+{
+   efi_guid_t guid = APPLE_PROPERTIES_PROTOCOL_GUID;
+   struct setup_data *data, *new;
+   efi_status_t status;
+   void *properties;
+   u32 size = 0;
+
+   status = efi_early->call(
+   (unsigned long)sys_table->boottime->locate_protocol,
+   , NULL, );
+   if (status != EFI_SUCCESS)
+   return;
+
+   do {
+   status = efi_call_early(allocate_pool, EFI_LOADER_DATA,
+   size + sizeof(struct setup_data), );
+   if (status != EFI_SUCCESS) {
+   efi_printk(sys_table,
+  "Failed to alloc mem for properties\n");
+   return;
+   }
+   status = efi_early->call(efi_early->is64 ?
+   ((apple_properties_protocol_64 *)properties)->get_all :
+   ((apple_properties_protocol_32 *)properties)->get_all,
+   properties, new->data, );
+   if (status == EFI_BUFFER_TOO_SMALL)
+