From: "Rafael J. Wysocki" <rafael@kernel.org> To: platform-driver-x86@kernel.org, r.marek@assembler.cz, "open list:ACPI COMPONENT ARCHITECTURE (ACPICA)" <devel@acpica.org>, Ingo Molnar <mingo@redhat.com>, Robert Moore <robert.moore@intel.com>, linux-kernel@kernel.org, ACPI Devel Maling List <linux-acpi@vger.kernel.org> Cc: vit@kabele.me Subject: Re: [PATCH 1/3] platform/x86: Check validity of EBDA pointer in mpparse.c Date: Tue, 5 Apr 2022 15:11:17 +0200 [thread overview] Message-ID: <CAJZ5v0gBbdzUO9MRxbKESEnaeaNAu-+3oP6ADMretch=iHPNJA@mail.gmail.com> (raw) In-Reply-To: <YjM/yphbAQHxJIxg@czspare1-lap.sysgo.cz> First off, this is not platform/x86, but arch/x86. On Thu, Mar 17, 2022 at 3:12 PM Vit Kabele <vit@kabele.me> wrote: > > The pointer to EBDA area is retrieved from a word at 0x40e in BDA. > In case that the memory there is not initialized and contains garbage, > it might happen that the kernel touches memory above 640K. > > This may cause unwanted reads from VGA memory which may not be decoded, > or even present when running under virtualization. > > This patch adds sanity check for the EBDA pointer retrieved from the memory > so that scanning EBDA does not leave the low memory. > > Signed-off-by: Vit Kabele <vit@kabele.me> > Reviewed-by: Rudolf Marek <r.marek@assembler.cz> > --- > arch/x86/include/asm/bios_ebda.h | 3 +++ > arch/x86/kernel/ebda.c | 3 --- > arch/x86/kernel/mpparse.c | 12 +++++++++++- > 3 files changed, 14 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/include/asm/bios_ebda.h b/arch/x86/include/asm/bios_ebda.h > index 4d5a17e2febe..c3133c01d5b7 100644 > --- a/arch/x86/include/asm/bios_ebda.h > +++ b/arch/x86/include/asm/bios_ebda.h > @@ -4,6 +4,9 @@ > > #include <asm/io.h> > > +#define BIOS_START_MIN 0x20000U /* 128K, less than this is insane */ > +#define BIOS_START_MAX 0x9f000U /* 640K, absolute maximum */ > + > /* > * Returns physical address of EBDA. Returns 0 if there is no EBDA. > */ > diff --git a/arch/x86/kernel/ebda.c b/arch/x86/kernel/ebda.c > index 38e7d597b660..86c0801fc3ce 100644 > --- a/arch/x86/kernel/ebda.c > +++ b/arch/x86/kernel/ebda.c > @@ -50,9 +50,6 @@ > > #define BIOS_RAM_SIZE_KB_PTR 0x413 > > -#define BIOS_START_MIN 0x20000U /* 128K, less than this is insane */ > -#define BIOS_START_MAX 0x9f000U /* 640K, absolute maximum */ > - > void __init reserve_bios_regions(void) > { > unsigned int bios_start, ebda_start; > diff --git a/arch/x86/kernel/mpparse.c b/arch/x86/kernel/mpparse.c > index fed721f90116..6bba0744d32d 100644 > --- a/arch/x86/kernel/mpparse.c > +++ b/arch/x86/kernel/mpparse.c > @@ -633,7 +633,17 @@ void __init default_find_smp_config(void) > */ > > address = get_bios_ebda(); > - if (address) > + > + /* Check that the EBDA address is sane and the get_bios_ebda() did not Comment format not adhering to coding-style. > + * return just garbage from memory. > + * The upper bound is considered valid if it points below 1K before > + * end of the lower memory (i.e. 639K). The EBDA can be smaller > + * than 1K in which case the pointer will point above 639K but that > + * case is handled in step 2) above, and we don't need to adjust scan > + * size to not bump into the memory above 640K. > + */ > + if (address >= BIOS_START_MIN && > + address < 639 * 0x400) This line doesn't need to be broken and maybe define a symbol for the upper bound limit. And if the 0x400 simply means 1KiB, it would be less confusing to use a decimal number IMO. > smp_scan_config(address, 0x400); > } > > --
WARNING: multiple messages have this Message-ID (diff)
From: Rafael J. Wysocki <rafael at kernel.org> To: devel@acpica.org Subject: [Devel] Re: [PATCH 1/3] platform/x86: Check validity of EBDA pointer in mpparse.c Date: Tue, 05 Apr 2022 15:11:17 +0200 [thread overview] Message-ID: <CAJZ5v0gBbdzUO9MRxbKESEnaeaNAu-+3oP6ADMretch=iHPNJA@mail.gmail.com> (raw) In-Reply-To: YjM/yphbAQHxJIxg@czspare1-lap.sysgo.cz [-- Attachment #1: Type: text/plain, Size: 3186 bytes --] First off, this is not platform/x86, but arch/x86. On Thu, Mar 17, 2022 at 3:12 PM Vit Kabele <vit(a)kabele.me> wrote: > > The pointer to EBDA area is retrieved from a word at 0x40e in BDA. > In case that the memory there is not initialized and contains garbage, > it might happen that the kernel touches memory above 640K. > > This may cause unwanted reads from VGA memory which may not be decoded, > or even present when running under virtualization. > > This patch adds sanity check for the EBDA pointer retrieved from the memory > so that scanning EBDA does not leave the low memory. > > Signed-off-by: Vit Kabele <vit(a)kabele.me> > Reviewed-by: Rudolf Marek <r.marek(a)assembler.cz> > --- > arch/x86/include/asm/bios_ebda.h | 3 +++ > arch/x86/kernel/ebda.c | 3 --- > arch/x86/kernel/mpparse.c | 12 +++++++++++- > 3 files changed, 14 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/include/asm/bios_ebda.h b/arch/x86/include/asm/bios_ebda.h > index 4d5a17e2febe..c3133c01d5b7 100644 > --- a/arch/x86/include/asm/bios_ebda.h > +++ b/arch/x86/include/asm/bios_ebda.h > @@ -4,6 +4,9 @@ > > #include <asm/io.h> > > +#define BIOS_START_MIN 0x20000U /* 128K, less than this is insane */ > +#define BIOS_START_MAX 0x9f000U /* 640K, absolute maximum */ > + > /* > * Returns physical address of EBDA. Returns 0 if there is no EBDA. > */ > diff --git a/arch/x86/kernel/ebda.c b/arch/x86/kernel/ebda.c > index 38e7d597b660..86c0801fc3ce 100644 > --- a/arch/x86/kernel/ebda.c > +++ b/arch/x86/kernel/ebda.c > @@ -50,9 +50,6 @@ > > #define BIOS_RAM_SIZE_KB_PTR 0x413 > > -#define BIOS_START_MIN 0x20000U /* 128K, less than this is insane */ > -#define BIOS_START_MAX 0x9f000U /* 640K, absolute maximum */ > - > void __init reserve_bios_regions(void) > { > unsigned int bios_start, ebda_start; > diff --git a/arch/x86/kernel/mpparse.c b/arch/x86/kernel/mpparse.c > index fed721f90116..6bba0744d32d 100644 > --- a/arch/x86/kernel/mpparse.c > +++ b/arch/x86/kernel/mpparse.c > @@ -633,7 +633,17 @@ void __init default_find_smp_config(void) > */ > > address = get_bios_ebda(); > - if (address) > + > + /* Check that the EBDA address is sane and the get_bios_ebda() did not Comment format not adhering to coding-style. > + * return just garbage from memory. > + * The upper bound is considered valid if it points below 1K before > + * end of the lower memory (i.e. 639K). The EBDA can be smaller > + * than 1K in which case the pointer will point above 639K but that > + * case is handled in step 2) above, and we don't need to adjust scan > + * size to not bump into the memory above 640K. > + */ > + if (address >= BIOS_START_MIN && > + address < 639 * 0x400) This line doesn't need to be broken and maybe define a symbol for the upper bound limit. And if the 0x400 simply means 1KiB, it would be less confusing to use a decimal number IMO. > smp_scan_config(address, 0x400); > } > > --
next prev parent reply other threads:[~2022-04-05 14:45 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <cover.1647525033.git.vit@kabele.me> 2022-03-17 14:03 ` [PATCH 1/3] platform/x86: Check validity of EBDA pointer in mpparse.c Vit Kabele 2022-03-17 14:03 ` [Devel] " Vit Kabele 2022-04-05 13:11 ` Rafael J. Wysocki [this message] 2022-04-05 13:11 ` [Devel] " Rafael J. Wysocki 2022-04-08 8:46 ` [PATCH v2] arch/x86: " Vit Kabele 2022-05-03 17:36 ` Borislav Petkov 2022-05-16 9:43 ` Vit Kabele 2022-05-17 19:21 ` Borislav Petkov 2022-07-21 15:38 ` Vit Kabele 2022-03-17 14:04 ` [PATCH 2/3] acpica: Check that the EBDA pointer is in valid range Vit Kabele 2022-03-17 14:04 ` [Devel] " Vit Kabele 2022-04-05 13:14 ` Rafael J. Wysocki 2022-04-05 13:14 ` [Devel] " Rafael J. Wysocki 2022-03-17 14:04 ` [PATCH 3/3] acpica: Do not touch VGA memory when EBDA < 1KiB Vit Kabele 2022-03-17 14:04 ` [Devel] " Vit Kabele
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAJZ5v0gBbdzUO9MRxbKESEnaeaNAu-+3oP6ADMretch=iHPNJA@mail.gmail.com' \ --to=rafael@kernel.org \ --cc=devel@acpica.org \ --cc=linux-acpi@vger.kernel.org \ --cc=linux-kernel@kernel.org \ --cc=mingo@redhat.com \ --cc=platform-driver-x86@kernel.org \ --cc=r.marek@assembler.cz \ --cc=robert.moore@intel.com \ --cc=vit@kabele.me \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.