From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1ciPvq-0000SL-1k for mharc-grub-devel@gnu.org; Mon, 27 Feb 2017 13:21:58 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55856) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ciPvm-0000Ok-8Z for grub-devel@gnu.org; Mon, 27 Feb 2017 13:21:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ciPvh-0007U4-9A for grub-devel@gnu.org; Mon, 27 Feb 2017 13:21:54 -0500 Received: from nm12-vm5.bullet.mail.gq1.yahoo.com ([98.136.218.204]:40616) by eggs.gnu.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71) (envelope-from ) id 1ciPvg-0007Td-SV for grub-devel@gnu.org; Mon, 27 Feb 2017 13:21:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ymail.com; s=s2048; t=1488219707; bh=u/W9slC4c2wyzsTtI7yu8qTeWmOxPWI/HjpsGHCJ2oA=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=Ky/VB9Su9NOl3tZJV9NAUKJ2tAYDRhZuqnsTHukt+SaPE19e8N22yop7NmhbMdOKsB4CI+7Woi00dtwrRNtJb6eNEXZjQf1qdS3Q7ufgxR8+Rp0IGw27ytHv2+PLfQjpMqP9ZErKbVuO8xoxT0fuDDWJdXB513RF4IMpw71hzXtknMCs4BrntWVBkf68wsNIHzEDh/mdvt2xgBbDduWjYFQr5QLoj+XW+8KA/KdBCj0m3jgUzBA3doUhylnMLZRnIidxrQFhPoW1En9CsvcRPsJJF+NdeHuUaz2YoZ9NpzISkVJIEVcvKcQYsy1rP1Of1u0asUI0ZvhLYfCDOurLiQ== Received: from [216.39.60.184] by nm12.bullet.mail.gq1.yahoo.com with NNFMP; 27 Feb 2017 18:21:47 -0000 Received: from [98.137.12.221] by tm20.bullet.mail.gq1.yahoo.com with NNFMP; 27 Feb 2017 18:21:47 -0000 Received: from [127.0.0.1] by omp1029.mail.gq1.yahoo.com with NNFMP; 27 Feb 2017 18:21:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 484194.62993.bm@omp1029.mail.gq1.yahoo.com X-YMail-OSG: kzhUDREVM1mOvE6tnm7zMCDlDT1jeDU7samWb86aM82PWz7vfFbGpzuyE34cU8Q GBptEf3Tg_OTkXW5i6FJforN4eAgj4fV.l6A6WSFfVmbsrIBpXUWDkaUhY9IJBKZucfR2cKsovbM GZdKu7LnUhd6rxomH54lj9ADD8A7KfABShGgKLbxYVoRXXB_lyZxDuBIbWAx77cUpAXizNptElZq P9t80mMhwsFVUqgh5Pjr_32cx5XAFWkNezO.iT4wXuo3ydhMExCh5XINVlozDa4_fgL6t0uMys0Z wO0Arhm5hD6EVwt0ne9aT8wcAdUW7yKK.6VYx7e0RfD0RYzJfNlL9U8t8PUJElaJSlO8Odo2YjQV vAmErgikNe.T3meRhyzYwR.oWLVwbrPipBmu1NM2mOEfWM7SDqQiDnF73ss4sx_neuKbJxDZattE 6E8iTrgACSbkOWl8GgnsJYyLKX4zaPWUv..ZHAW2vmMXPOG6e_Zsu7VkqUIUs4p0V0VrtfcEqwE. UJ8i1mdoa.ZbimRkaV0lMSDAJ2dySvBZlV3KyJFFwT2pQX_.AjIQavLLO Received: from jws300001.mail.gq1.yahoo.com by sendmailws121.mail.gq1.yahoo.com; Mon, 27 Feb 2017 18:21:47 +0000; 1488219707.002 Date: Mon, 27 Feb 2017 18:21:46 +0000 (UTC) From: Nando Eva Reply-To: Nando Eva To: "grub-devel@gnu.org" Message-ID: <1893359760.2685777.1488219706759@mail.yahoo.com> In-Reply-To: <144480689.2460565.1488208393781@mail.yahoo.com> References: <1736729449.4676062.1487865639993.ref@mail.yahoo.com> <1736729449.4676062.1487865639993@mail.yahoo.com> <229125734.2281203.1488194973248@mail.yahoo.com> <144480689.2460565.1488208393781@mail.yahoo.com> Subject: Re: Loading DSDT table using 'acpi' or some memory write command? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2685776_724535270.1488219706756" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 98.136.218.204 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 18:21:56 -0000 ------=_Part_2685776_724535270.1488219706756 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Vladimir 'phcoder' Serbinenko wrote: I reproduced the bug. I'm investigating >> Apparently finish_boot_services rewrites acpi tables. It's possible to w= orkaround this, possibly by using acpi table protocol. >> But it's certaine= ly not for 2.02 at this point. Thank you for investigating the issue. Earlier I did a test to check to see= if UEFI chainloading was altering ACPI tables. I did this by: 1. performing two grub2 "write_dword" console memory commands to enable ASP= M in the ACPI FADT (FACP on my system) table as per http://smackerelofopini= on.blogspot.com.au/2011/03/making-sense-of-pcie-aspm.html=20 2. then chainloaded from Grub2 to windows: chainloader /efi/Microsoft/Boot/= bootmgfw.efi The ASPM enabling change was there as found by using r-w everything and rep= orted by 'powercfg /energy', indicating the UEFI chainloading isn't, at lea= st for ACPI FADT (FACP), altering the in-memory table. As the DSDT table is much larger, I can't really write_dword it. Hence aski= ng for some other memory loading module. As another lead, I found the mentioned finish_boot_services routine in mm.c= , quoted below. Would you mind pointing out which code is rewriting the ACP= I tables? Thank you,Nando ---grub_err_t grub_efi_finish_boot_services (grub_efi_uintn_t *outbuf_size, void *outbuf, =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 grub_efi_uintn_t *map_key, =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 grub_efi_uintn_t *efi_desc_size, =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 grub_efi_uint32_t *efi_desc_version) { =C2=A0 grub_efi_boot_services_t *b; =C2=A0 grub_efi_status_t status; #if defined (__i386__) || defined (__x86_64__) =C2=A0 const grub_uint16_t apple[] =3D { 'A', 'p', 'p', 'l', 'e' }; =C2=A0 int is_apple; =C2=A0 is_apple =3D (grub_memcmp (grub_efi_system_table->firmware_vendor, =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 apple= , sizeof (apple)) =3D=3D 0); #endif =C2=A0 while (1) =C2=A0=C2=A0=C2=A0 { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (grub_efi_get_memory_map (&finish_mmap_si= ze, finish_mmap_buf, &finish_key, =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 &finish_desc_size, &finish_desc_version) < 0) =C2=A0=C2=A0=C2=A0 return grub_error (GRUB_ERR_IO, "couldn't retrieve memor= y map"); =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (outbuf && *outbuf_size < finish_mmap_siz= e) =C2=A0=C2=A0=C2=A0 return grub_error (GRUB_ERR_IO, "memory map buffer is to= o small"); =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 finish_mmap_buf =3D grub_malloc (finish_mmap= _size); =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (!finish_mmap_buf) =C2=A0=C2=A0=C2=A0 return grub_errno; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (grub_efi_get_memory_map (&finish_mmap_si= ze, finish_mmap_buf, &finish_key, =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 &finish_desc_size, &finish_desc_version) <=3D 0) =C2=A0=C2=A0=C2=A0 { =C2=A0=C2=A0=C2=A0 =C2=A0 grub_free (finish_mmap_buf); =C2=A0=C2=A0=C2=A0 =C2=A0 return grub_error (GRUB_ERR_IO, "couldn't retriev= e memory map"); =C2=A0=C2=A0=C2=A0 } =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 b =3D grub_efi_system_table->boot_services; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 status =3D efi_call_2 (b->exit_boot_services= , grub_efi_image_handle, =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 finis= h_key); =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (status =3D=3D GRUB_EFI_SUCCESS) =C2=A0=C2=A0=C2=A0 break; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (status !=3D GRUB_EFI_INVALID_PARAMETER) =C2=A0=C2=A0=C2=A0 { =C2=A0=C2=A0=C2=A0 =C2=A0 grub_free (finish_mmap_buf); =C2=A0=C2=A0=C2=A0 =C2=A0 return grub_error (GRUB_ERR_IO, "couldn't termina= te EFI services"); =C2=A0=C2=A0=C2=A0 } =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 grub_free (finish_mmap_buf); =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 grub_printf ("Trying to terminate EFI servic= es again\n"); =C2=A0=C2=A0=C2=A0 } =C2=A0 grub_efi_is_finished =3D 1; =C2=A0 if (outbuf_size) =C2=A0=C2=A0=C2=A0 *outbuf_size =3D finish_mmap_size; =C2=A0 if (outbuf) =C2=A0=C2=A0=C2=A0 grub_memcpy (outbuf, finish_mmap_buf, finish_mmap_size); =C2=A0 if (map_key) =C2=A0=C2=A0=C2=A0 *map_key =3D finish_key; =C2=A0 if (efi_desc_size) =C2=A0=C2=A0=C2=A0 *efi_desc_size =3D finish_desc_size; =C2=A0 if (efi_desc_version) =C2=A0=C2=A0=C2=A0 *efi_desc_version =3D finish_desc_version; #if defined (__i386__) || defined (__x86_64__) =C2=A0 if (is_apple) =C2=A0=C2=A0=C2=A0 stop_broadcom (); #endif =C2=A0 return GRUB_ERR_NONE; } Nando=20 On Tuesday, 28 February 2017, 2:13, Nando Eva wro= te: =20 Andrei Borzenkov wrote: >> That's more or less what grub tries to do. We cannot really overwrite >> ACPI tables because they may be located in read-only memory, but it >> attempts to create EBDA and place new RSDP there and update EBDA >> address as well as update RSDP pointer in EFI system table. I would >> suggest trying to load something else (like Linux) and check whether >> it sees new or old table. This user had 'acpi' also fail to replace the FACS ACPI table on Linux: https://bbs.archlinux.org/viewtopic.php?id=3D190258=20 The DSDT I require is for Win10. Win10 has a registry override method to re= place a DSDT but requires test signing mode to do it, along with some app r= estrictions/incompatibilities.=20 I require a pre-boot DSDT override method to overcome Win10 test signing mo= de AND have my required DSDT table loaded. Just need an in-memory DSDT subs= itution tool to do it. =20 I have been able to accomplish this using MBR boot because the tools exist.= For the more popular UEFI,I have yet to find a load-file-into-memory-locat= ion tool to make it possible. Only things are the multiboot file encapsulat= ion, hexedit and write_dword. All not the right fit.=20 Any chance the grub-devel team can help out here with either a load-file-to= -memory-location module/tool (where I need to find the address) or specific= ally one that does a in-memory DSDT override by overwriting the existing ta= ble? Of course, ppl with read-only memory can't use it just like I imagine = would be the case with the current 'acpi' method.=20 Thank you, Nando =20 ------=_Part_2685776_724535270.1488219706756 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Vladimir 'phcoder' S= erbinenko wrote:

