| 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
| ||
|
Message-ID: <20100408015353.GB4053@localhost>
Date: Thu, 8 Apr 2010 09:53:53 +0800
From: Liang Li <liang.li@...driver.com>
To: Yinghai <yinghai.lu@...cle.com>
Cc: akpm@...ux-foundation.org, hpa@...or.com, mingo@...e.hu,
tglx@...utronix.de, wangchen@...fujitsu.com,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: + x86-fix-handling-of-the-reservetop-boot-option.patch added to
-mm tree
On Wed, Apr 07, 2010 at 06:13:56PM -0700, Yinghai wrote:
> On 04/07/2010 06:05 PM, Liang Li wrote:
> > On Wed, Apr 07, 2010 at 04:52:03PM -0700, Yinghai wrote:
> >> On 04/07/2010 03:00 PM, akpm@...ux-foundation.org wrote:
> >>> The patch titled
> >>> x86: fix handling of the 'reservetop' boot option
> >>> has been added to the -mm tree. Its filename is
> >>> x86-fix-handling-of-the-reservetop-boot-option.patch
> >>>
> >>> Before you just go and hit "reply", please:
> >>> a) Consider who else should be cc'ed
> >>> b) Prefer to cc a suitable mailing list as well
> >>> c) Ideally: find the original patch on the mailing list and do a
> >>> reply-to-all to that, adding suitable additional cc's
> >>>
> >>> *** Remember to use Documentation/SubmitChecklist when testing your code ***
> >>>
> >>> See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
> >>> out what to do about this
> >>>
> >>> The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
> >>>
> >>> ------------------------------------------------------
> >>> Subject: x86: fix handling of the 'reservetop' boot option
> >>> From: Liang Li <liang.li@...driver.com>
> >>>
> >>> When specifying the 'reservetop=0xbadc0de' kernel parameter, the kernel
> >>> will stop booting due to a early_ioremap bug that relate to commit
> >>> 8827247ff ("x86: don't define __this_fixmap_does_not_exist()").
> >>>
> >>> The root cause of boot failure problem is the value of 'slot_virt[i]' was
> >>> initialized in setup_arch->early_ioremap_init. But later in setup_arch,
> >>> the function 'parse_early_param' will modify 'FIXADDR_TOP' when
> >>> 'reservetop=0xbadc0de' being specified.
> >>>
> >>> The simplest fix might be use __fix_to_virt(idx0) to get updated value
> >>> of 'FIXADDR_TOP' in '__early_ioremap' instead of reference old value
> >>> from slot_virt[slot] directly.
> >>>
> >>> Signed-off-by: Liang Li <liang.li@...driver.com>
> >>> Cc: Wang Chen <wangchen@...fujitsu.com>
> >>> Cc: Ingo Molnar <mingo@...e.hu>
> >>> Cc: Thomas Gleixner <tglx@...utronix.de>
> >>> Cc: "H. Peter Anvin" <hpa@...or.com>
> >>> Cc: Yinghai Lu <yinghai@...nel.org>
> >>> Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
> >>> ---
> >>>
> >>> arch/x86/mm/ioremap.c | 4 ++--
> >>> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff -puN arch/x86/mm/ioremap.c~x86-fix-handling-of-the-reservetop-boot-option arch/x86/mm/ioremap.c
> >>> --- a/arch/x86/mm/ioremap.c~x86-fix-handling-of-the-reservetop-boot-option
> >>> +++ a/arch/x86/mm/ioremap.c
> >>> @@ -537,9 +537,9 @@ __early_ioremap(resource_size_t phys_add
> >>> --nrpages;
> >>> }
> >>> if (early_ioremap_debug)
> >>> - printk(KERN_CONT "%08lx + %08lx\n", offset, slot_virt[slot]);
> >>> + printk(KERN_CONT "%08lx + %08lx\n", offset, __fix_to_virt(idx0));
> >>>
> >>> - prev_map[slot] = (void __iomem *)(offset + slot_virt[slot]);
> >>> + prev_map[slot] = (void __iomem *)(offset + __fix_to_virt(idx0));
> >>> return prev_map[slot];
> >>> }
> >>>
> >>> _
> >>
> >> not that simple. but it looks like correct direction.
> >>
> >> please consider:
> >> when early_parsing reserve_top, double check if there is left over in prev_map[], and
> >> reinitialize slot_virt[] and clear old PMD and setup new PMD if needed.
> >
> > Hi Yinghai,
> >
> > Thanks for your reply, its better to have eyes on then being ignored. :)
> >
> > Your suggestions were considered before the patch to public, let me try
> > to explain:
> >
> > #1 check/adjust prev_map[]?
> > In my tests, seems early_ioremap is untouched between early_ioremap_init
> > and parse_early_param so I did not check prev_map. Even its get touched,
> > I think we could do nothing to this mapping, since prev_map[i] just
> > record virt addr for clients of early_ioremap. We can check and adjust
> > prev_map but clients of early_ioremap won't realize the fact so nothing
> > being fixed or broken.
>
> efi related code need them
>
> dmi
>
> you need to add bug_on if there is still have left over, and need the caller to re map it again later.
>
> >
> > #2 reinitialize slot_virt and update PMD
> > I actually tried this approach, call early_ioremap_init again after
> > parse_early_param will do that work, it also works but I am not sure
> > that is the better solution or too heavy for solve the problem? So I
> > tend to say 'simplest' solution in git commit log.
>
> how about PMD? you don't need set PMD again.
>
> YH
Hi Yinghai,
Does this similar modification like this is more preferred?
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index a1dcfa3..30a3e97 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -347,6 +347,7 @@ extern void __iomem *early_ioremap(resource_size_t phys_addr,
extern void __iomem *early_memremap(resource_size_t phys_addr,
unsigned long size);
extern void early_iounmap(void __iomem *addr, unsigned long size);
+extern void fixup_early_ioremap(void);
#define IO_SPACE_LIMIT 0xffff
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index ea82ef0..fe06296 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -448,6 +448,23 @@ static inline void __init early_clear_fixmap(enum fixed_addresses idx)
static void __iomem *prev_map[FIX_BTMAPS_SLOTS] __initdata;
static unsigned long prev_size[FIX_BTMAPS_SLOTS] __initdata;
+void __init fixup_early_ioremap(void)
+{
+ int i;
+ for (i = 0; i < FIX_BTMAPS_SLOTS; i++) {
+ if (prev_map[i])
+ break;
+ }
+
+ if (i == FIX_BTMAPS_SLOTS)
+ WARN_ON(1);
+
+ for (i = 0; i < FIX_BTMAPS_SLOTS; i++)
+ slot_virt[i] = __fix_to_virt(FIX_BTMAP_BEGIN - NR_FIX_BTMAPS * i);
+
+ return;
+}
+
static int __init check_early_ioremap_leak(void)
{
int count = 0;
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
index 5c4ee42..ea4d54c 100644
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -4,6 +4,7 @@
#include <asm/pgtable.h>
#include <asm/tlb.h>
#include <asm/fixmap.h>
+#include <asm/io.h>
#define PGALLOC_GFP GFP_KERNEL | __GFP_NOTRACK | __GFP_REPEAT | __GFP_ZERO
@@ -351,6 +352,7 @@ void __init reserve_top_address(unsigned long reserve)
printk(KERN_INFO "Reserving virtual address space above 0x%08x\n",
(int)-reserve);
__FIXADDR_TOP = -reserve - PAGE_SIZE;
+ fixup_early_ioremap();
#endif
}
Thanks,
-Liang Li
--
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