<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/arm64/kernel/kaslr.c, branch linux-4.9.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.9.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.9.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2022-09-05T08:23:57Z</updated>
<entry>
<title>arm64: map FDT as RW for early_init_dt_scan()</title>
<updated>2022-09-05T08:23:57Z</updated>
<author>
<name>Hsin-Yi Wang</name>
</author>
<published>2019-08-23T06:24:50Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3e930a2deac2ea232965fd6650ebc7d0cbc782dd'/>
<id>urn:sha1:3e930a2deac2ea232965fd6650ebc7d0cbc782dd</id>
<content type='text'>
commit e112b032a72c78f15d0c803c5dc6be444c2e6c66 upstream.

Currently in arm64, FDT is mapped to RO before it's passed to
early_init_dt_scan(). However, there might be some codes
(eg. commit "fdt: add support for rng-seed") that need to modify FDT
during init. Map FDT to RO after early fixups are done.

Signed-off-by: Hsin-Yi Wang &lt;hsinyi@chromium.org&gt;
Reviewed-by: Stephen Boyd &lt;swboyd@chromium.org&gt;
Reviewed-by: Mike Rapoport &lt;rppt@linux.ibm.com&gt;
Signed-off-by: Will Deacon &lt;will@kernel.org&gt;
[mkbestas: fixed trivial conflicts for 4.9 backport]
Signed-off-by: Michael Bestas &lt;mkbestas@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>arm64: kaslr: ensure randomized quantities are clean also when kaslr is off</title>
<updated>2019-02-06T16:33:28Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2019-01-27T08:29:42Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=62d1d2b720db405c94d85191083bb2eb218a55c0'/>
<id>urn:sha1:62d1d2b720db405c94d85191083bb2eb218a55c0</id>
<content type='text'>
commit 8ea235932314311f15ea6cf65c1393ed7e31af70 upstream.

