linux-kernel - Re: [PATCHv3 02/11] arm64: Handle section maps for swapper/idmap

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:	Wed, 14 Oct 2015 15:51:58 +0100
From:	Mark Rutland <mark.rutland@....com>
To:	"Suzuki K. Poulose" <Suzuki.Poulose@....com>
Cc:	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	catalin.marinas@....com, will.deacon@....com,
	steve.capper@...aro.org, marc.zyngier@....com,
	ard.biesheuvel@...aro.org, christoffer.dall@...aro.org
Subject: Re: [PATCHv3 02/11] arm64: Handle section maps for swapper/idmap

> >>+/* With 4K pages, we use section maps. */
> >>+#ifdef CONFIG_ARM64_4K_PAGES
> >>+#define ARM64_SWAPPER_USES_SECTION_MAPS 1
> >>+#else
> >>+#define ARM64_SWAPPER_USES_SECTION_MAPS 0
> >>+#endif
> >
> >The comment is somewhat redunant. It would be better to state why we do
> >this for 4K and not 64K (or 16K).
> 
> Something like :
> 
> /*
>  * ARM64 kernel is guaranteed to be loaded at 2M aligned
>  * address (as per booting requirements). Hence we can use
>  * section mapping with 4K (section size = 2M) and not with
>  * 16K(section size = 32M) or 64K (section size = 512M).
>  */

That sounds much better. I hadn't figured out why myself, so thanks for
the explanation :)

However, there's one minor nit: the start of memory below the kernel is
2M aligned, but the offset means that the kernel itself is not loaded at
a 2M aligned address.

So how about:

/*
 * The linear mapping and the start of memory are both 2M aligned (per
 * the arm64 booting.txt requirements). Hence we can use section mapping
 * with 4K (section size = 2M) but not with 16K (section size = 32M) or
 * 64K (section size = 512M).
 */

> >>+	 * us PUD_SIZE (with SECTION maps, i.e, 4K) or PMD_SIZE (without
> >>+	 * SECTION maps, i.e, 64K pages) memory starting from PHYS_OFFSET
> >>+	 * (which must be aligned to 2MB as per Documentation/arm64/booting.txt).
> >
> >This didn't seem to get updated for 16K later in the series, unless I
> >missed something.
> >
> >Perhaps drop the mention of 4K / 64K entirely here?
> 
> You are right, I missed it. We can drop the pagesize info entirely.

Ok. Sounds good.

> >>@@ -551,7 +552,7 @@ int kern_addr_valid(unsigned long addr)
> >>  	return pfn_valid(pte_pfn(*pte));
> >>  }
> >>  #ifdef CONFIG_SPARSEMEM_VMEMMAP
> >>-#ifdef CONFIG_ARM64_64K_PAGES
> >>+#if !ARM64_SWAPPER_USES_SECTION_MAPS
> >
> >This leaves the comments on the #else and #endif stale. Please update
> >those too.
> 
> Done.

Great.

Thanks,
Mark.
--
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/