[PATCH] increase the use of CONFIG_VECTORS_BASE

[PATCH] increase the use of CONFIG_VECTORS_BASE

[Domenico Andreoli]

From: Domenico Andreoli <cavokz@gmail.com>

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.

Signed-off-by: Domenico Andreoli <cavokz@gmail.com>

---

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
===================================================================
--- a/arch/arm/mm/mmu.c	2011-04-11 18:03:50.000000000 +0200
+++ b/arch/arm/mm/mmu.c	2011-04-11 18:09:46.000000000 +0200
@@ -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);

[PATCH] increase the use of CONFIG_VECTORS_BASE

[Nicolas Pitre]

On Mon, 11 Apr 2011, Domenico Andreoli wrote:

> From: Domenico Andreoli <cavokz@gmail.com>
> 
> 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.
> 
> Signed-off-by: Domenico Andreoli <cavokz@gmail.com>

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

[PATCH] CONFIG_VECTORS_BASE vs. 0xffff0000 documentation

[Domenico Andreoli]

From: Domenico Andreoli <cavokz@gmail.com>

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

Signed-off-by: Domenico Andreoli <cavokz@gmail.com>

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

Index: b/Documentation/arm/memory.txt
===================================================================
--- a/Documentation/arm/memory.txt	2011-04-11 22:39:45.000000000 +0200
+++ b/Documentation/arm/memory.txt	2011-04-11 22:50:48.000000000 +0200
@@ -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
===================================================================
--- a/arch/arm/mm/mmu.c	2011-04-11 22:40:01.000000000 +0200
+++ b/arch/arm/mm/mmu.c	2011-04-11 22:42:10.000000000 +0200
@@ -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;

[PATCH] increase the use of CONFIG_VECTORS_BASE

[Dave Martin]

On Mon, Apr 11, 2011 at 8:39 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Mon, 11 Apr 2011, Domenico Andreoli wrote:
>
>> From: Domenico Andreoli <cavokz@gmail.com>
>>
>> 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.
>>
>> Signed-off-by: Domenico Andreoli <cavokz@gmail.com>
>
> 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.
>

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