diff mbox

ACPICA: use designated initializers

Message ID 20161217010425.GA140581@beast (mailing list archive)
State Not Applicable, archived
Headers show

Commit Message

Kees Cook Dec. 17, 2016, 1:04 a.m. UTC
Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.

Signed-off-by: Kees Cook <keescook@chromium.org>
---
 drivers/acpi/acpica/hwxfsleep.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

Comments

Rafael J. Wysocki Dec. 17, 2016, 2:17 a.m. UTC | #1
On Sat, Dec 17, 2016 at 2:04 AM, Kees Cook <keescook@chromium.org> wrote:
> Prepare to mark sensitive kernel structures for randomization by making
> sure they're using designated initializers. These were identified during
> allyesconfig builds of x86, arm, and arm64, with most initializer fixes
> extracted from grsecurity.
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
>  drivers/acpi/acpica/hwxfsleep.c | 11 ++++++-----
>  1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/acpi/acpica/hwxfsleep.c b/drivers/acpi/acpica/hwxfsleep.c
> index f76e0eab32b8..25cd5c66e102 100644
> --- a/drivers/acpi/acpica/hwxfsleep.c
> +++ b/drivers/acpi/acpica/hwxfsleep.c
> @@ -70,11 +70,12 @@ static acpi_status acpi_hw_sleep_dispatch(u8 sleep_state, u32 function_id);
>  /* Legacy functions are optional, based upon ACPI_REDUCED_HARDWARE */
>
>  static struct acpi_sleep_functions acpi_sleep_dispatch[] = {
> -       {ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_sleep),
> -        acpi_hw_extended_sleep},
> -       {ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake_prep),
> -        acpi_hw_extended_wake_prep},
> -       {ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake), acpi_hw_extended_wake}
> +       { .legacy_function = ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_sleep),
> +         .extended_function = acpi_hw_extended_sleep },
> +       { .legacy_function = ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake_prep),
> +         .extended_function = acpi_hw_extended_wake_prep },
> +       { .legacy_function = ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake),
> +         .extended_function = acpi_hw_extended_wake }
>  };
>
>  /*
> --

The problem here is like in the other patch sent earlier today.  If we
change that here, it will diverge from the upstream file it has been
generated from.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lv Zheng Dec. 19, 2016, 6:06 a.m. UTC | #2
Hi,

> From: Kees Cook [mailto:keescook@chromium.org]
> Subject: [PATCH] ACPICA: use designated initializers
> 
> Prepare to mark sensitive kernel structures for randomization by making
> sure they're using designated initializers. These were identified during
> allyesconfig builds of x86, arm, and arm64, with most initializer fixes
> extracted from grsecurity.

This commit is not suitable for ACPICA upstream.
It's not portable. Please drop.

Thanks
Lv

> 
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
>  drivers/acpi/acpica/hwxfsleep.c | 11 ++++++-----
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/acpi/acpica/hwxfsleep.c b/drivers/acpi/acpica/hwxfsleep.c
> index f76e0eab32b8..25cd5c66e102 100644
> --- a/drivers/acpi/acpica/hwxfsleep.c
> +++ b/drivers/acpi/acpica/hwxfsleep.c
> @@ -70,11 +70,12 @@ static acpi_status acpi_hw_sleep_dispatch(u8 sleep_state, u32 function_id);
>  /* Legacy functions are optional, based upon ACPI_REDUCED_HARDWARE */
> 
>  static struct acpi_sleep_functions acpi_sleep_dispatch[] = {
> -	{ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_sleep),
> -	 acpi_hw_extended_sleep},
> -	{ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake_prep),
> -	 acpi_hw_extended_wake_prep},
> -	{ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake), acpi_hw_extended_wake}
> +	{ .legacy_function = ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_sleep),
> +	  .extended_function = acpi_hw_extended_sleep },
> +	{ .legacy_function = ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake_prep),
> +	  .extended_function = acpi_hw_extended_wake_prep },
> +	{ .legacy_function = ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake),
> +	  .extended_function = acpi_hw_extended_wake }
>  };
> 
>  /*
> --
> 2.7.4
> 
> 
> --
> Kees Cook
> Nexus Security
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Kees Cook March 29, 2017, 9:16 p.m. UTC | #3
On Sun, Dec 18, 2016 at 10:06 PM, Zheng, Lv <lv.zheng@intel.com> wrote:
> Hi,
>
>> From: Kees Cook [mailto:keescook@chromium.org]
>> Subject: [PATCH] ACPICA: use designated initializers
>>
>> Prepare to mark sensitive kernel structures for randomization by making
>> sure they're using designated initializers. These were identified during
>> allyesconfig builds of x86, arm, and arm64, with most initializer fixes
>> extracted from grsecurity.
>
> This commit is not suitable for ACPICA upstream.
> It's not portable. Please drop.

What compilers are building this that do not support designated
initializers? Also, couldn't this be made into a macro so it could be
supported in either case?

#ifdef __GNUC__
# define ACPI_SLEEP_FUNCTIONS(legacy, extended) { \
    .legacy_function = legacy, \
    .extended_function = extended, \
}
#else
# define ACPI_SLEEP_FUNCTIONS(legacy, extended) { legacy, extended }
#endif

...

 static struct acpi_sleep_functions acpi_sleep_dispatch[] = {
        ACPI_SLEEP_FUNCTIONS(
               ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_sleep),
               acpi_hw_extended_sleep),
...


-Kees

>
> Thanks
> Lv
>
>>
>> Signed-off-by: Kees Cook <keescook@chromium.org>
>> ---
>>  drivers/acpi/acpica/hwxfsleep.c | 11 ++++++-----
>>  1 file changed, 6 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/acpi/acpica/hwxfsleep.c b/drivers/acpi/acpica/hwxfsleep.c
>> index f76e0eab32b8..25cd5c66e102 100644
>> --- a/drivers/acpi/acpica/hwxfsleep.c
>> +++ b/drivers/acpi/acpica/hwxfsleep.c
>> @@ -70,11 +70,12 @@ static acpi_status acpi_hw_sleep_dispatch(u8 sleep_state, u32 function_id);
>>  /* Legacy functions are optional, based upon ACPI_REDUCED_HARDWARE */
>>
>>  static struct acpi_sleep_functions acpi_sleep_dispatch[] = {
>> -     {ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_sleep),
>> -      acpi_hw_extended_sleep},
>> -     {ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake_prep),
>> -      acpi_hw_extended_wake_prep},
>> -     {ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake), acpi_hw_extended_wake}
>> +     { .legacy_function = ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_sleep),
>> +       .extended_function = acpi_hw_extended_sleep },
>> +     { .legacy_function = ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake_prep),
>> +       .extended_function = acpi_hw_extended_wake_prep },
>> +     { .legacy_function = ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake),
>> +       .extended_function = acpi_hw_extended_wake }
>>  };
>>
>>  /*
>> --
>> 2.7.4
>>
>>
>> --
>> Kees Cook
>> Nexus Security
Lv Zheng March 30, 2017, 2:12 a.m. UTC | #4
SGksDQoNCj4gRnJvbToga2Vlc2Nvb2tAZ29vZ2xlLmNvbSBbbWFpbHRvOmtlZXNjb29rQGdvb2ds
ZS5jb21dIE9uIEJlaGFsZiBPZiBLZWVzIENvb2sNCj4gU3ViamVjdDogUmU6IFtQQVRDSF0gQUNQ
SUNBOiB1c2UgZGVzaWduYXRlZCBpbml0aWFsaXplcnMNCj4gDQo+IE9uIFN1biwgRGVjIDE4LCAy
MDE2IGF0IDEwOjA2IFBNLCBaaGVuZywgTHYgPGx2LnpoZW5nQGludGVsLmNvbT4gd3JvdGU6DQo+
ID4gSGksDQo+ID4NCj4gPj4gRnJvbTogS2VlcyBDb29rIFttYWlsdG86a2Vlc2Nvb2tAY2hyb21p
dW0ub3JnXQ0KPiA+PiBTdWJqZWN0OiBbUEFUQ0hdIEFDUElDQTogdXNlIGRlc2lnbmF0ZWQgaW5p
dGlhbGl6ZXJzDQo+ID4+DQo+ID4+IFByZXBhcmUgdG8gbWFyayBzZW5zaXRpdmUga2VybmVsIHN0
cnVjdHVyZXMgZm9yIHJhbmRvbWl6YXRpb24gYnkgbWFraW5nDQo+ID4+IHN1cmUgdGhleSdyZSB1
c2luZyBkZXNpZ25hdGVkIGluaXRpYWxpemVycy4gVGhlc2Ugd2VyZSBpZGVudGlmaWVkIGR1cmlu
Zw0KPiA+PiBhbGx5ZXNjb25maWcgYnVpbGRzIG9mIHg4NiwgYXJtLCBhbmQgYXJtNjQsIHdpdGgg
bW9zdCBpbml0aWFsaXplciBmaXhlcw0KPiA+PiBleHRyYWN0ZWQgZnJvbSBncnNlY3VyaXR5Lg0K
PiA+DQo+ID4gVGhpcyBjb21taXQgaXMgbm90IHN1aXRhYmxlIGZvciBBQ1BJQ0EgdXBzdHJlYW0u
DQo+ID4gSXQncyBub3QgcG9ydGFibGUuIFBsZWFzZSBkcm9wLg0KPiANCj4gV2hhdCBjb21waWxl
cnMgYXJlIGJ1aWxkaW5nIHRoaXMgdGhhdCBkbyBub3Qgc3VwcG9ydCBkZXNpZ25hdGVkDQo+IGlu
aXRpYWxpemVycz8gQWxzbywgY291bGRuJ3QgdGhpcyBiZSBtYWRlIGludG8gYSBtYWNybyBzbyBp
dCBjb3VsZCBiZQ0KPiBzdXBwb3J0ZWQgaW4gZWl0aGVyIGNhc2U/DQoNCkl0J3MgTVNWQy4NCklu
IEFDUElDQSB1cHN0cmVhbSwgaXQgc3VwcG9ydHMgSW50ZWwgY29tcGlsZXIsIEdDQyBhbmQgTVNW
Qy4NCg0KPiANCj4gI2lmZGVmIF9fR05VQ19fDQo+ICMgZGVmaW5lIEFDUElfU0xFRVBfRlVOQ1RJ
T05TKGxlZ2FjeSwgZXh0ZW5kZWQpIHsgXA0KPiAgICAgLmxlZ2FjeV9mdW5jdGlvbiA9IGxlZ2Fj
eSwgXA0KPiAgICAgLmV4dGVuZGVkX2Z1bmN0aW9uID0gZXh0ZW5kZWQsIFwNCj4gfQ0KPiAjZWxz
ZQ0KPiAjIGRlZmluZSBBQ1BJX1NMRUVQX0ZVTkNUSU9OUyhsZWdhY3ksIGV4dGVuZGVkKSB7IGxl
Z2FjeSwgZXh0ZW5kZWQgfQ0KPiAjZW5kaWYNCj4gDQo+IC4uLg0KPiANCj4gIHN0YXRpYyBzdHJ1
Y3QgYWNwaV9zbGVlcF9mdW5jdGlvbnMgYWNwaV9zbGVlcF9kaXNwYXRjaFtdID0gew0KPiAgICAg
ICAgIEFDUElfU0xFRVBfRlVOQ1RJT05TKA0KPiAgICAgICAgICAgICAgICBBQ1BJX0hXX09QVElP
TkFMX0ZVTkNUSU9OKGFjcGlfaHdfbGVnYWN5X3NsZWVwKSwNCj4gICAgICAgICAgICAgICAgYWNw
aV9od19leHRlbmRlZF9zbGVlcCksDQo+IC4uLg0KDQpUaGVyZSBhcmUgbWFueSBzdWNoIGNhc2Vz
IGluIEFDUElDQSwgYW5kIEkgY291bGRuJ3Qgc2VlIHRoZSBiZW5lZml0IHRvIGludHJvZHVjZSBz
dWNoIG1lY2hhbmlzbSB0byBzdWNoIGEgc29mdHdhcmUgd2hvc2UgcHVycG9zZXMgY29udGFpbiBw
b3J0YWJpbGl0eS4NClVubGVzcyB5b3UgY2FuIGludmVudCBhIG1lY2hhbmlzbSB0aGF0IGNhbiBi
ZSB1dGlsaXplZCBieSBhbGwgc3VjaCBjYXNlcy4NClRoZW4geW91IHNob3VsZCBwdXQgaXQgaW50
byBhY2djYy5oIGFuZCBpbXBsZW1lbnQgYSByZXBsYWNlYWJsZSBpbiBhY21zdmMuaC4NCkFmdGVy
IHRoYXQsIHlvdSBzdXJlbHkgbmVlZCB0byBkbyBhIGNsZWFudXAgaW4gdGhlIGVudGlyZSBBQ1BJ
Q0EgY29kZSBiYXNlIHVzaW5nIHRoaXMgbmV3IG1lY2hhbmlzbS4NCg0KVGhhbmtzDQpMdg0KDQo+
IA0KPiANCj4gLUtlZXMNCj4gDQo+ID4NCj4gPiBUaGFua3MNCj4gPiBMdg0KPiA+DQo+ID4+DQo+
ID4+IFNpZ25lZC1vZmYtYnk6IEtlZXMgQ29vayA8a2Vlc2Nvb2tAY2hyb21pdW0ub3JnPg0KPiA+
PiAtLS0NCj4gPj4gIGRyaXZlcnMvYWNwaS9hY3BpY2EvaHd4ZnNsZWVwLmMgfCAxMSArKysrKyst
LS0tLQ0KPiA+PiAgMSBmaWxlIGNoYW5nZWQsIDYgaW5zZXJ0aW9ucygrKSwgNSBkZWxldGlvbnMo
LSkNCj4gPj4NCj4gPj4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvYWNwaS9hY3BpY2EvaHd4ZnNsZWVw
LmMgYi9kcml2ZXJzL2FjcGkvYWNwaWNhL2h3eGZzbGVlcC5jDQo+ID4+IGluZGV4IGY3NmUwZWFi
MzJiOC4uMjVjZDVjNjZlMTAyIDEwMDY0NA0KPiA+PiAtLS0gYS9kcml2ZXJzL2FjcGkvYWNwaWNh
L2h3eGZzbGVlcC5jDQo+ID4+ICsrKyBiL2RyaXZlcnMvYWNwaS9hY3BpY2EvaHd4ZnNsZWVwLmMN
Cj4gPj4gQEAgLTcwLDExICs3MCwxMiBAQCBzdGF0aWMgYWNwaV9zdGF0dXMgYWNwaV9od19zbGVl
cF9kaXNwYXRjaCh1OCBzbGVlcF9zdGF0ZSwgdTMyIGZ1bmN0aW9uX2lkKTsNCj4gPj4gIC8qIExl
Z2FjeSBmdW5jdGlvbnMgYXJlIG9wdGlvbmFsLCBiYXNlZCB1cG9uIEFDUElfUkVEVUNFRF9IQVJE
V0FSRSAqLw0KPiA+Pg0KPiA+PiAgc3RhdGljIHN0cnVjdCBhY3BpX3NsZWVwX2Z1bmN0aW9ucyBh
Y3BpX3NsZWVwX2Rpc3BhdGNoW10gPSB7DQo+ID4+IC0gICAgIHtBQ1BJX0hXX09QVElPTkFMX0ZV
TkNUSU9OKGFjcGlfaHdfbGVnYWN5X3NsZWVwKSwNCj4gPj4gLSAgICAgIGFjcGlfaHdfZXh0ZW5k
ZWRfc2xlZXB9LA0KPiA+PiAtICAgICB7QUNQSV9IV19PUFRJT05BTF9GVU5DVElPTihhY3BpX2h3
X2xlZ2FjeV93YWtlX3ByZXApLA0KPiA+PiAtICAgICAgYWNwaV9od19leHRlbmRlZF93YWtlX3By
ZXB9LA0KPiA+PiAtICAgICB7QUNQSV9IV19PUFRJT05BTF9GVU5DVElPTihhY3BpX2h3X2xlZ2Fj
eV93YWtlKSwgYWNwaV9od19leHRlbmRlZF93YWtlfQ0KPiA+PiArICAgICB7IC5sZWdhY3lfZnVu
Y3Rpb24gPSBBQ1BJX0hXX09QVElPTkFMX0ZVTkNUSU9OKGFjcGlfaHdfbGVnYWN5X3NsZWVwKSwN
Cj4gPj4gKyAgICAgICAuZXh0ZW5kZWRfZnVuY3Rpb24gPSBhY3BpX2h3X2V4dGVuZGVkX3NsZWVw
IH0sDQo+ID4+ICsgICAgIHsgLmxlZ2FjeV9mdW5jdGlvbiA9IEFDUElfSFdfT1BUSU9OQUxfRlVO
Q1RJT04oYWNwaV9od19sZWdhY3lfd2FrZV9wcmVwKSwNCj4gPj4gKyAgICAgICAuZXh0ZW5kZWRf
ZnVuY3Rpb24gPSBhY3BpX2h3X2V4dGVuZGVkX3dha2VfcHJlcCB9LA0KPiA+PiArICAgICB7IC5s
ZWdhY3lfZnVuY3Rpb24gPSBBQ1BJX0hXX09QVElPTkFMX0ZVTkNUSU9OKGFjcGlfaHdfbGVnYWN5
X3dha2UpLA0KPiA+PiArICAgICAgIC5leHRlbmRlZF9mdW5jdGlvbiA9IGFjcGlfaHdfZXh0ZW5k
ZWRfd2FrZSB9DQo+ID4+ICB9Ow0KPiA+Pg0KPiA+PiAgLyoNCj4gPj4gLS0NCj4gPj4gMi43LjQN
Cj4gPj4NCj4gPj4NCj4gPj4gLS0NCj4gPj4gS2VlcyBDb29rDQo+ID4+IE5leHVzIFNlY3VyaXR5
DQo+IA0KPiANCj4gDQo+IC0tDQo+IEtlZXMgQ29vaw0KPiBQaXhlbCBTZWN1cml0eQ0K
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Moore, Robert March 30, 2017, 2:26 p.m. UTC | #5
WWVzLCBBQ1BJQ0EgbXVzdCBzdXBwb3J0IG1hbnkgY29tcGlsZXJzLCBzbyB3ZSBrZWVwIHRoZSBj
b2RlIGFzIHNpbXBsZSBhcyBwb3NzaWJsZS4NCg0KTWFueSBvZiB0aGUgY29ycG9yYXRlIE9TIHZl
bmRvcnMgdXNlIHRoZWlyIG93biBjb21waWxlcnMuDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh
Z2UtLS0tLQ0KPiBGcm9tOiBaaGVuZywgTHYNCj4gU2VudDogV2VkbmVzZGF5LCBNYXJjaCAyOSwg
MjAxNyA3OjEyIFBNDQo+IFRvOiBLZWVzIENvb2sgPGtlZXNjb29rQGNocm9taXVtLm9yZz4NCj4g
Q2M6IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IE1vb3JlLCBSb2JlcnQNCj4gPHJvYmVy
dC5tb29yZUBpbnRlbC5jb20+OyBXeXNvY2tpLCBSYWZhZWwgSg0KPiA8cmFmYWVsLmoud3lzb2Nr
aUBpbnRlbC5jb20+OyBMZW4gQnJvd24gPGxlbmJAa2VybmVsLm9yZz47IGxpbnV4LQ0KPiBhY3Bp
QHZnZXIua2VybmVsLm9yZzsgZGV2ZWxAYWNwaWNhLm9yZw0KPiBTdWJqZWN0OiBSRTogW1BBVENI
XSBBQ1BJQ0E6IHVzZSBkZXNpZ25hdGVkIGluaXRpYWxpemVycw0KPiANCj4gSGksDQo+IA0KPiA+
IEZyb206IGtlZXNjb29rQGdvb2dsZS5jb20gW21haWx0bzprZWVzY29va0Bnb29nbGUuY29tXSBP
biBCZWhhbGYgT2YNCj4gPiBLZWVzIENvb2sNCj4gPiBTdWJqZWN0OiBSZTogW1BBVENIXSBBQ1BJ
Q0E6IHVzZSBkZXNpZ25hdGVkIGluaXRpYWxpemVycw0KPiA+DQo+ID4gT24gU3VuLCBEZWMgMTgs
IDIwMTYgYXQgMTA6MDYgUE0sIFpoZW5nLCBMdiA8bHYuemhlbmdAaW50ZWwuY29tPg0KPiB3cm90
ZToNCj4gPiA+IEhpLA0KPiA+ID4NCj4gPiA+PiBGcm9tOiBLZWVzIENvb2sgW21haWx0bzprZWVz
Y29va0BjaHJvbWl1bS5vcmddDQo+ID4gPj4gU3ViamVjdDogW1BBVENIXSBBQ1BJQ0E6IHVzZSBk
ZXNpZ25hdGVkIGluaXRpYWxpemVycw0KPiA+ID4+DQo+ID4gPj4gUHJlcGFyZSB0byBtYXJrIHNl
bnNpdGl2ZSBrZXJuZWwgc3RydWN0dXJlcyBmb3IgcmFuZG9taXphdGlvbiBieQ0KPiA+ID4+IG1h
a2luZyBzdXJlIHRoZXkncmUgdXNpbmcgZGVzaWduYXRlZCBpbml0aWFsaXplcnMuIFRoZXNlIHdl
cmUNCj4gPiA+PiBpZGVudGlmaWVkIGR1cmluZyBhbGx5ZXNjb25maWcgYnVpbGRzIG9mIHg4Niwg
YXJtLCBhbmQgYXJtNjQsIHdpdGgNCj4gPiA+PiBtb3N0IGluaXRpYWxpemVyIGZpeGVzIGV4dHJh
Y3RlZCBmcm9tIGdyc2VjdXJpdHkuDQo+ID4gPg0KPiA+ID4gVGhpcyBjb21taXQgaXMgbm90IHN1
aXRhYmxlIGZvciBBQ1BJQ0EgdXBzdHJlYW0uDQo+ID4gPiBJdCdzIG5vdCBwb3J0YWJsZS4gUGxl
YXNlIGRyb3AuDQo+ID4NCj4gPiBXaGF0IGNvbXBpbGVycyBhcmUgYnVpbGRpbmcgdGhpcyB0aGF0
IGRvIG5vdCBzdXBwb3J0IGRlc2lnbmF0ZWQNCj4gPiBpbml0aWFsaXplcnM/IEFsc28sIGNvdWxk
bid0IHRoaXMgYmUgbWFkZSBpbnRvIGEgbWFjcm8gc28gaXQgY291bGQgYmUNCj4gPiBzdXBwb3J0
ZWQgaW4gZWl0aGVyIGNhc2U/DQo+IA0KPiBJdCdzIE1TVkMuDQo+IEluIEFDUElDQSB1cHN0cmVh
bSwgaXQgc3VwcG9ydHMgSW50ZWwgY29tcGlsZXIsIEdDQyBhbmQgTVNWQy4NCj4gDQo+ID4NCj4g
PiAjaWZkZWYgX19HTlVDX18NCj4gPiAjIGRlZmluZSBBQ1BJX1NMRUVQX0ZVTkNUSU9OUyhsZWdh
Y3ksIGV4dGVuZGVkKSB7IFwNCj4gPiAgICAgLmxlZ2FjeV9mdW5jdGlvbiA9IGxlZ2FjeSwgXA0K
PiA+ICAgICAuZXh0ZW5kZWRfZnVuY3Rpb24gPSBleHRlbmRlZCwgXA0KPiA+IH0NCj4gPiAjZWxz
ZQ0KPiA+ICMgZGVmaW5lIEFDUElfU0xFRVBfRlVOQ1RJT05TKGxlZ2FjeSwgZXh0ZW5kZWQpIHsg
bGVnYWN5LCBleHRlbmRlZCB9DQo+ID4gI2VuZGlmDQo+ID4NCj4gPiAuLi4NCj4gPg0KPiA+ICBz
dGF0aWMgc3RydWN0IGFjcGlfc2xlZXBfZnVuY3Rpb25zIGFjcGlfc2xlZXBfZGlzcGF0Y2hbXSA9
IHsNCj4gPiAgICAgICAgIEFDUElfU0xFRVBfRlVOQ1RJT05TKA0KPiA+ICAgICAgICAgICAgICAg
IEFDUElfSFdfT1BUSU9OQUxfRlVOQ1RJT04oYWNwaV9od19sZWdhY3lfc2xlZXApLA0KPiA+ICAg
ICAgICAgICAgICAgIGFjcGlfaHdfZXh0ZW5kZWRfc2xlZXApLCAuLi4NCj4gDQo+IFRoZXJlIGFy
ZSBtYW55IHN1Y2ggY2FzZXMgaW4gQUNQSUNBLCBhbmQgSSBjb3VsZG4ndCBzZWUgdGhlIGJlbmVm
aXQgdG8NCj4gaW50cm9kdWNlIHN1Y2ggbWVjaGFuaXNtIHRvIHN1Y2ggYSBzb2Z0d2FyZSB3aG9z
ZSBwdXJwb3NlcyBjb250YWluDQo+IHBvcnRhYmlsaXR5Lg0KPiBVbmxlc3MgeW91IGNhbiBpbnZl
bnQgYSBtZWNoYW5pc20gdGhhdCBjYW4gYmUgdXRpbGl6ZWQgYnkgYWxsIHN1Y2gNCj4gY2FzZXMu
DQo+IFRoZW4geW91IHNob3VsZCBwdXQgaXQgaW50byBhY2djYy5oIGFuZCBpbXBsZW1lbnQgYSBy
ZXBsYWNlYWJsZSBpbg0KPiBhY21zdmMuaC4NCj4gQWZ0ZXIgdGhhdCwgeW91IHN1cmVseSBuZWVk
IHRvIGRvIGEgY2xlYW51cCBpbiB0aGUgZW50aXJlIEFDUElDQSBjb2RlDQo+IGJhc2UgdXNpbmcg
dGhpcyBuZXcgbWVjaGFuaXNtLg0KPiANCj4gVGhhbmtzDQo+IEx2DQo+IA0KPiA+DQo+ID4NCj4g
PiAtS2Vlcw0KPiA+DQo+ID4gPg0KPiA+ID4gVGhhbmtzDQo+ID4gPiBMdg0KPiA+ID4NCj4gPiA+
Pg0KPiA+ID4+IFNpZ25lZC1vZmYtYnk6IEtlZXMgQ29vayA8a2Vlc2Nvb2tAY2hyb21pdW0ub3Jn
Pg0KPiA+ID4+IC0tLQ0KPiA+ID4+ICBkcml2ZXJzL2FjcGkvYWNwaWNhL2h3eGZzbGVlcC5jIHwg
MTEgKysrKysrLS0tLS0NCj4gPiA+PiAgMSBmaWxlIGNoYW5nZWQsIDYgaW5zZXJ0aW9ucygrKSwg
NSBkZWxldGlvbnMoLSkNCj4gPiA+Pg0KPiA+ID4+IGRpZmYgLS1naXQgYS9kcml2ZXJzL2FjcGkv
YWNwaWNhL2h3eGZzbGVlcC5jDQo+ID4gPj4gYi9kcml2ZXJzL2FjcGkvYWNwaWNhL2h3eGZzbGVl
cC5jIGluZGV4IGY3NmUwZWFiMzJiOC4uMjVjZDVjNjZlMTAyDQo+ID4gPj4gMTAwNjQ0DQo+ID4g
Pj4gLS0tIGEvZHJpdmVycy9hY3BpL2FjcGljYS9od3hmc2xlZXAuYw0KPiA+ID4+ICsrKyBiL2Ry
aXZlcnMvYWNwaS9hY3BpY2EvaHd4ZnNsZWVwLmMNCj4gPiA+PiBAQCAtNzAsMTEgKzcwLDEyIEBA
IHN0YXRpYyBhY3BpX3N0YXR1cyBhY3BpX2h3X3NsZWVwX2Rpc3BhdGNoKHU4DQo+ID4gPj4gc2xl
ZXBfc3RhdGUsIHUzMiBmdW5jdGlvbl9pZCk7DQo+ID4gPj4gIC8qIExlZ2FjeSBmdW5jdGlvbnMg
YXJlIG9wdGlvbmFsLCBiYXNlZCB1cG9uIEFDUElfUkVEVUNFRF9IQVJEV0FSRQ0KPiA+ID4+ICov
DQo+ID4gPj4NCj4gPiA+PiAgc3RhdGljIHN0cnVjdCBhY3BpX3NsZWVwX2Z1bmN0aW9ucyBhY3Bp
X3NsZWVwX2Rpc3BhdGNoW10gPSB7DQo+ID4gPj4gLSAgICAge0FDUElfSFdfT1BUSU9OQUxfRlVO
Q1RJT04oYWNwaV9od19sZWdhY3lfc2xlZXApLA0KPiA+ID4+IC0gICAgICBhY3BpX2h3X2V4dGVu
ZGVkX3NsZWVwfSwNCj4gPiA+PiAtICAgICB7QUNQSV9IV19PUFRJT05BTF9GVU5DVElPTihhY3Bp
X2h3X2xlZ2FjeV93YWtlX3ByZXApLA0KPiA+ID4+IC0gICAgICBhY3BpX2h3X2V4dGVuZGVkX3dh
a2VfcHJlcH0sDQo+ID4gPj4gLSAgICAge0FDUElfSFdfT1BUSU9OQUxfRlVOQ1RJT04oYWNwaV9o
d19sZWdhY3lfd2FrZSksDQo+IGFjcGlfaHdfZXh0ZW5kZWRfd2FrZX0NCj4gPiA+PiArICAgICB7
IC5sZWdhY3lfZnVuY3Rpb24gPQ0KPiBBQ1BJX0hXX09QVElPTkFMX0ZVTkNUSU9OKGFjcGlfaHdf
bGVnYWN5X3NsZWVwKSwNCj4gPiA+PiArICAgICAgIC5leHRlbmRlZF9mdW5jdGlvbiA9IGFjcGlf
aHdfZXh0ZW5kZWRfc2xlZXAgfSwNCj4gPiA+PiArICAgICB7IC5sZWdhY3lfZnVuY3Rpb24gPQ0K
PiBBQ1BJX0hXX09QVElPTkFMX0ZVTkNUSU9OKGFjcGlfaHdfbGVnYWN5X3dha2VfcHJlcCksDQo+
ID4gPj4gKyAgICAgICAuZXh0ZW5kZWRfZnVuY3Rpb24gPSBhY3BpX2h3X2V4dGVuZGVkX3dha2Vf
cHJlcCB9LA0KPiA+ID4+ICsgICAgIHsgLmxlZ2FjeV9mdW5jdGlvbiA9DQo+IEFDUElfSFdfT1BU
SU9OQUxfRlVOQ1RJT04oYWNwaV9od19sZWdhY3lfd2FrZSksDQo+ID4gPj4gKyAgICAgICAuZXh0
ZW5kZWRfZnVuY3Rpb24gPSBhY3BpX2h3X2V4dGVuZGVkX3dha2UgfQ0KPiA+ID4+ICB9Ow0KPiA+
ID4+DQo+ID4gPj4gIC8qDQo+ID4gPj4gLS0NCj4gPiA+PiAyLjcuNA0KPiA+ID4+DQo+ID4gPj4N
Cj4gPiA+PiAtLQ0KPiA+ID4+IEtlZXMgQ29vaw0KPiA+ID4+IE5leHVzIFNlY3VyaXR5DQo+ID4N
Cj4gPg0KPiA+DQo+ID4gLS0NCj4gPiBLZWVzIENvb2sNCj4gPiBQaXhlbCBTZWN1cml0eQ0K
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Kees Cook April 1, 2017, 12:26 a.m. UTC | #6
On Wed, Mar 29, 2017 at 7:12 PM, Zheng, Lv <lv.zheng@intel.com> wrote:
> Hi,
>
>> From: keescook@google.com [mailto:keescook@google.com] On Behalf Of Kees Cook
>> Subject: Re: [PATCH] ACPICA: use designated initializers
>>
>> On Sun, Dec 18, 2016 at 10:06 PM, Zheng, Lv <lv.zheng@intel.com> wrote:
>> > Hi,
>> >
>> >> From: Kees Cook [mailto:keescook@chromium.org]
>> >> Subject: [PATCH] ACPICA: use designated initializers
>> >>
>> >> Prepare to mark sensitive kernel structures for randomization by making
>> >> sure they're using designated initializers. These were identified during
>> >> allyesconfig builds of x86, arm, and arm64, with most initializer fixes
>> >> extracted from grsecurity.
>> >
>> > This commit is not suitable for ACPICA upstream.
>> > It's not portable. Please drop.
>>
>> What compilers are building this that do not support designated
>> initializers? Also, couldn't this be made into a macro so it could be
>> supported in either case?
>
> It's MSVC.
> In ACPICA upstream, it supports Intel compiler, GCC and MSVC.
>
>>
>> #ifdef __GNUC__
>> # define ACPI_SLEEP_FUNCTIONS(legacy, extended) { \
>>     .legacy_function = legacy, \
>>     .extended_function = extended, \
>> }
>> #else
>> # define ACPI_SLEEP_FUNCTIONS(legacy, extended) { legacy, extended }
>> #endif
>>
>> ...
>>
>>  static struct acpi_sleep_functions acpi_sleep_dispatch[] = {
>>         ACPI_SLEEP_FUNCTIONS(
>>                ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_sleep),
>>                acpi_hw_extended_sleep),
>> ...
>
> There are many such cases in ACPICA, and I couldn't see the benefit to introduce such mechanism to such a software whose purposes contain portability.
> Unless you can invent a mechanism that can be utilized by all such cases.
> Then you should put it into acgcc.h and implement a replaceable in acmsvc.h.
> After that, you surely need to do a cleanup in the entire ACPICA code base using this new mechanism.

This is only needed in a few cases, so I think general solution would
be overkill. That said, it looks like MSVC supports designated
initializers. Are people building this with especially old compilers?

-Kees

>
> Thanks
> Lv
>
>>
>>
>> -Kees
>>
>> >
>> > Thanks
>> > Lv
>> >
>> >>
>> >> Signed-off-by: Kees Cook <keescook@chromium.org>
>> >> ---
>> >>  drivers/acpi/acpica/hwxfsleep.c | 11 ++++++-----
>> >>  1 file changed, 6 insertions(+), 5 deletions(-)
>> >>
>> >> diff --git a/drivers/acpi/acpica/hwxfsleep.c b/drivers/acpi/acpica/hwxfsleep.c
>> >> index f76e0eab32b8..25cd5c66e102 100644
>> >> --- a/drivers/acpi/acpica/hwxfsleep.c
>> >> +++ b/drivers/acpi/acpica/hwxfsleep.c
>> >> @@ -70,11 +70,12 @@ static acpi_status acpi_hw_sleep_dispatch(u8 sleep_state, u32 function_id);
>> >>  /* Legacy functions are optional, based upon ACPI_REDUCED_HARDWARE */
>> >>
>> >>  static struct acpi_sleep_functions acpi_sleep_dispatch[] = {
>> >> -     {ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_sleep),
>> >> -      acpi_hw_extended_sleep},
>> >> -     {ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake_prep),
>> >> -      acpi_hw_extended_wake_prep},
>> >> -     {ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake), acpi_hw_extended_wake}
>> >> +     { .legacy_function = ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_sleep),
>> >> +       .extended_function = acpi_hw_extended_sleep },
>> >> +     { .legacy_function = ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake_prep),
>> >> +       .extended_function = acpi_hw_extended_wake_prep },
>> >> +     { .legacy_function = ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake),
>> >> +       .extended_function = acpi_hw_extended_wake }
>> >>  };
>> >>
>> >>  /*
>> >> --
>> >> 2.7.4
>> >>
>> >>
>> >> --
>> >> Kees Cook
>> >> Nexus Security
>>
>>
>>
>> --
>> Kees Cook
>> Pixel Security
Moore, Robert April 1, 2017, 12:45 a.m. UTC | #7
Acpica is built with many compilers, even very old ones. It runs on at least 12 known operating systems, and very probably more.

I'm sorry, but no, we are not going to start adding compiler-specific ifdefs/code in the base ACPICA code.

I don't care what you do in the Linux-specific or gcc-specific headers, however. If this breaks a customer build, we (you) will hear about it rather quickly.

Bob
Kees Cook April 3, 2017, 5:29 p.m. UTC | #8
On Fri, Mar 31, 2017 at 5:45 PM, Moore, Robert <robert.moore@intel.com> wrote:
> Acpica is built with many compilers, even very old ones. It runs on at least 12 known operating systems, and very probably more.
>
> I'm sorry, but no, we are not going to start adding compiler-specific ifdefs/code in the base ACPICA code.
>
> I don't care what you do in the Linux-specific or gcc-specific headers, however. If this breaks a customer build, we (you) will hear about it rather quickly.

Since the change is specific to the one place ACPICA uses an
all-function-pointer structure, I made the change local:

https://github.com/acpica/acpica/pull/248

would you rather this is in the .h files instead?

-Kees
Moore, Robert April 4, 2017, 3:02 p.m. UTC | #9
> -----Original Message-----

> From: keescook@google.com [mailto:keescook@google.com] On Behalf Of Kees

> Cook

> Sent: Monday, April 3, 2017 10:29 AM

> To: Moore, Robert <robert.moore@intel.com>

> Cc: Zheng, Lv <lv.zheng@intel.com>; linux-kernel@vger.kernel.org;

> Wysocki, Rafael J <rafael.j.wysocki@intel.com>; Len Brown

> <lenb@kernel.org>; linux-acpi@vger.kernel.org; devel@acpica.org

> Subject: Re: [PATCH] ACPICA: use designated initializers

> 

> On Fri, Mar 31, 2017 at 5:45 PM, Moore, Robert <robert.moore@intel.com>

> wrote:

> > Acpica is built with many compilers, even very old ones. It runs on at

> least 12 known operating systems, and very probably more.

> >

> > I'm sorry, but no, we are not going to start adding compiler-specific

> ifdefs/code in the base ACPICA code.

> >

> > I don't care what you do in the Linux-specific or gcc-specific

> headers, however. If this breaks a customer build, we (you) will hear

> about it rather quickly.

> 

> Since the change is specific to the one place ACPICA uses an all-

> function-pointer structure, I made the change local:

> 

> https://github.com/acpica/acpica/pull/248

> 

> would you rather this is in the .h files instead?

> 

> -Kees

> 

> --

> Kees Cook

> Pixel Security





[Moore, Robert] 

I have some questions about this entire issue:

+ * Some compilers can handle designated initializers, which is needed  
+ * under Linux kernel builds for structures that are entirely function  
  * pointers.  

I don't understand why this is coming up now, since ACPICA has been integrated with Linux for something like the last 15 years. It's the "which is needed under Linux kernel builds" wording that concerns me the most. Are you saying that the ACPICA build for Linux is broken and does not work?

Further, there are quite a few similar dispatch tables in ACPICA, why are these not a problem?

Bob
Kees Cook April 4, 2017, 3:55 p.m. UTC | #10
On Tue, Apr 4, 2017 at 8:02 AM, Moore, Robert <robert.moore@intel.com> wrote:
>> -----Original Message-----
>> From: keescook@google.com [mailto:keescook@google.com] On Behalf Of Kees
>> Cook
>> Sent: Monday, April 3, 2017 10:29 AM
>> To: Moore, Robert <robert.moore@intel.com>
>> Cc: Zheng, Lv <lv.zheng@intel.com>; linux-kernel@vger.kernel.org;
>> Wysocki, Rafael J <rafael.j.wysocki@intel.com>; Len Brown
>> <lenb@kernel.org>; linux-acpi@vger.kernel.org; devel@acpica.org
>> Subject: Re: [PATCH] ACPICA: use designated initializers
>>
>> On Fri, Mar 31, 2017 at 5:45 PM, Moore, Robert <robert.moore@intel.com>
>> wrote:
>> > Acpica is built with many compilers, even very old ones. It runs on at
>> least 12 known operating systems, and very probably more.
>> >
>> > I'm sorry, but no, we are not going to start adding compiler-specific
>> ifdefs/code in the base ACPICA code.
>> >
>> > I don't care what you do in the Linux-specific or gcc-specific
>> headers, however. If this breaks a customer build, we (you) will hear
>> about it rather quickly.
>>
>> Since the change is specific to the one place ACPICA uses an all-
>> function-pointer structure, I made the change local:
>>
>> https://github.com/acpica/acpica/pull/248
>>
>> would you rather this is in the .h files instead?
>>
>> -Kees
>>
>> --
>> Kees Cook
>> Pixel Security
>
>
>
>
> [Moore, Robert]
>
> I have some questions about this entire issue:
>
> + * Some compilers can handle designated initializers, which is needed
> + * under Linux kernel builds for structures that are entirely function
>   * pointers.
>
> I don't understand why this is coming up now, since ACPICA has been integrated with Linux for something like the last 15 years. It's the "which is needed under Linux kernel builds" wording that concerns me the most. Are you saying that the ACPICA build for Linux is broken and does not work?

I was trying to avoid being overly Linux-specific in the ACPICA commit
message. More accurately, this is "for future Linux builds using the
structure layout randomization plugin." That plugin will randomize the
layout of manually marked structures and automatically for structures
that are entirely function pointers. (And this acpica structure is one
noticed by the plugin.)

> Further, there are quite a few similar dispatch tables in ACPICA, why are these not a problem?

I can double-check, but I think this was the only one that showed up
in an x86 allyesconfig with the plugin enabled.

FWIW, I've been making these changes in lots of places, not just
ACPICA. ACPICA just has external requirements. :P

$ git log --oneline v4.9..next-20170404 | grep -i "designated initializers"
b3c829193253 reiserfs: use designated initializers
8291798dcf05 TOMOYO: Use designated initializers
f231aebfc4ca rbtree: use designated initializers
c4d27f4b4dc9 [media] solo6x10: use designated initializers
6351db2b4df3 [media] mtk-vcodec: use designated initializers
613e61a0252c drm/amdgpu: use designated initializers
8486adf0d755 apparmor: use designated initializers
7f6856b789ff RDMA/i40iw: use designated initializers
6554c9f7f749 RDMA/nes: use designated initializers
a641261e9998 video: fbdev: matroxfb: use designated initializers
6895aff47170 video: fbdev: sh_mobile_lcdcfb: use designated initializers
54e22bbf11ca staging: comedi: daqboard2000: use designated initializers
5f5fca6db3d3 scsi: cciss: use designated initializers
93380123fbb5 scsi: hpsa: use designated initializers
2fd2434c3f47 staging: lustre: ldlm: use designated initializers
f93a1c9e5e6a ALSA: synth: use designated initializers
2fa70bb9b564 drm/nouveau: use designated initializers
5ca16d8efa66 drm/vmwgfx: use designated initializers
4e98c378a137 drm/ttm: use designated initializers
c92f72370571 drm/ttm: use designated initializers
ffc7dc8d838c x86/floppy: Use designated initializers
e999cb43d51f net/x25: use designated initializers
ebf12f1320c7 isdn: use designated initializers
9751362a4fe7 bna: use designated initializers
aabd7ad94924 WAN: use designated initializers
9d1c0ca5e1d6 net: use designated initializers
99a5e178bde4 ATM: use designated initializers
4794195058b9 isdn/gigaset: use designated initializers


-Kees
Kees Cook May 8, 2017, 8:05 p.m. UTC | #11
On Tue, Apr 4, 2017 at 8:55 AM, Kees Cook <keescook@chromium.org> wrote:
> On Tue, Apr 4, 2017 at 8:02 AM, Moore, Robert <robert.moore@intel.com> wrote:
>>> -----Original Message-----
>>> From: keescook@google.com [mailto:keescook@google.com] On Behalf Of Kees
>>> Cook
>>> Sent: Monday, April 3, 2017 10:29 AM
>>> To: Moore, Robert <robert.moore@intel.com>
>>> Cc: Zheng, Lv <lv.zheng@intel.com>; linux-kernel@vger.kernel.org;
>>> Wysocki, Rafael J <rafael.j.wysocki@intel.com>; Len Brown
>>> <lenb@kernel.org>; linux-acpi@vger.kernel.org; devel@acpica.org
>>> Subject: Re: [PATCH] ACPICA: use designated initializers
>>>
>>> On Fri, Mar 31, 2017 at 5:45 PM, Moore, Robert <robert.moore@intel.com>
>>> wrote:
>>> > Acpica is built with many compilers, even very old ones. It runs on at
>>> least 12 known operating systems, and very probably more.
>>> >
>>> > I'm sorry, but no, we are not going to start adding compiler-specific
>>> ifdefs/code in the base ACPICA code.
>>> >
>>> > I don't care what you do in the Linux-specific or gcc-specific
>>> headers, however. If this breaks a customer build, we (you) will hear
>>> about it rather quickly.
>>>
>>> Since the change is specific to the one place ACPICA uses an all-
>>> function-pointer structure, I made the change local:
>>>
>>> https://github.com/acpica/acpica/pull/248
>>>
>>> would you rather this is in the .h files instead?
>>>
>>> -Kees
>>>
>>> --
>>> Kees Cook
>>> Pixel Security
>>
>>
>>
>>
>> [Moore, Robert]
>>
>> I have some questions about this entire issue:
>>
>> + * Some compilers can handle designated initializers, which is needed
>> + * under Linux kernel builds for structures that are entirely function
>>   * pointers.
>>
>> I don't understand why this is coming up now, since ACPICA has been integrated with Linux for something like the last 15 years. It's the "which is needed under Linux kernel builds" wording that concerns me the most. Are you saying that the ACPICA build for Linux is broken and does not work?
>
> I was trying to avoid being overly Linux-specific in the ACPICA commit
> message. More accurately, this is "for future Linux builds using the
> structure layout randomization plugin." That plugin will randomize the
> layout of manually marked structures and automatically for structures
> that are entirely function pointers. (And this acpica structure is one
> noticed by the plugin.)

Here is the merge request in upstream ACPICA. Can anyone re-review it?

https://github.com/acpica/acpica/pull/248/

Thanks!

-Kees
diff mbox

Patch

diff --git a/drivers/acpi/acpica/hwxfsleep.c b/drivers/acpi/acpica/hwxfsleep.c
index f76e0eab32b8..25cd5c66e102 100644
--- a/drivers/acpi/acpica/hwxfsleep.c
+++ b/drivers/acpi/acpica/hwxfsleep.c
@@ -70,11 +70,12 @@  static acpi_status acpi_hw_sleep_dispatch(u8 sleep_state, u32 function_id);
 /* Legacy functions are optional, based upon ACPI_REDUCED_HARDWARE */
 
 static struct acpi_sleep_functions acpi_sleep_dispatch[] = {
-	{ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_sleep),
-	 acpi_hw_extended_sleep},
-	{ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake_prep),
-	 acpi_hw_extended_wake_prep},
-	{ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake), acpi_hw_extended_wake}
+	{ .legacy_function = ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_sleep),
+	  .extended_function = acpi_hw_extended_sleep },
+	{ .legacy_function = ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake_prep),
+	  .extended_function = acpi_hw_extended_wake_prep },
+	{ .legacy_function = ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake),
+	  .extended_function = acpi_hw_extended_wake }
 };
 
 /*