lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1AE640813FDE7649BE1B193DEA596E88024950FD@SHSMSX101.ccr.corp.intel.com>
Date:	Fri, 6 Dec 2013 15:01:06 +0000
From:	"Zheng, Lv" <lv.zheng@...el.com>
To:	"Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
	"Brown, Len" <len.brown@...el.com>
CC:	Lv Zheng <zetalog@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	Konrad Rzeszutek Wilk <konrad@...nel.org>,
	Peter Jones <pjones@...hat.com>
Subject: RE: [PATCH v3 6/6] ACPI/IBFT: Fix wrong <acpi/acpi.h> inclusion in
 iSCSI boot firmware module.

> From: Zheng, Lv
> Sent: Friday, December 06, 2013 4:52 PM
> 
> In Linux kernel, ACPICA is wrapped and safely exported by CONFIG_ACPI.  So
> all external modules should depend on CONFIG_ACPI rather than using ACPICA
> header directly for stubbing.  But if we moves <acpi/acpi.h> inclusions
> into "#ifdef CONFIG_ACPI", build breakge can help to detect wrong ACPICA
> dependent modules.
> 
> One of the build breakage is:
> drivers/firmware/iscsi_ibft_find.c: In function 'find_ibft_region':
> drivers/firmware/iscsi_ibft_find.c:106:12: error: dereferencing pointer to incomplete type
> drivers/firmware/iscsi_ibft_find.c:106:12: error: dereferencing pointer to incomplete type
> drivers/firmware/iscsi_ibft_find.c:106:12: error: dereferencing pointer to incomplete type
> 
> The root cause of this breakage is:
> 1. iBFT locating is implemented by looking up it in the memory.  This is
>    based on the specification.  Specification doesn't mention if it can
>    appear on a non-ACPI platforms but mentions it is defined in ACPI 3.0b.
>    The current CONFIG_ISCSI_IBFT_FIND doesn't use ACPI table APIs to locate
>    the table, thus it doesn't rely on CONFIG_ACPI.
> 
> Since ACPI iSCSI Boot Firmware is an ACPI-based mechanism (please refer to
> the Doclink below), we can make CONFIG_ISCSI_IBFT_FIND dependent on
> CONFIG_ACPI though the locating mechanism can be implemented without using
> ACPI table APIs.  But please let me know if this is wrong.

Ping Konrad or Peter, will this fix mess up some situations?
Originally, this patch is marked as RFC.
But since I can see it in linux-pm/bleeding-edge branch and this patchset refreshes what have been accepted, I took the "RFC" off.

Thanks and best regards
-Lv

> 
> Doclink: http://www.microsoft.com/whdc/system/platform/firmware/ibft.mspx
> Cc: Konrad Rzeszutek Wilk <konrad@...nel.org>
> Cc: Peter Jones <pjones@...hat.com>
> Signed-off-by: Lv Zheng <lv.zheng@...el.com>
> ---
>  drivers/firmware/Kconfig   |    2 +-
>  include/linux/iscsi_ibft.h |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
> index 0747872..a6ef6ac 100644
> --- a/drivers/firmware/Kconfig
> +++ b/drivers/firmware/Kconfig
> @@ -110,7 +110,7 @@ config DMI_SYSFS
> 
>  config ISCSI_IBFT_FIND
>  	bool "iSCSI Boot Firmware Table Attributes"
> -	depends on X86
> +	depends on X86 && ACPI
>  	default n
>  	help
>  	  This option enables the kernel to find the region of memory
> diff --git a/include/linux/iscsi_ibft.h b/include/linux/iscsi_ibft.h
> index 82f9673..605cc5c 100644
> --- a/include/linux/iscsi_ibft.h
> +++ b/include/linux/iscsi_ibft.h
> @@ -21,7 +21,7 @@
>  #ifndef ISCSI_IBFT_H
>  #define ISCSI_IBFT_H
> 
> -#include <acpi/acpi.h>	/* FIXME: inclusion should be removed */
> +#include <linux/acpi.h>
> 
>  /*
>   * Logical location of iSCSI Boot Format Table.
> --
> 1.7.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