<?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 archrandom.h</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>9592eef7 - random: remove CONFIG_ARCH_RANDOM</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/arch/arm/include/asm/archrandom.h#9592eef7</link>
        <description>random: remove CONFIG_ARCH_RANDOMWhen RDRAND was introduced, there was much discussion on whether itshould be trusted and how the kernel should handle that. Initially, twomechanisms cropped up, CONFIG_ARCH_RANDOM, a compile time switch, and&quot;nordrand&quot;, a boot-time switch.Later the thinking evolved. With a properly designed RNG, using RDRANDvalues alone won&apos;t harm anything, even if the outputs are malicious.Rather, the issue is whether those values are being *trusted* to be goodor not. And so a new set of options were introduced as the realones that people use -- CONFIG_RANDOM_TRUST_CPU and &quot;random.trust_cpu&quot;.With these options, RDRAND is used, but it&apos;s not always credited. So inthe worst case, it does nothing, and in the best case, maybe it helps.Along the way, CONFIG_ARCH_RANDOM&apos;s meaning got sort of pulled into thecenter and became something certain platforms force-select.The old options don&apos;t really help with much, and it&apos;s a bit odd to havespecial handling for these instructions when the kernel can deal finewith the existence or untrusted existence or broken existence ornon-existence of that CPU capability.Simplify the situation by removing CONFIG_ARCH_RANDOM and using theordinary asm-generic fallback pattern instead, keeping the two optionsthat are actually used. For now it leaves &quot;nordrand&quot; for now, as theremoval of that will take a different route.Acked-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;Acked-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;Acked-by: Borislav Petkov &lt;bp@suse.de&gt;Acked-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;Acked-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;Signed-off-by: Jason A. Donenfeld &lt;Jason@zx2c4.com&gt;

            List of files:
            /linux-6.15/arch/arm/include/asm/archrandom.h</description>
        <pubDate>Tue, 05 Jul 2022 18:48:41 +0000</pubDate>
        <dc:creator>Jason A. Donenfeld &lt;Jason@zx2c4.com&gt;</dc:creator>
    </item>
<item>
        <title>a37e31fc - firmware: smccc: Introduce SMCCC TRNG framework</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/arch/arm/include/asm/archrandom.h#a37e31fc</link>
        <description>firmware: smccc: Introduce SMCCC TRNG frameworkThe ARM DEN0098 document describe an SMCCC based firmware service todeliver hardware generated random numbers. Its existence is advertisedaccording to the SMCCC v1.1 specification.Add a (dummy) call to probe functions implemented in each architecture(ARM and arm64), to determine the existence of this interface.For now this return false, but this will be overwritten by eacharchitecture&apos;s support patch.Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;Reviewed-by: Sudeep Holla &lt;sudeep.holla@arm.com&gt;Signed-off-by: Will Deacon &lt;will@kernel.org&gt;

            List of files:
            /linux-6.15/arch/arm/include/asm/archrandom.h</description>
        <pubDate>Wed, 06 Jan 2021 10:34:50 +0000</pubDate>
        <dc:creator>Andre Przywara &lt;andre.przywara@arm.com&gt;</dc:creator>
    </item>
</channel>
</rss>
