increase the use of CONFIG_VECTORS_BASE

From: Domenico Andreoli <[email protected]>

If CONFIG_VECTORS_BASE is meant to make vectors base address configurable, it is not consistently used. At least in arch/arm/mm/mmu.c the explicit value 0xffff0000 is still widely used.

This is an attempt to improve the situation.

---

I'm in the footsteps of the vectors' initialization but following CONFIG_VECTORS_BASE alone does not bring anywhere. Even if this patch does not allow to freely set the vectors base elsewhere (if it has any sense) it could anyway improve the way for the others coming along.

Grepping for ffff0000 in arch/arm shows a lot of false positives, this is my guess of other possible places in which CONFIG_VECTORS_BASE may have sense:

arch/arm/include/asm/fixmap.h:8: * the architecture such as the vector page which is located at 0xffff0000,
arch/arm/include/asm/system.h:33:#define CR_V (1 << 13) /* Vectors relocated to 0xffff0000 */
arch/arm/kernel/process.c:496: return install_special_mapping(mm, 0xffff0000, PAGE_SIZE, arch/arm/kernel/process.c:505: return (vma->vm_start == 0xffff0000) ? "[vectors]" : NULL;
arch/arm/kernel/traps.c:773: * into the vector page, mapped at 0xffff0000, and ensure these
arch/arm/mach-sa1100/generic.c:376: * 0xffff0000-0xffff0fff: SA1100 exception vectors
arch/arm/mm/mmu.c:1044: top_pmd = pmd_off_k(0xffff0000);
...

Surely the most important are missing :)

cheers,
Domenico

---
 arch/arm/mm/mmu.c |    9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

Index: b/arch/arm/mm/mmu.c
===================================================================
@@ -521,7 +521,7 @@
 EXPORT_SYMBOL(phys_mem_access_prot);
 #endif
 