I reproduced the b= ug. I'm investigating
>> Apparently finish_boot_services rewrites acpi tables. It's possible to workaround=20 this, possibly by using acpi table protocol. >> But it's certainely n= ot for 2.02 at this point.

= Thank you for investigating the issue. Earlier I did a test to check to see= if UEFI chainloading was altering ACPI tables. I did this by:

1.= performing two grub2 "write_dword" console memory commands to enable ASPM = in the ACPI FADT (FACP on my system) table as per http://smackerelofopinion.blogspot.com.au/2011/03/making-sense-of-p= cie-aspm.html

2. th= en chainloaded from Grub2 to windows: chainloader /efi/Microsoft/Boot/bootm= gfw.efi

The ASPM enabling change was there as found by using r-w everything and report= ed by=20 'powercfg /energy', indicating the UEFI chainloading isn't, at least for ACPI FADT (FACP), altering the in-memory table.

As the DSDT table is much larger, I can't really write_dword it. Hence = asking for some other memory loading module.

As another lead, I found the mentioned finish_boot_services rou= tine in mm.c, quoted below. Would you mind pointing out which code is rewri= ting the ACPI tables?

Thank you,
N= ando

---
grub_err_t
grub_efi_finish_boot_services (grub_efi_uintn_t *outbuf_size, void= *outbuf,
    &nb= sp;              gru= b_efi_uintn_t *map_key,
 &n= bsp;              &n= bsp;  grub_efi_uintn_t *efi_desc_size,
             =       grub_efi_uint32_t *efi_desc_version)
{
  grub_efi_boot_services_t *b;
  grub_efi_status_t status;

#if defined (__i38= 6__) || defined (__x86_64__)
&nb= sp; const grub_uint16_t apple[] =3D { 'A', 'p', 'p', 'l', 'e' };
  int is_apple;

  is= _apple =3D (grub_memcmp (grub_efi_system_table->firmware_vendor,
       =        apple, sizeof (apple)) =3D=3D 0);
#endif

  while (1)
    {
      if (grub_efi_get= _memory_map (&finish_mmap_size, finish_mmap_buf, &finish_key,
       =            &finish_desc_size, = &finish_desc_version) < 0)
    return grub_error (GRUB_ERR_IO, "couldn't retrieve mem= ory map");

      if (outbuf &&= *outbuf_size < finish_mmap_size)
    return grub_error (GRUB_ERR_IO, "memory map buffer = is too small");

      finish_mmap_buf = =3D grub_malloc (finish_mmap_size);
      if (!finish_mmap_buf)
    return grub_errno;

=       if (grub_efi_get_memory_map (&finish_mma= p_size, finish_mmap_buf, &finish_key,
             &n= bsp;     &finish_desc_size, &finish_desc_version) &l= t;=3D 0)
    {      grub_fre= e (finish_mmap_buf);
  = ;    return grub_error (GRUB_ERR_IO, "couldn't retrieve memory ma= p");
    }

      b =3D grub_efi_system_table->boot_= services;
   &nbs= p;  status =3D efi_call_2 (b->exit_boot_services, grub_efi_image_ha= ndle,
     &= nbsp;         finish_key);
      if (status =3D=3D G= RUB_EFI_SUCCESS)
  &nb= sp; break;

      if (status !=3D GRUB_= EFI_INVALID_PARAMETER)
 &nb= sp;  {
    &= nbsp; grub_free (finish_mmap_buf);
      return grub_error (GRUB_ERR_IO, "couldn't term= inate EFI services");
 &nbs= p;  }

      grub_free (finish_mma= p_buf);
    =   grub_printf ("Trying to terminate EFI services again\n");
    }
  grub_efi_is_finished =3D 1;
  if (outbuf_size)
    *outbuf_size =3D finish_mmap_size;
  if (outbuf)
    grub_memcpy (outbuf, finish_mm= ap_buf, finish_mmap_size);
 = ; if (map_key)
   = ; *map_key =3D finish_key;
 = ; if (efi_desc_size)
  = ;  *efi_desc_size =3D finish_desc_size;
  if (efi_desc_version)
    *efi_desc_version =3D finish_desc_version;

#if defined (__i386__) || defined (__x86_64__)
  if (is_apple)
    stop_broadcom ();
#endif

  return GRUB_ERR_NONE;
}


