<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/arm/include/asm/elf.h, branch linux-3.19.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.19.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.19.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2015-05-06T20:01:48Z</updated>
<entry>
<title>ARM: 8320/1: fix integer overflow in ELF_ET_DYN_BASE</title>
<updated>2015-05-06T20:01:48Z</updated>
<author>
<name>Andrey Ryabinin</name>
</author>
<published>2015-03-20T14:42:27Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4dcafe787396525d0947ca5fc8ee7f186680ce3a'/>
<id>urn:sha1:4dcafe787396525d0947ca5fc8ee7f186680ce3a</id>
<content type='text'>
commit 8defb3367fcd19d1af64c07792aade0747b54e0f upstream.

Usually ELF_ET_DYN_BASE is 2/3 of TASK_SIZE. With 3G/1G user/kernel
split this is not so, because 2*TASK_SIZE overflows 32 bits,
so the actual value of ELF_ET_DYN_BASE is:
	(2 * TASK_SIZE / 3) = 0x2a000000

When ASLR is disabled PIE binaries will load at ELF_ET_DYN_BASE address.
On 32bit platforms AddressSanitzer uses addresses [0x20000000 - 0x40000000]
for shadow memory [1]. So ASan doesn't work for PIE binaries when ASLR disabled
as it fails to map shadow memory.
Also after Kees's 'split ET_DYN ASLR from mmap ASLR' patchset PIE binaries
has a high chance of loading somewhere in between [0x2a000000 - 0x40000000]
even if ASLR enabled. This makes ASan with PIE absolutely incompatible.

Fix overflow by dividing TASK_SIZE prior to multiplying.
After this patch ELF_ET_DYN_BASE equals to (for CONFIG_VMSPLIT_3G=y):
	(TASK_SIZE / 3 * 2) = 0x7f555554

[1] https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerAlgorithm#Mapping

Signed-off-by: Andrey Ryabinin &lt;a.ryabinin@samsung.com&gt;
Reported-by: Maria Guseva &lt;m.guseva@samsung.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ARM: 8127/1: module: add support for R_ARM_TARGET1 relocations</title>
<updated>2014-08-27T14:40:11Z</updated>
<author>
<name>Andrey Ryabinin</name>
</author>
<published>2014-08-08T13:12:17Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=55f0fb6adb83a5883589e945cbce37e90615ea09'/>
<id>urn:sha1:55f0fb6adb83a5883589e945cbce37e90615ea09</id>
<content type='text'>
Kernel module build with GCOV profiling fails to load with the
following error:

 $ insmod test_module.ko
   test_module: unknown relocation: 38
   insmod: can't insert 'test_module.ko': invalid module format

This happens because constructor pointers in the .init_array section
have not supported R_ARM_TARGET1 relocation type.

Documentation (ELF for the ARM Architecture) says:
    "The relocation must be processed either in the same way as R_ARM_REL32 or
     as R_ARM_ABS32: a virtual platform must specify which method is used."

Since kernel expects to see absolute addresses in .init_array R_ARM_TARGET1
relocation type should be treated the same way as R_ARM_ABS32.

Signed-off-by: Andrey Ryabinin &lt;a.ryabinin@samsung.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>Move the EM_ARM and EM_AARCH64 definitions to uapi/linux/elf-em.h</title>
<updated>2013-09-02T15:35:50Z</updated>
<author>
<name>Dan Aloni</name>
</author>
<published>2013-08-28T13:24:53Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=909e3ee4119f87b85c6e1b8534b2287ed1ea3ca2'/>
<id>urn:sha1:909e3ee4119f87b85c6e1b8534b2287ed1ea3ca2</id>
<content type='text'>
Signed-off-by: Dan Aloni &lt;alonid@stratoscale.com&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
</content>
</entry>
<entry>
<title>ARM: fix nommu builds with 48be69a02 (ARM: move signal handlers into a vdso-like page)</title>
<updated>2013-08-03T09:49:01Z</updated>
<author>
<name>Russell King</name>
</author>
<published>2013-08-03T09:39:51Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8c0cc8a5d90bc7373a7a9e7f7a40eb41f51e03fc'/>
<id>urn:sha1:8c0cc8a5d90bc7373a7a9e7f7a40eb41f51e03fc</id>
<content type='text'>
Olof reports that noMMU builds error out with:

arch/arm/kernel/signal.c: In function 'setup_return':
arch/arm/kernel/signal.c:413:25: error: 'mm_context_t' has no member named 'sigpage'

This shows one of the evilnesses of IS_ENABLED().  Get rid of it here
and replace it with #ifdef's - and as no noMMU platform can make use
of sigpage, depend on CONIFG_MMU not CONFIG_ARM_MPU.

