<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/scripts/mod/modpost.c, branch v4.9.319</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.9.319</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.9.319'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2022-06-14T14:52:40Z</updated>
<entry>
<title>modpost: fix undefined behavior of is_arm_mapping_symbol()</title>
<updated>2022-06-14T14:52:40Z</updated>
<author>
<name>Masahiro Yamada</name>
<email>masahiroy@kernel.org</email>
</author>
<published>2022-05-23T16:46:22Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=7aa910df07ae8e725756ce974d7c5ba174c8f847'/>
<id>urn:sha1:7aa910df07ae8e725756ce974d7c5ba174c8f847</id>
<content type='text'>
[ Upstream commit d6b732666a1bae0df3c3ae06925043bba34502b1 ]

The return value of is_arm_mapping_symbol() is unpredictable when "$"
is passed in.

strchr(3) says:
  The strchr() and strrchr() functions return a pointer to the matched
  character or NULL if the character is not found. The terminating null
  byte is considered part of the string, so that if c is specified as
  '\0', these functions return a pointer to the terminator.

When str[1] is '\0', strchr("axtd", str[1]) is not NULL, and str[2] is
referenced (i.e. buffer overrun).

Test code
---------

  char str1[] = "abc";
  char str2[] = "ab";

  strcpy(str1, "$");
  strcpy(str2, "$");

  printf("test1: %d\n", is_arm_mapping_symbol(str1));
  printf("test2: %d\n", is_arm_mapping_symbol(str2));

Result
------

  test1: 0
  test2: 1

Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
Reviewed-by: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>modpost: fix removing numeric suffixes</title>
<updated>2022-06-14T14:52:38Z</updated>
<author>
<name>Alexander Lobakin</name>
<email>alexandr.lobakin@intel.com</email>
</author>
<published>2022-05-24T15:27:18Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c6f44c880ab47e691e88abf7a391b74d6c59269a'/>
<id>urn:sha1:c6f44c880ab47e691e88abf7a391b74d6c59269a</id>
<content type='text'>
[ Upstream commit b5beffa20d83c4e15306c991ffd00de0d8628338 ]

With the `-z unique-symbol` linker flag or any similar mechanism,
it is possible to trigger the following:

ERROR: modpost: "param_set_uint.0" [vmlinux] is a static EXPORT_SYMBOL

The reason is that for now the condition from remove_dot():

if (m &amp;&amp; (s[n + m] == '.' || s[n + m] == 0))

which was designed to test if it's a dot or a '\0' after the suffix
is never satisfied.
This is due to that `s[n + m]` always points to the last digit of a
numeric suffix, not on the symbol next to it (from a custom debug
print added to modpost):

param_set_uint.0, s[n + m] is '0', s[n + m + 1] is '\0'

So it's off-by-one and was like that since 2014.

Fix this for the sake of any potential upcoming features, but don't
bother stable-backporting, as it's well hidden -- apart from that
LD flag, it can be triggered only with GCC LTO which never landed
upstream.

Fixes: fcd38ed0ff26 ("scripts: modpost: fix compilation warning")
Signed-off-by: Alexander Lobakin &lt;alexandr.lobakin@intel.com&gt;
Reviewed-by: Petr Mladek &lt;pmladek@suse.com&gt;
Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>x86, modpost: Replace last remnants of RETPOLINE with CONFIG_RETPOLINE</title>
<updated>2022-03-11T09:03:32Z</updated>
<author>
<name>WANG Chao</name>
<email>chao.wang@ucloud.cn</email>
</author>
<published>2018-12-10T16:37:25Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=31fb07f2a9a7a98fb8571470dd8c98638bf02c05'/>
<id>urn:sha1:31fb07f2a9a7a98fb8571470dd8c98638bf02c05</id>
<content type='text'>
commit e4f358916d528d479c3c12bd2fd03f2d5a576380 upstream.

Commit

  4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compiler support")

replaced the RETPOLINE define with CONFIG_RETPOLINE checks. Remove the
remaining pieces.

 [ bp: Massage commit message. ]