=
Nando
<= /div>


On Tuesday, 28 Februa= ry 2017, 2:13, Nando Eva <nando4eva@ymail.com> wrote:

<= div style=3D"color:#000;background-color:#fff;font-family:verdana, helvetic= a, sans-serif;font-size:13px;">
Andrei Borzenkov wrote:
>> That's mor=
e or less what grub tries to do. We cannot really overwrite
>> ACPI tables because they may be located in read-only memory, but i=
t
>> attempts to create EBDA and place new RSDP there and update EBDA
>> address as well as update RSDP pointer in EFI system table. I woul=
d
>> suggest trying to load something else (like Linux) and check wheth=
er
>> it sees new or old table.

Thi=
s user had 'acpi' also fail to replace the FACS ACPI table on Linux:
https://bbs.archlinux.org/viewtopic.php?id=3D1=
90258 

The DSDT I require is for W=
in10. Win10 has a registry override method to replace a DSDT but requires t=
est signing mode to do it, along with some app restrictions/incompatibiliti=
es. 

I require a pre-boot DSDT overrid=
e method to overcome Win10 test signing mode AND have my required DSDT tabl=
e loaded. Just need an in-memory DSDT subsitution tool to do it.  

I have been able to accomplish this using MBR =
boot because the tools exist. For the more popular UEFI,I have yet to find =
a load-file-into-memory-location tool to make it possible. Only things are =
the multiboot file encapsulation, hexedit and write_dword. All not the righ=
t fit. 

Any chance the grub-devel team=
 can help out here with either a load-file-to-memory-location module/tool (=
where I need to find the address) or specifically one that does a in-memory=
 DSDT override by overwriting the existing table? Of course, ppl with read-=
only memory can't use it just like I imagine would be the case with the cur=
rent 'acpi' method. 


Thank you,
Nando


------=_Part_2685776_724535270.1488219706756--