-#define vectors_base()	(vectors_high() ? 0xffff0000 : 0)
+#define vectors_base()	(vectors_high() ? CONFIG_VECTORS_BASE : 0)
 
 static void __init *early_alloc(unsigned long sz)
 {

@@ -962,11 +962,12 @@
 
 	/*
 	 * Create a mapping for the machine vectors at the high-vectors
-	 * location (0xffff0000).  If we aren't using high-vectors, also
-	 * create a mapping at the low-vectors virtual address.
+	 * location (defined by CONFIG_VECTORS_BASE).  If we aren't
+	 * using high-vectors, also create a mapping at the low-vectors
+	 * virtual address.
 	 */
 	map.pfn = __phys_to_pfn(virt_to_phys(vectors_page));
-	map.virtual = 0xffff0000;
+	map.virtual = CONFIG_VECTORS_BASE;
 	map.length = PAGE_SIZE;
 	map.type = MT_HIGH_VECTORS;
 	create_mapping(&map);

NAK.

Some explanation is in order.

On CPU cores with a MMU, there are only two possibilities for the location of the vector page: either address 0, or address 0xffff0000. Some CPUs only supports the low vectors i.e. at 0. Most others allow for a selection between either of those addresses using the V bit in the control register (see the vectors_high() macro for example). In those cases replacing 0xffff0000 with CONFIG_VECTORS_BASE is the wrong thing to do.

Now, because the vector table and associated stubs are quite small, we also use the same memory page for other things such as read-only code segments made available to user space. So to simplify things, the vector page is _always_ mapped at 0xffff0000, regardless if the CPU supports high vectors or not (if it doesn't then another mapping for the same page is installed at 0). So also in this case it is wrong to substitute 0xffff0000 with CONFIG_VECTORS_BASE.

Finally, on non-MMU processors, the actual vector table is often in ROM and no RAM page can be mapped to the vector address because of course there is no MMU. In this case, all vectors (except for the reset one) are usually branching to some arbitrary location in RAM to allow the installed software to redirect them. This is where CONFIG_VECTORS_BASE really makes sense as it should be set to the address of the memory area that the OS can modify to hook its exception handlers.

So using CONFIG_VECTORS_BASE really depends on the context. For shared code between the MMU and non-MMU cases with access to the vector page, then it makes sense to use CONFIG_VECTORS_BASE, and in the MMU case it shouldn't be set to anything other than 0xffff0000.

Nicolas

From: Domenico Andreoli <[email protected]>

Nice explanation of CONFIG_VECTORS_BASE vs. 0xffff0000 usage. Save it to make annoying people avoid not obvious questions.

---
 Documentation/arm/memory.txt |   35 +++++++++++++++++++++++++++++++++++
 arch/arm/mm/mmu.c            |    3 +++
 2 files changed, 38 insertions(+)

Index: b/Documentation/arm/memory.txt
===================================================================
@@ -91,3 +91,38 @@
 must not access any memory which is not mapped inside their 0x0001000
 to TASK_SIZE address range.  If they wish to access these areas, they
 must set up their own mappings using open() and mmap().
+
+
+About using CONFIG_VECTORS_BASE and 0xffff0000
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+On CPU cores with a MMU, there are only two possibilities for the
+location of the vector page: either address 0, or address 0xffff0000.
+Some CPUs only supports the low vectors i.e. at 0.  Most others allow
+for a selection between either of those addresses using the V bit
+in the control register (see the vectors_high() macro for example).
+In those cases replacing 0xffff0000 with CONFIG_VECTORS_BASE is the
+wrong thing to do.
+
+Now, because the vector table and associated stubs are quite small,
+we also use the same memory page for other things such as read-only
+code segments made available to user space.  So to simplify things,
+the vector page is _always_ mapped at 0xffff0000, regardless if the CPU
+supports high vectors or not (if it doesn't then another mapping for
+the same page is installed at 0).  So also in this case it is wrong to
+substitute 0xffff0000 with CONFIG_VECTORS_BASE.
+
+Finally, on non-MMU processors, the actual vector table is often in ROM
+and no RAM page can be mapped to the vector address because of course
+there is no MMU.  In this case, all vectors (except for the reset one)
+are usually branching to some arbitrary location in RAM to allow the
+installed software to redirect them.  This is where CONFIG_VECTORS_BASE
+really makes sense as it should be set to the address of the memory
+area that the OS can modify to hook its exception handlers.
+
+So using CONFIG_VECTORS_BASE really depends on the context.  For shared
+code between the MMU and non-MMU cases with access to the vector page,
+then it makes sense to use CONFIG_VECTORS_BASE, and in the MMU case it
+shouldn't be set to anything other than 0xffff0000.
+
+ -- Nicolas Pitre

Index: b/arch/arm/mm/mmu.c
===================================================================
@@ -964,6 +964,9 @@
 	 * Create a mapping for the machine vectors at the high-vectors
 	 * location (0xffff0000).  If we aren't using high-vectors, also
 	 * create a mapping at the low-vectors virtual address.
+	 *
+	 * Read Documentation/arm/memory.txt in case you want to replace
+	 * 0xffff0000 with CONFIG_VECTORS_BASE.
 	 */
 	map.pfn = __phys_to_pfn(virt_to_phys(vectors_page));
 	map.virtual = 0xffff0000;

Since v6Z (i.e., including arm1176 and all v7-A processors), there is a cp15 vector base address register for MMU-enabled CPUs, allowing the vectors to be placed anywhere (32-byte aligned) in the virtual address space.

This was introduced as part of the v6 security extensions, since the Secure World needs two vector tables for its own use and therefore a single default location isn't enough; but as a consequence the Normal World can move its vector table too. The high vectors configuration input to the core only determines the default vectors location at boot in this case.

Moving the actual vectors could be useful from an address space layout randomisation point of view. But unfortunately, although the vectors themselves could be moved, the rest of the contents of the vectors page must probably stay where it is -- with no VDSO, userspace code is riddled with hard-coded references to 0xffff0000 to call the kuser helpers etc.

Cheers
---Dave