Fixes: 4cd24de3a098 ("x86/retpoline: Make CONFIG_RETPOLINE depend on compiler support")
Signed-off-by: WANG Chao &lt;chao.wang@ucloud.cn&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Reviewed-by: Zhenzhong Duan &lt;zhenzhong.duan@oracle.com&gt;
Reviewed-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;
Cc: "H. Peter Anvin" &lt;hpa@zytor.com&gt;
Cc: Andi Kleen &lt;ak@linux.intel.com&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Cc: Andy Lutomirski &lt;luto@kernel.org&gt;
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Cc: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Cc: David Woodhouse &lt;dwmw@amazon.co.uk&gt;
Cc: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Cc: Jessica Yu &lt;jeyu@kernel.org&gt;
Cc: Jiri Kosina &lt;jkosina@suse.cz&gt;
Cc: Kees Cook &lt;keescook@chromium.org&gt;
Cc: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Cc: Luc Van Oostenryck &lt;luc.vanoostenryck@gmail.com&gt;
Cc: Michal Marek &lt;michal.lkml@markovi.net&gt;
Cc: Miguel Ojeda &lt;miguel.ojeda.sandonis@gmail.com&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Tim Chen &lt;tim.c.chen@linux.intel.com&gt;
Cc: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Cc: linux-kbuild@vger.kernel.org
Cc: srinivas.eeda@oracle.com
Cc: stable &lt;stable@vger.kernel.org&gt;
Cc: x86-ml &lt;x86@kernel.org&gt;
Link: https://lkml.kernel.org/r/20181210163725.95977-1-chao.wang@ucloud.cn
[bwh: Backported to 4.9: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>modpost: skip ELF local symbols during section mismatch check</title>
<updated>2019-12-21T09:41:17Z</updated>
<author>
<name>Paul Walmsley</name>
<email>paul.walmsley@sifive.com</email>
</author>
<published>2018-11-21T21:14:13Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=53a7d908b4730f599b4b0f9476e900b88d2a871f'/>
<id>urn:sha1:53a7d908b4730f599b4b0f9476e900b88d2a871f</id>
<content type='text'>
[ Upstream commit a4d26f1a0958bb1c2b60c6f1e67c6f5d43e2647b ]

During development of a serial console driver with a gcc 8.2.0
toolchain for RISC-V, the following modpost warning appeared:

----
WARNING: vmlinux.o(.data+0x19b10): Section mismatch in reference from the variable .LANCHOR1 to the function .init.text:sifive_serial_console_setup()
The variable .LANCHOR1 references
the function __init sifive_serial_console_setup()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
----

".LANCHOR1" is an ELF local symbol, automatically created by gcc's section
anchor generation code:

https://gcc.gnu.org/onlinedocs/gccint/Anchored-Addresses.html

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/varasm.c;h=cd9591a45617464946dcf9a126dde277d9de9804;hb=9fb89fa845c1b2e0a18d85ada0b077c84508ab78#l7473

This was verified by compiling the kernel with -fno-section-anchors
and observing that the ".LANCHOR1" ELF local symbol disappeared, and
modpost no longer warned about the section mismatch.  The serial
driver code idiom triggering the warning is standard Linux serial
driver practice that has a specific whitelist inclusion in modpost.c.

I'm neither a modpost nor an ELF expert, but naively, it doesn't seem
useful for modpost to report section mismatch warnings caused by ELF
local symbols by default.  Local symbols have compiler-generated
names, and thus bypass modpost's whitelisting algorithm, which relies
on the presence of a non-autogenerated symbol name.  This increases
the likelihood that false positive warnings will be generated (as in
the above case).

Thus, disable section mismatch reporting on ELF local symbols.  The
rationale here is similar to that of commit 2e3a10a1551d ("ARM: avoid
ARM binutils leaking ELF local symbols") and of similar code already
present in modpost.c:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/mod/modpost.c?h=v4.19-rc4&amp;id=7876320f88802b22d4e2daf7eb027dd14175a0f8#n1256

This third version of the patch implements a suggestion from Masahiro
Yamada &lt;yamada.masahiro@socionext.com&gt; to restructure the code as an
additional pattern matching step inside secref_whitelist(), and
further improves the patch description.

Signed-off-by: Paul Walmsley &lt;paul.walmsley@sifive.com&gt;
Signed-off-by: Paul Walmsley &lt;paul@pwsan.com&gt;
Acked-by: Sam Ravnborg &lt;sam@ravnborg.org&gt;
Signed-off-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>modpost: validate symbol names also in find_elf_symbol</title>
<updated>2019-02-12T18:44:52Z</updated>
<author>
<name>Sami Tolvanen</name>
<email>samitolvanen@google.com</email>
</author>
<published>2018-10-23T22:15:35Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ab70d98b39f2f8e222a1e67c8447d09c48c9b8b0'/>
<id>urn:sha1:ab70d98b39f2f8e222a1e67c8447d09c48c9b8b0</id>
<content type='text'>
[ Upstream commit 5818c683a619c534c113e1f66d24f636defc29bc ]

If an ARM mapping symbol shares an address with a valid symbol,
find_elf_symbol can currently return the mapping symbol instead, as the
symbol is not validated. This can result in confusing warnings:

  WARNING: vmlinux.o(.text+0x18f4028): Section mismatch in reference
  from the function set_reset_devices() to the variable .init.text:$x.0

This change adds a call to is_valid_name to find_elf_symbol, similarly
to how it's already used in find_elf_symbol2.

Signed-off-by: Sami Tolvanen &lt;samitolvanen@google.com&gt;
Signed-off-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scripts: modpost: check memory allocation results</title>
<updated>2018-09-15T07:42:57Z</updated>
<author>
<name>Randy Dunlap</name>
<email>rdunlap@infradead.org</email>
</author>
<published>2018-08-15T19:30:38Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=94279fa683e9984261701b5a42160c258b61d3e9'/>
<id>urn:sha1:94279fa683e9984261701b5a42160c258b61d3e9</id>
<content type='text'>
[ Upstream commit 1f3aa9002dc6a0d59a4b599b4fc8f01cf43ef014 ]

Fix missing error check for memory allocation functions in
scripts/mod/modpost.c.

Fixes kernel bugzilla #200319:
https://bugzilla.kernel.org/show_bug.cgi?id=200319

Signed-off-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Cc: Yuexing Wang &lt;wangyxlandq@gmail.com&gt;
Signed-off-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>module/retpoline: Warn about missing retpoline in module</title>
<updated>2018-02-13T11:35:58Z</updated>
<author>
<name>Andi Kleen</name>
<email>ak@linux.intel.com</email>
</author>
<published>2018-01-25T23:50:28Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a1745ad92f50e95b6c2d101cd9b77253969ddccc'/>
<id>urn:sha1:a1745ad92f50e95b6c2d101cd9b77253969ddccc</id>
<content type='text'>
(cherry picked from commit caf7501a1b4ec964190f31f9c3f163de252273b8)

There's a risk that a kernel which has full retpoline mitigations becomes
vulnerable when a module gets loaded that hasn't been compiled with the
right compiler or the right option.

To enable detection of that mismatch at module load time, add a module info
string "retpoline" at build time when the module was compiled with
retpoline support. This only covers compiled C source, but assembler source
or prebuilt object files are not checked.

If a retpoline enabled kernel detects a non retpoline protected module at
load time, print a warning and report it in the sysfs vulnerability file.

[ tglx: Massaged changelog ]

Signed-off-by: Andi Kleen &lt;ak@linux.intel.com&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: David Woodhouse &lt;dwmw2@infradead.org&gt;
Cc: gregkh@linuxfoundation.org
Cc: torvalds@linux-foundation.org
Cc: jeyu@kernel.org
Cc: arjan@linux.intel.com
Link: https://lkml.kernel.org/r/20180125235028.31211-1-andi@firstfloor.org
Signed-off-by: David Woodhouse &lt;dwmw@amazon.co.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>objtool, modules: Discard objtool annotation sections for modules</title>
<updated>2018-01-17T08:38:58Z</updated>
<author>
<name>Josh Poimboeuf</name>
<email>jpoimboe@redhat.com</email>
</author>
<published>2017-03-01T18:04:44Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=35aee626fa6311c3942fedd50c50f6748922e89f'/>
<id>urn:sha1:35aee626fa6311c3942fedd50c50f6748922e89f</id>
<content type='text'>
commit e390f9a9689a42f477a6073e2e7df530a4c1b740 upstream.

The '__unreachable' and '__func_stack_frame_non_standard' sections are
only used at compile time.  They're discarded for vmlinux but they
should also be discarded for modules.

Since this is a recurring pattern, prefix the section names with
".discard.".  It's a nice convention and vmlinux.lds.h already discards
such sections.

Also remove the 'a' (allocatable) flag from the __unreachable section
since it doesn't make sense for a discarded section.

Suggested-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Josh Poimboeuf &lt;jpoimboe@redhat.com&gt;
Cc: Jessica Yu &lt;jeyu@redhat.com&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Fixes: d1091c7fa3d5 ("objtool: Improve detection of BUG() and other dead ends")
Link: http://lkml.kernel.org/r/20170301180444.lhd53c5tibc4ns77@treble
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
[dwmw2: Remove the unreachable part in backporting since it's not here yet]
Signed-off-by: David Woodhouse &lt;dwmw@amazon.co.ku&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>nmi_backtrace: generate one-line reports for idle cpus</title>
<updated>2016-10-08T01:46:30Z</updated>
<author>
<name>Chris Metcalf</name>
<email>cmetcalf@mellanox.com</email>
</author>
<published>2016-10-08T00:02:55Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=6727ad9e206cc08b80d8000a4d67f8417e53539d'/>
<id>urn:sha1:6727ad9e206cc08b80d8000a4d67f8417e53539d</id>
<content type='text'>
When doing an nmi backtrace of many cores, most of which are idle, the
output is a little overwhelming and very uninformative.  Suppress
messages for cpus that are idling when they are interrupted and just
emit one line, "NMI backtrace for N skipped: idling at pc 0xNNN".

We do this by grouping all the cpuidle code together into a new
.cpuidle.text section, and then checking the address of the interrupted
PC to see if it lies within that section.

This commit suitably tags x86 and tile idle routines, and only adds in
the minimal framework for other architectures.

Link: http://lkml.kernel.org/r/1472487169-14923-5-git-send-email-cmetcalf@mellanox.com
Signed-off-by: Chris Metcalf &lt;cmetcalf@mellanox.com&gt;
Acked-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Tested-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Tested-by: Daniel Thompson &lt;daniel.thompson@linaro.org&gt; [arm]
Tested-by: Petr Mladek &lt;pmladek@suse.com&gt;
Cc: Aaron Tomlin &lt;atomlin@redhat.com&gt;
Cc: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Cc: "Rafael J. Wysocki" &lt;rjw@rjwysocki.net&gt;
Cc: Russell King &lt;linux@arm.linux.org.uk&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Ingo Molnar &lt;mingo@elte.hu&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>powerpc: Simplify module TOC handling</title>
<updated>2016-01-21T03:10:56Z</updated>
<author>
<name>Alan Modra</name>
<email>amodra@gmail.com</email>
</author>
<published>2016-01-15T09:52:22Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c153693d7eb9eeb28478aa2deaaf0b4e7b5ff5e9'/>
<id>urn:sha1:c153693d7eb9eeb28478aa2deaaf0b4e7b5ff5e9</id>
<content type='text'>
PowerPC64 uses the symbol .TOC. much as other targets use
_GLOBAL_OFFSET_TABLE_. It identifies the value of the GOT pointer (or in
powerpc parlance, the TOC pointer). Global offset tables are generally
local to an executable or shared library, or in the kernel, module. Thus
it does not make sense for a module to resolve a relocation against
.TOC. to the kernel's .TOC. value. A module has its own .TOC., and
indeed the powerpc64 module relocation processing ignores the kernel
value of .TOC. and instead calculates a module-local value.

This patch removes code involved in exporting the kernel .TOC., tweaks
modpost to ignore an undefined .TOC., and the module loader to twiddle
the section symbol so that .TOC. isn't seen as undefined.

Note that if the kernel was compiled with -msingle-pic-base then ELFv2
would not have function global entry code setting up r2. In that case
the module call stubs would need to be modified to set up r2 using the
kernel .TOC. value, requiring some of this code to be reinstated.

mpe: Furthermore a change in binutils master (not yet released) causes
the current way we handle the TOC to no longer work when building with
MODVERSIONS=y and RELOCATABLE=n. The symptom is that modules can not be
loaded due to there being no version found for TOC.

Cc: stable@vger.kernel.org # 3.16+
Signed-off-by: Alan Modra &lt;amodra@gmail.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
</content>
</entry>
</feed>