Reported-by: Olof Johansson &lt;olof@lixom.net&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>ARM: move signal handlers into a vdso-like page</title>
<updated>2013-08-01T13:31:56Z</updated>
<author>
<name>Russell King</name>
</author>
<published>2013-07-23T23:29:18Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=48be69a026b2c17350a5ef18a1959a919f60be7d'/>
<id>urn:sha1:48be69a026b2c17350a5ef18a1959a919f60be7d</id>
<content type='text'>
Move the signal handlers into a VDSO page rather than keeping them in
the vectors page.  This allows us to place them randomly within this
page, and also map the page at a random location within userspace
further protecting these code fragments from ROP attacks.  The new
VDSO page is also poisoned in the same way as the vector page.

Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>ARM: 7294/1: vectors: use gate_vma for vectors user mapping</title>
<updated>2012-03-24T09:38:51Z</updated>
<author>
<name>Will Deacon</name>
</author>
<published>2012-01-20T11:01:13Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f9d4861fc32b995b1616775614459b8f266c803c'/>
<id>urn:sha1:f9d4861fc32b995b1616775614459b8f266c803c</id>
<content type='text'>
The current user mapping for the vectors page is inserted as a `horrible
hack vma' into each task via arch_setup_additional_pages. This causes
problems with the MM subsystem and vm_normal_page, as described here:

https://lkml.org/lkml/2012/1/14/55

Following the suggestion from Hugh in the above thread, this patch uses
the gate_vma for the vectors user mapping, therefore consolidating
the horrible hack VMAs into one.

Acked-and-Tested-by: Nicolas Pitre &lt;nico@linaro.org&gt;

Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>ARM: 6883/1: ptrace: Migrate to regsets framework</title>
<updated>2011-05-14T20:36:55Z</updated>
<author>
<name>Dave Martin</name>
</author>
<published>2011-04-18T13:48:23Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5be6f62b0059a3344437b4c2877152c58cb3fdeb'/>
<id>urn:sha1:5be6f62b0059a3344437b4c2877152c58cb3fdeb</id>
<content type='text'>
This patch migrates the implementation of the ptrace interface for
the core integer registers, legacy FPA registers and VFP registers
to use the regsets framework.

As an added bonus, all this stuff gets included in coredumps
at no extra cost.  Without this patch, coredumps contained no
VFP state.

Third-party extension register sets (iwmmx, crunch) are not migrated
by this patch, and continue to use the old implementation;
these should be migratable without much extra work.

Signed-off-by: Dave Martin &lt;dave.martin@linaro.org&gt;
Acked-by: Will Deacon &lt;Will.Deacon@arm.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>ARM: 6486/1: provide zero vmcore_elf64_check_arch()</title>
<updated>2010-11-30T13:40:01Z</updated>
<author>
<name>Mika Westerberg</name>
</author>
<published>2010-11-18T18:13:19Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4b3bf7aef94fc337610d78fce0d960e2ee1d5a8f'/>
<id>urn:sha1:4b3bf7aef94fc337610d78fce0d960e2ee1d5a8f</id>
<content type='text'>
Since we don't support 64-bit ELF vmcores. This also prevents the
following warning:

fs/proc/vmcore.c: In function 'parse_crash_elf64_headers':
fs/proc/vmcore.c:502: warning: passing argument 1 of 'elf_check_arch'
  from incompatible pointer type

Signed-off-by: Mika Westerberg &lt;mika.westerberg@iki.fi&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
</entry>
<entry>
<title>ARM: add a vma entry for the user accessible vector page</title>
<updated>2010-10-02T02:35:19Z</updated>
<author>
<name>Nicolas Pitre</name>
</author>
<published>2010-08-27T03:10:50Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ec706dab290c486837d4a825870ab052bf200279'/>
<id>urn:sha1:ec706dab290c486837d4a825870ab052bf200279</id>
<content type='text'>
The kernel makes the high vector page visible to user space. This page
contains (amongst others) small code segments that can be executed in
user space.  Make this page visible through ptrace and /proc/&lt;pid&gt;/mem
in order to let gdb perform code parsing needed for proper unwinding.

For example, the ERESTART_RESTARTBLOCK handler actually has a stack
frame -- it returns to a PC value stored on the user's stack.   To
unwind after a "sleep" system call was interrupted twice, GDB would
have to recognize this situation and understand that stack frame
layout -- which it currently cannot do.

We could fix this by hard-coding addresses in the vector page range into
GDB, but that isn't really portable as not all of those addresses are
guaranteed to remain stable across kernel releases.  And having the gdb
process make an exception for this page and get  content from its own
address space for it looks strange, and it is not future proof either.

Being located above PAGE_OFFSET, this vma cannot be deleted by
user space code.

Signed-off-by: Nicolas Pitre &lt;nicolas.pitre@linaro.org&gt;
</content>
</entry>
<entry>
<title>ARM: 6189/1: Add support for the MOVW/MOVT relocations in Thumb-2</title>
<updated>2010-08-05T09:35:46Z</updated>
<author>
<name>Catalin Marinas</name>
</author>
<published>2010-06-21T14:10:37Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8dd47741d191400c46173ed9fba9d14b4033ce23'/>
<id>urn:sha1:8dd47741d191400c46173ed9fba9d14b4033ce23</id>
<content type='text'>
The patch adds handling case for the R_ARM_THM_MOVW_ABS_NC and
R_ARM_THM_MOVT_ABS relocations in arch/arm/kernel/module.c. Such
relocations may appear in Thumb-2 compiled kernel modules.

Reported-by: Kyungmin Park &lt;kmpark@infradead.org&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
</entry>
</feed>