Commit 1598ecda7b23 ("arm64: kaslr: ensure randomized quantities are
clean to the PoC") added cache maintenance to ensure that global
variables set by the kaslr init routine are not wiped clean due to
cache invalidation occurring during the second round of page table
creation.

However, if kaslr_early_init() exits early with no randomization
being applied (either due to the lack of a seed, or because the user
has disabled kaslr explicitly), no cache maintenance is performed,
leading to the same issue we attempted to fix earlier, as far as the
module_alloc_base variable is concerned.

Note that module_alloc_base cannot be initialized statically, because
that would cause it to be subject to a R_AARCH64_RELATIVE relocation,
causing it to be overwritten by the second round of KASLR relocation
processing.

Fixes: f80fb3a3d508 ("arm64: add support for kernel ASLR")
Cc: &lt;stable@vger.kernel.org&gt; # v4.6+
Signed-off-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;
Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>arm64: kaslr: ensure randomized quantities are clean to the PoC</title>
<updated>2019-01-23T07:10:55Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2019-01-15T19:47:07Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3ec9b7754262ae006356be964b6c05169bb8ad7a'/>
<id>urn:sha1:3ec9b7754262ae006356be964b6c05169bb8ad7a</id>
<content type='text'>
commit 1598ecda7b239e9232dda032bfddeed9d89fab6c upstream.

kaslr_early_init() is called with the kernel mapped at its
link time offset, and if it returns with a non-zero offset,
the kernel is unmapped and remapped again at the randomized
offset.

During its execution, kaslr_early_init() also randomizes the
base of the module region and of the linear mapping of DRAM,
and sets two variables accordingly. However, since these
variables are assigned with the caches on, they may get lost
during the cache maintenance that occurs when unmapping and
remapping the kernel, so ensure that these values are cleaned
to the PoC.

Acked-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Fixes: f80fb3a3d508 ("arm64: add support for kernel ASLR")
Cc: &lt;stable@vger.kernel.org&gt; # v4.6+
Signed-off-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;
Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>arm64: kaslr: Fix up the kernel image alignment</title>
<updated>2017-03-30T07:41:26Z</updated>
<author>
<name>Neeraj Upadhyay</name>
</author>
<published>2017-03-22T11:38:25Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b9ed800f71889795e1f329d4ee84d7778a16797f'/>
<id>urn:sha1:b9ed800f71889795e1f329d4ee84d7778a16797f</id>
<content type='text'>
commit afd0e5a876703accb95894f23317a13e2c49b523 upstream.

If kernel image extends across alignment boundary, existing
code increases the KASLR offset by size of kernel image. The
offset is masked after resizing. There are cases, where after
masking, we may still have kernel image extending across
boundary. This eventually results in only 2MB block getting
mapped while creating the page tables. This results in data aborts
while accessing unmapped regions during second relocation (with
kaslr offset) in __primary_switch. To fix this problem, round up the
kernel image size, by swapper block size, before adding it for
correction.

For example consider below case, where kernel image still crosses
1GB alignment boundary, after masking the offset, which is fixed
by rounding up kernel image size.

SWAPPER_TABLE_SHIFT = 30
Swapper using section maps with section size 2MB.
CONFIG_PGTABLE_LEVELS = 3
VA_BITS = 39

_text  : 0xffffff8008080000
_end   : 0xffffff800aa1b000
offset : 0x1f35600000
mask = ((1UL &lt;&lt; (VA_BITS - 2)) - 1) &amp; ~(SZ_2M - 1)

(_text + offset) &gt;&gt; SWAPPER_TABLE_SHIFT = 0x3fffffe7c
(_end + offset) &gt;&gt; SWAPPER_TABLE_SHIFT  = 0x3fffffe7d

offset after existing correction (before mask) = 0x1f37f9b000
(_text + offset) &gt;&gt; SWAPPER_TABLE_SHIFT = 0x3fffffe7d
(_end + offset) &gt;&gt; SWAPPER_TABLE_SHIFT  = 0x3fffffe7d

offset (after mask) = 0x1f37e00000
(_text + offset) &gt;&gt; SWAPPER_TABLE_SHIFT = 0x3fffffe7c
(_end + offset) &gt;&gt; SWAPPER_TABLE_SHIFT  = 0x3fffffe7d

new offset w/ rounding up = 0x1f38000000
(_text + offset) &gt;&gt; SWAPPER_TABLE_SHIFT = 0x3fffffe7d
(_end + offset) &gt;&gt; SWAPPER_TABLE_SHIFT  = 0x3fffffe7d

Fixes: f80fb3a3d508 ("arm64: add support for kernel ASLR")
Reviewed-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;
Signed-off-by: Neeraj Upadhyay &lt;neeraju@codeaurora.org&gt;
Signed-off-by: Srinivas Ramana &lt;sramana@codeaurora.org&gt;
Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>arm64: apply __ro_after_init to some objects</title>
<updated>2016-08-22T11:32:29Z</updated>
<author>
<name>Jisheng Zhang</name>
</author>
<published>2016-08-15T06:45:46Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5a9e3e156ec1ab26ba70b4c44157858c92bbeee0'/>
<id>urn:sha1:5a9e3e156ec1ab26ba70b4c44157858c92bbeee0</id>
<content type='text'>
These objects are set during initialization, thereafter are read only.

Previously I only want to mark vdso_pages, vdso_spec, vectors_page and
cpu_ops as __read_mostly from performance point of view. Then inspired
by Kees's patch[1] to apply more __ro_after_init for arm, I think it's
better to mark them as __ro_after_init. What's more, I find some more
objects are also read only after init. So apply __ro_after_init to all
of them.

This patch also removes global vdso_pagelist and tries to clean up
vdso_spec[] assignment code.

[1] http://www.spinics.net/lists/arm-kernel/msg523188.html

Acked-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Signed-off-by: Jisheng Zhang &lt;jszhang@marvell.com&gt;
Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
</content>
</entry>
<entry>
<title>arm64: relocatable: deal with physically misaligned kernel images</title>
<updated>2016-04-26T11:23:28Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2016-04-18T15:09:47Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=08cdac619c81b3fa8cd73aeed2330ffe0a0b73ca'/>
<id>urn:sha1:08cdac619c81b3fa8cd73aeed2330ffe0a0b73ca</id>
<content type='text'>
When booting a relocatable kernel image, there is no practical reason
to refuse an image whose load address is not exactly TEXT_OFFSET bytes
above a 2 MB aligned base address, as long as the physical and virtual
misalignment with respect to the swapper block size are equal, and are
both aligned to THREAD_SIZE.

Since the virtual misalignment is under our control when we first enter
the kernel proper, we can simply choose its value to be equal to the
physical misalignment.

So treat the misalignment of the physical load address as the initial
KASLR offset, and fix up the remaining code to deal with that.

Acked-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;
Signed-off-by: Will Deacon &lt;will.deacon@arm.com&gt;
</content>
</entry>
<entry>
<title>arm64: kaslr: randomize the linear region</title>
<updated>2016-02-24T14:57:27Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2016-01-29T10:59:03Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c031a4213c11a5db475f528c182f7b3858df11db'/>
<id>urn:sha1:c031a4213c11a5db475f528c182f7b3858df11db</id>
<content type='text'>
When KASLR is enabled (CONFIG_RANDOMIZE_BASE=y), and entropy has been
provided by the bootloader, randomize the placement of RAM inside the
linear region if sufficient space is available. For instance, on a 4KB
granule/3 levels kernel, the linear region is 256 GB in size, and we can
choose any 1 GB aligned offset that is far enough from the top of the
address space to fit the distance between the start of the lowest memblock
and the top of the highest memblock.

Signed-off-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
</content>
</entry>
<entry>
<title>arm64: add support for kernel ASLR</title>
<updated>2016-02-24T14:57:27Z</updated>
<author>
<name>Ard Biesheuvel</name>
</author>
<published>2016-01-26T13:12:01Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f80fb3a3d50843a401dac4b566b3b131da8077a2'/>
<id>urn:sha1:f80fb3a3d50843a401dac4b566b3b131da8077a2</id>
<content type='text'>
This adds support for KASLR is implemented, based on entropy provided by
the bootloader in the /chosen/kaslr-seed DT property. Depending on the size
of the address space (VA_BITS) and the page size, the entropy in the
virtual displacement is up to 13 bits (16k/2 levels) and up to 25 bits (all
4 levels), with the sidenote that displacements that result in the kernel
image straddling a 1GB/32MB/512MB alignment boundary (for 4KB/16KB/64KB
granule kernels, respectively) are not allowed, and will be rounded up to
an acceptable value.

If CONFIG_RANDOMIZE_MODULE_REGION_FULL is enabled, the module region is
randomized independently from the core kernel. This makes it less likely
that the location of core kernel data structures can be determined by an
adversary, but causes all function calls from modules into the core kernel
to be resolved via entries in the module PLTs.

If CONFIG_RANDOMIZE_MODULE_REGION_FULL is not enabled, the module region is
randomized by choosing a page aligned 128 MB region inside the interval
[_etext - 128 MB, _stext + 128 MB). This gives between 10 and 14 bits of
entropy (depending on page size), independently of the kernel randomization,
but still guarantees that modules are within the range of relative branch
and jump instructions (with the caveat that, since the module region is
shared with other uses of the vmalloc area, modules may need to be loaded
further away if the module region is exhausted)

Signed-off-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
</content>
</entry>
</feed>
