linux-kernel - Re: [PATCH 04/32] ACPI: sleep: Update acpi_set_firmware_waking_vector() invocations to favor 32-bit firmware waking vector.

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]

Date:	Sat, 20 Jun 2015 01:42:24 +0200
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Lv Zheng <lv.zheng@...el.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Len Brown <len.brown@...el.com>, Lv Zheng <zetalog@...il.com>,
	linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	Tony Luck <tony.luck@...el.com>,
	Fenghua Yu <fenghua.yu@...el.com>, linux-ia64@...r.kernel.org
Subject: Re: [PATCH 04/32] ACPI: sleep: Update acpi_set_firmware_waking_vector() invocations to favor 32-bit firmware waking vector.

On Friday, June 19, 2015 08:26:31 AM Ingo Molnar wrote:
> 
> * Lv Zheng <lv.zheng@...el.com> wrote:
> 
> > This patch updates acpi_set_firmware_waking_vector() invocations in order
> > to keep 32-bit firmware waking vector favor for Linux.
> 
> This sentence does not parse.
> 
> > 64-bit firmware waking vector has never been enabled by Linux.  The
> > (acpi_physical_address)0 for 64-bit address can be used to force ACPICA to
> > set only 32-bit firmware waking vector for Linux.
> 
> So this is a change that affects a lot of systems - what is the expected 
> compatibility of this? Does Windows enable the 64-bit address? Which versions of 
> Windows?
> 
> > 
> > Reference: https://bugzilla.kernel.org/show_bug.cgi?id=74021
> > Reported-and-tested-by: Oswald Buddenhagen <ossi@....org>
> > Signed-off-by: Lv Zheng <lv.zheng@...el.com>
> > Cc: Thomas Gleixner <tglx@...utronix.de>
> > Cc: Ingo Molnar <mingo@...hat.com>
> > Cc: "H. Peter Anvin" <hpa@...or.com>
> > Cc: x86@...nel.org
> > Cc: Tony Luck <tony.luck@...el.com>
> > Cc: Fenghua Yu <fenghua.yu@...el.com>
> > Cc: linux-ia64@...r.kernel.org
> > ---
> >  arch/ia64/include/asm/acpi.h |    3 ++-
> >  arch/ia64/kernel/acpi.c      |    2 --
> >  arch/x86/include/asm/acpi.h  |    3 ++-
> >  drivers/acpi/sleep.c         |    8 ++++++--
> >  4 files changed, 10 insertions(+), 6 deletions(-)
> > 
> > diff --git a/arch/ia64/include/asm/acpi.h b/arch/ia64/include/asm/acpi.h
> > index aa0fdf1..0ac4fab 100644
> > --- a/arch/ia64/include/asm/acpi.h
> > +++ b/arch/ia64/include/asm/acpi.h
> > @@ -79,7 +79,8 @@ int acpi_gsi_to_irq (u32 gsi, unsigned int *irq);
> >  /* Low-level suspend routine. */
> >  extern int acpi_suspend_lowlevel(void);
> >  
> > -extern unsigned long acpi_wakeup_address;
> > +#define acpi_wakeup_address	((acpi_physical_address)0)
> > +#define acpi_wakeup_address64	((acpi_physical_address)0)
> >  
> >  /*
> >   * Record the cpei override flag and current logical cpu. This is
> > diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c
> > index b1698bc..1b08d6f 100644
> > --- a/arch/ia64/kernel/acpi.c
> > +++ b/arch/ia64/kernel/acpi.c
> > @@ -60,8 +60,6 @@ int acpi_lapic;
> >  unsigned int acpi_cpei_override;
> >  unsigned int acpi_cpei_phys_cpuid;
> >  
> > -unsigned long acpi_wakeup_address = 0;
> > -
> >  #ifdef CONFIG_IA64_GENERIC
> >  static unsigned long __init acpi_find_rsdp(void)
> >  {
> > diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
> > index 3a45668..fc9608d 100644
> > --- a/arch/x86/include/asm/acpi.h
> > +++ b/arch/x86/include/asm/acpi.h
> > @@ -72,7 +72,8 @@ static inline void acpi_disable_pci(void)
> >  extern int (*acpi_suspend_lowlevel)(void);
> >  
> >  /* Physical address to resume after wakeup */
> > -#define acpi_wakeup_address ((unsigned long)(real_mode_header->wakeup_start))
> > +#define acpi_wakeup_address	((acpi_physical_address)(real_mode_header->wakeup_start))
> > +#define acpi_wakeup_address64	((acpi_physical_address)(0))
> 
> Btw., 'acpi_physical_address' is a mouthful, and despite being a data type, it 
> looks like a variable name. Please rename it to something more sensible, matching 
> existing physical address patterns, like 'acpi_phys_addr_t'.

This is an ACPICA data type which means that it is used by multiple OSes, not only
by Linux.  We're just a user here. :-)


> Also, is there any reason why it's not simply phys_addr_t? It's not like ACPI has 
> a different notion of physical addresses.

Portability between different OSes is the reason.


> > diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
> > index 2f0d4db..3a6a2eb 100644
> > --- a/drivers/acpi/sleep.c
> > +++ b/drivers/acpi/sleep.c
> > @@ -25,6 +25,8 @@
> >  #include "internal.h"
> >  #include "sleep.h"
> >  
> > +#define ACPI_NO_WAKING_VECTOR		((acpi_physical_address)0)
> 
> So in x86 speak, 'vectors' are the things that drive interrupts. They are not 
> addresses. So calling it a 'vector' is a misnomer - it's a wakeup entry address 
> point.

But it is called "the waking vector" by the spec, so the naming here follows
the spec.


> Secondly, when the 64-bit entry point is configured, in what mode does the 
> firmware enter it - still real mode? Exactly what are the semantics when the 
> 64-bit entry point is set?

It can't do that in real mode, because the 64-bit one is only supposed to be
used when the entry point is above 4 GB in the physical address space.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/