<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in Makefile</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>7f7f6f7a - Makefile: remove redundant tool coverage variables</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/arch/arm64/kernel/pi/Makefile#7f7f6f7a</link>
        <description>Makefile: remove redundant tool coverage variablesNow Kbuild provides reasonable defaults for objtool, sanitizers, andprofilers.Remove redundant variables.Note:This commit changes the coverage for some objects:  - include arch/mips/vdso/vdso-image.o into UBSAN, GCOV, KCOV  - include arch/sparc/vdso/vdso-image-*.o into UBSAN  - include arch/sparc/vdso/vma.o into UBSAN  - include arch/x86/entry/vdso/extable.o into KASAN, KCSAN, UBSAN, GCOV, KCOV  - include arch/x86/entry/vdso/vdso-image-*.o into KASAN, KCSAN, UBSAN, GCOV, KCOV  - include arch/x86/entry/vdso/vdso32-setup.o into KASAN, KCSAN, UBSAN, GCOV, KCOV  - include arch/x86/entry/vdso/vma.o into GCOV, KCOV  - include arch/x86/um/vdso/vma.o into KASAN, GCOV, KCOVI believe these are positive effects because all of them are kernelspace objects.Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;Tested-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;

            List of files:
            /linux-6.15/arch/arm64/kernel/pi/Makefile</description>
        <pubDate>Mon, 06 May 2024 13:35:43 +0000</pubDate>
        <dc:creator>Masahiro Yamada &lt;masahiroy@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>84b04d3e - arm64: kernel: Create initial ID map from C code</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/arch/arm64/kernel/pi/Makefile#84b04d3e</link>
        <description>arm64: kernel: Create initial ID map from C codeThe asm code that creates the initial ID map is rather intricate andhard to follow. This is problematic because it makes adding support forthings like LPA2 or WXN more difficult than necessary. Also, it isparameterized like the rest of the MM code to run with a configurablenumber of levels, which is rather pointless, given that all AArch64 CPUsimplement support for 48-bit virtual addressing, and that many systemsexist with DRAM located outside of the 39-bit addressable range, whichis the only smaller VA size that is widely used, and we need additionaltricks to make things work in that combination.So let&apos;s bite the bullet, and rip out all the asm macros, and fiddlycode, and replace it with a C implementation based on the newly addedroutines for creating the early kernel VA mappings. And while at it,create the initial ID map based on 48-bit virtual addressing as well,regardless of the number of configured levels for the kernel proper.Note that this code may execute with the MMU and caches disabled, and istherefore not permitted to make unaligned accesses. This shouldn&apos;tgenerally happen in any case for the algorithm as implemented, but to besure, let&apos;s pass -mstrict-align to the compiler just in case.Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;Link: https://lore.kernel.org/r/20240214122845.2033971-66-ardb+git@google.comSigned-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;

            List of files:
            /linux-6.15/arch/arm64/kernel/pi/Makefile</description>
        <pubDate>Wed, 14 Feb 2024 12:29:07 +0000</pubDate>
        <dc:creator>Ard Biesheuvel &lt;ardb@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>97a6f43b - arm64: head: Move early kernel mapping routines into C code</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/arch/arm64/kernel/pi/Makefile#97a6f43b</link>
        <description>arm64: head: Move early kernel mapping routines into C codeThe asm version of the kernel mapping code works fine for creating acoarse grained identity map, but for mapping the kernel down to itsexact boundaries with the right attributes, it is not suitable. This iswhy we create a preliminary RWX kernel mapping first, and then rebuildit from scratch later on.So let&apos;s reimplement this in C, in a way that will make it unnecessaryto create the kernel page tables yet another time in paging_init().Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;Link: https://lore.kernel.org/r/20240214122845.2033971-63-ardb+git@google.comSigned-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;

            List of files:
            /linux-6.15/arch/arm64/kernel/pi/Makefile</description>
        <pubDate>Wed, 14 Feb 2024 12:29:04 +0000</pubDate>
        <dc:creator>Ard Biesheuvel &lt;ardb@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>8a6e40e1 - arm64: head: move dynamic shadow call stack patching into early C runtime</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/arch/arm64/kernel/pi/Makefile#8a6e40e1</link>
        <description>arm64: head: move dynamic shadow call stack patching into early C runtimeOnce we update the early kernel mapping code to only map the kernel oncewith the right permissions, we can no longer perform code patching viathis mapping.So move this code to an earlier stage of the boot, right after applyingthe relocations.Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;Link: https://lore.kernel.org/r/20240214122845.2033971-54-ardb+git@google.comSigned-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;

            List of files:
            /linux-6.15/arch/arm64/kernel/pi/Makefile</description>
        <pubDate>Wed, 14 Feb 2024 12:28:55 +0000</pubDate>
        <dc:creator>Ard Biesheuvel &lt;ardb@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>e223a449 - arm64: idreg-override: Move to early mini C runtime</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/arch/arm64/kernel/pi/Makefile#e223a449</link>
        <description>arm64: idreg-override: Move to early mini C runtimeWe will want to parse the ID register overrides even earlier, so that wecan take them into account before creating the kernel mapping. Somigrate the code and make it work in the context of the early C runtime.We will move the invocation to an earlier stage in a subsequent patch.Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;Link: https://lore.kernel.org/r/20240214122845.2033971-49-ardb+git@google.comSigned-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;

            List of files:
            /linux-6.15/arch/arm64/kernel/pi/Makefile</description>
        <pubDate>Wed, 14 Feb 2024 12:28:50 +0000</pubDate>
        <dc:creator>Ard Biesheuvel &lt;ardb@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>734958ef - arm64: head: move relocation handling to C code</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/arch/arm64/kernel/pi/Makefile#734958ef</link>
        <description>arm64: head: move relocation handling to C codeNow that we have a mini C runtime before the kernel mapping is up, wecan move the non-trivial relocation processing code out of head.S andreimplement it in C.Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;Link: https://lore.kernel.org/r/20240214122845.2033971-48-ardb+git@google.comSigned-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;

            List of files:
            /linux-6.15/arch/arm64/kernel/pi/Makefile</description>
        <pubDate>Wed, 14 Feb 2024 12:28:49 +0000</pubDate>
        <dc:creator>Ard Biesheuvel &lt;ardb@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>a86aa72e - arm64: kernel: Don&apos;t rely on objcopy to make code under pi/ __init</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/arch/arm64/kernel/pi/Makefile#a86aa72e</link>
        <description>arm64: kernel: Don&apos;t rely on objcopy to make code under pi/ __initWe will add some code under pi/ that contains global variables thatshould not end up in __initdata, as they will not be writable via theinitial ID map. So only rely on objcopy for making the libfdt code__init, and use explicit annotations for the rest.Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;Link: https://lore.kernel.org/r/20240214122845.2033971-47-ardb+git@google.comSigned-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;

            List of files:
            /linux-6.15/arch/arm64/kernel/pi/Makefile</description>
        <pubDate>Wed, 14 Feb 2024 12:28:48 +0000</pubDate>
        <dc:creator>Ard Biesheuvel &lt;ardb@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>48157aa3 - arm64: kernel: Manage absolute relocations in code built under pi/</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/arch/arm64/kernel/pi/Makefile#48157aa3</link>
        <description>arm64: kernel: Manage absolute relocations in code built under pi/The mini C runtime runs before relocations are processed, and so itcannot rely on statically initialized pointer variables.Add a check to ensure that such code does not get introduced byaccident, by going over the relocations in each object, identifying theones that operate on data sections that are part of the executableimage, and raising an error if any relocations of type R_AARCH64_ABS64exist. Note that such relocations are permitted in other places (e.g.,debug sections) and will never occur in compiler generated code sectionswhen using the small code model, so only check sections that haveSHF_ALLOC set and SHF_EXECINSTR cleared.To accommodate cases where statically initialized symbol references areunavoidable, introduce a special case for ELF input data sections thathave &quot;.rodata.prel64&quot; in their names, and in these cases, instead ofrejecting any encountered ABS64 relocations, convert them into PREL64relocations, which don&apos;t require any runtime fixups. Note that the codein question must still be modified to deal with this, as it needs toconvert the 64-bit signed offsets into absolute addresses before use.Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;Link: https://lore.kernel.org/r/20240214122845.2033971-46-ardb+git@google.comSigned-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;

            List of files:
            /linux-6.15/arch/arm64/kernel/pi/Makefile</description>
        <pubDate>Wed, 14 Feb 2024 12:28:47 +0000</pubDate>
        <dc:creator>Ard Biesheuvel &lt;ardb@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>3dfdc275 - arm64: kernel: Disable latent_entropy GCC plugin in early C runtime</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/arch/arm64/kernel/pi/Makefile#3dfdc275</link>
        <description>arm64: kernel: Disable latent_entropy GCC plugin in early C runtimeIn subsequent patches, mark portions of the early C code will be markedas __init.  Unfortunarely, __init implies __latent_entropy, and thiswould result in the early C code being instrumented in an unsafe manner.Disable the latent entropy plugin for the early C code.Acked-by: Mark Rutland &lt;mark.rutland@arm.com&gt;Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;Link: https://lore.kernel.org/r/20231129111555.3594833-44-ardb@google.comSigned-off-by: Will Deacon &lt;will@kernel.org&gt;

            List of files:
            /linux-6.15/arch/arm64/kernel/pi/Makefile</description>
        <pubDate>Wed, 29 Nov 2023 11:15:57 +0000</pubDate>
        <dc:creator>Ard Biesheuvel &lt;ardb@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>68c76ad4 - arm64: unwind: add asynchronous unwind tables to kernel and modules</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/arch/arm64/kernel/pi/Makefile#68c76ad4</link>
        <description>arm64: unwind: add asynchronous unwind tables to kernel and modulesEnable asynchronous unwind table generation for both the core kernel aswell as modules, and emit the resulting .eh_frame sections as init codeso we can use the unwind directives for code patching at boot or moduleload time.This will be used by dynamic shadow call stack support, which will relyon code patching rather than compiler codegen to emit the shadow callstack push and pop instructions.Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;Reviewed-by: Nick Desaulniers &lt;ndesaulniers@google.com&gt;Reviewed-by: Sami Tolvanen &lt;samitolvanen@google.com&gt;Tested-by: Sami Tolvanen &lt;samitolvanen@google.com&gt;Link: https://lore.kernel.org/r/20221027155908.1940624-2-ardb@kernel.orgSigned-off-by: Will Deacon &lt;will@kernel.org&gt;

            List of files:
            /linux-6.15/arch/arm64/kernel/pi/Makefile</description>
        <pubDate>Thu, 27 Oct 2022 15:59:06 +0000</pubDate>
        <dc:creator>Ard Biesheuvel &lt;ardb@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>aacd149b - arm64: head: avoid relocating the kernel twice for KASLR</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/arch/arm64/kernel/pi/Makefile#aacd149b</link>
        <description>arm64: head: avoid relocating the kernel twice for KASLRCurrently, when KASLR is in effect, we set up the kernel virtual addressspace twice: the first time, the KASLR seed is looked up in the devicetree, and the kernel virtual mapping is torn down and recreated again,after which the relocations are applied a second time. The latter stepmeans that statically initialized global pointer variables will be resetto their initial values, and to ensure that BSS variables are not set tovalues based on the initial translation, they are cleared again as well.All of this is needed because we need the command line (taken from theDT) to tell us whether or not to randomize the virtual address spacebefore entering the kernel proper. However, this code has expandedlittle by little and now creates global state unrelated to the virtualrandomization of the kernel before the mapping is torn down and set upagain, and the BSS cleared for a second time. This has created someissues in the past, and it would be better to avoid this little dance ifpossible.So instead, let&apos;s use the temporary mapping of the device tree, andexecute the bare minimum of code to decide whether or not KASLR shouldbe enabled, and what the seed is. Only then, create the virtual kernelmapping, clear BSS, etc and proceed as normal.  This avoids the issuesaround inconsistent global state due to BSS being cleared twice, and isgenerally more maintainable, as it permits us to defer all the remainingDT parsing and KASLR initialization to a later time.This means the relocation fixup code runs only a single time as well,allowing us to simplify the RELR handling code too, which is notidempotent and was therefore required to keep track of the offset thatwas applied the first time around.Note that this means we have to clone a pair of FDT library objects, sothat we can control how they are built - we need the stack protectorand other instrumentation disabled so that the code can tolerate beingcalled this early. Note that only the kernel page tables and thetemporary stack are mapped read-write at this point, which ensures thatthe early code does not modify any global state inadvertently.Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;Link: https://lore.kernel.org/r/20220624150651.1358849-21-ardb@kernel.orgSigned-off-by: Will Deacon &lt;will@kernel.org&gt;

            List of files:
            /linux-6.15/arch/arm64/kernel/pi/Makefile</description>
        <pubDate>Fri, 24 Jun 2022 15:06:50 +0000</pubDate>
        <dc:creator>Ard Biesheuvel &lt;ardb@kernel.org&gt;</dc:creator>
    </item>
</channel>
</rss>
