08 Oct, 2019
1 commit
-
With the use of the barrier implied by barrier_data(), there is no need
for memzero_explicit() to be extern. Making it inline saves the overhead
of a function call, and allows the code to be reused in arch/*/purgatory
without having to duplicate the implementation.Tested-by: Hans de Goede
Signed-off-by: Arvind Sankar
Reviewed-by: Hans de Goede
Cc: Ard Biesheuvel
Cc: Borislav Petkov
Cc: H . Peter Anvin
Cc: Herbert Xu
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Stephan Mueller
Cc: Thomas Gleixner
Cc: linux-crypto@vger.kernel.org
Cc: linux-s390@vger.kernel.org
Fixes: 906a4bb97f5d ("crypto: sha256 - Use get/put_unaligned_be32 to get input, memzero_explicit")
Link: https://lkml.kernel.org/r/20191007220000.GA408752@rani.riverdale.lan
Signed-off-by: Ingo Molnar
26 Sep, 2019
2 commits
-
As already done for snprintf(), add a check in strscpy() for giant (i.e.
likely negative and/or miscalculated) copy sizes, WARN, and error out.Link: http://lkml.kernel.org/r/201907260928.23DE35406@keescook
Signed-off-by: Kees Cook
Cc: Joe Perches
Cc: Rasmus Villemoes
Cc: Yann Droneaud
Cc: David Laight
Cc: Jonathan Corbet
Cc: Stephen Kitt
Cc: Jann Horn
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
core-api should show all the various string functions including the newly
added stracpy and stracpy_pad.Miscellanea:
o Update the Returns: value for strscpy
o fix a defect with %NUL)[joe@perches.com: correct return of -E2BIG descriptions]
Link: http://lkml.kernel.org/r/29f998b4c1a9d69fbeae70500ba0daa4b340c546.1563889130.git.joe@perches.com
Link: http://lkml.kernel.org/r/224a6ebf39955f4107c0c376d66155d970e46733.1563841972.git.joe@perches.com
Signed-off-by: Joe Perches
Reviewed-by: Kees Cook
Cc: Jonathan Corbet
Cc: Stephen Kitt
Cc: Nitin Gote
Cc: Rasmus Villemoes
Cc: Jann Horn
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 Jul, 2019
1 commit
-
Patch series "lib/string: search for NUL with strchr/strnchr".
I noticed an inconsistency where strchr and strnchr do not behave the
same with respect to the trailing NUL. strchr is standardised and the
kernel function conforms, and the kernel relies on the behavior. So,
naturally strchr stays as-is and strnchr is what I change.While writing a few tests to verify that my new strnchr loop was sane, I
noticed that the tests for memset16/32/64 had a problem. Since it's all
about the lib/string.c file I made a short series of it all...This patch (of 3):
strchr considers the terminating NUL to be part of the string, and NUL
can thus be searched for with that function. For consistency, do the
same with strnchr.Link: http://lkml.kernel.org/r/20190506124634.6807-2-peda@axentia.se
Signed-off-by: Peter Rosin
Cc: Matthew Wilcox
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
09 Apr, 2019
1 commit
-
We have a function to copy strings safely and we have a function to copy
strings and zero the tail of the destination (if source string is
shorter than destination buffer) but we do not have a function to do
both at once. This means developers must write this themselves if they
desire this functionality. This is a chore, and also leaves us open to
off by one errors unnecessarily.Add a function that calls strscpy() then memset()s the tail to zero if
the source string is shorter than the destination buffer.Acked-by: Kees Cook
Signed-off-by: Tobin C. Harding
Signed-off-by: Shuah Khan
06 Apr, 2019
1 commit
-
A recent optimization in Clang (r355672) lowers comparisons of the
return value of memcmp against zero to comparisons of the return value
of bcmp against zero. This helps some platforms that implement bcmp
more efficiently than memcmp. glibc simply aliases bcmp to memcmp, but
an optimized implementation is in the works.This results in linkage failures for all targets with Clang due to the
undefined symbol. For now, just implement bcmp as a tailcail to memcmp
to unbreak the build. This routine can be further optimized in the
future.Other ideas discussed:
* A weak alias was discussed, but breaks for architectures that define
their own implementations of memcmp since aliases to declarations are
not permitted (only definitions). Arch-specific memcmp
implementations typically declare memcmp in C headers, but implement
them in assembly.* -ffreestanding also is used sporadically throughout the kernel.
* -fno-builtin-bcmp doesn't work when doing LTO.
Link: https://bugs.llvm.org/show_bug.cgi?id=41035
Link: https://code.woboq.org/userspace/glibc/string/memcmp.c.html#bcmp
Link: https://github.com/llvm/llvm-project/commit/8e16d73346f8091461319a7dfc4ddd18eedcff13
Link: https://github.com/ClangBuiltLinux/linux/issues/416
Link: http://lkml.kernel.org/r/20190313211335.165605-1-ndesaulniers@google.com
Signed-off-by: Nick Desaulniers
Reported-by: Nathan Chancellor
Reported-by: Adhemerval Zanella
Suggested-by: Arnd Bergmann
Suggested-by: James Y Knight
Suggested-by: Masahiro Yamada
Suggested-by: Nathan Chancellor
Suggested-by: Rasmus Villemoes
Acked-by: Steven Rostedt (VMware)
Reviewed-by: Nathan Chancellor
Tested-by: Nathan Chancellor
Reviewed-by: Masahiro Yamada
Reviewed-by: Andy Shevchenko
Cc: David Laight
Cc: Rasmus Villemoes
Cc: Namhyung Kim
Cc: Greg Kroah-Hartman
Cc: Alexander Shishkin
Cc: Dan Williams
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
16 Oct, 2018
1 commit
-
kbuild robot reports that since commit ce76d938dd98 ("lib: Add memcat_p():
paste 2 pointer arrays together") the ia64/hp/sim/boot fails to link:> LD arch/ia64/hp/sim/boot/bootloader
> lib/string.o: In function `__memcat_p':
> string.c:(.text+0x1f22): undefined reference to `__kmalloc'
> string.c:(.text+0x1ff2): undefined reference to `__kmalloc'
> make[1]: *** [arch/ia64/hp/sim/boot/Makefile:37: arch/ia64/hp/sim/boot/bootloader] Error 1The reason is, the above commit, via __memcat_p(), adds a call to
__kmalloc to string.o, which happens to be used in the bootloader, but
there's no kmalloc or slab or anything.Since the linker would only pull in objects that contain referenced
symbols, moving __memcat_p() to a different compilation unit solves the
problem.Fixes: ce76d938dd98 ("lib: Add memcat_p(): paste 2 pointer arrays together")
Signed-off-by: Alexander Shishkin
Reported-by: kbuild test robot
Cc: Fenghua Yu
Cc: Tony Luck
Cc: Joe Perches
Signed-off-by: Greg Kroah-Hartman
11 Oct, 2018
1 commit
-
This adds a helper to paste 2 pointer arrays together, useful for merging
various types of attribute arrays. There are a few places in the kernel
tree where this is open coded, and I just added one more in the STM class.The naming is inspired by memset_p() and memcat(), and partial credit for
it goes to Andy Shevchenko.This patch adds the function wrapped in a type-enforcing macro and a test
module.Signed-off-by: Alexander Shishkin
Reviewed-by: Andy Shevchenko
Tested-by: Mathieu Poirier
Signed-off-by: Greg Kroah-Hartman
02 Feb, 2018
1 commit
-
strscpy() performs the word-at-a-time optimistic reads. So it may may
access the memory past the end of the object, which is perfectly fine
since strscpy() doesn't use that (past-the-end) data and makes sure the
optimistic read won't cross a page boundary.Use new read_word_at_a_time() to shut up the KASAN.
Note that this potentially could hide some bugs. In example bellow,
stscpy() will copy more than we should (1-3 extra uninitialized bytes):char dst[8];
char *src;src = kmalloc(5, GFP_KERNEL);
memset(src, 0xff, 5);
strscpy(dst, src, 8);Signed-off-by: Andrey Ryabinin
Signed-off-by: Linus Torvalds
18 Nov, 2017
1 commit
-
Extract the string test code into its own source file, to allow
compiling it either to a loadable module, or built into the kernel.Fixes: 03270c13c5ffaa6a ("lib/string.c: add testcases for memset16/32/64")
Link: http://lkml.kernel.org/r/1505397744-3387-1-git-send-email-geert@linux-m68k.org
Signed-off-by: Geert Uytterhoeven
Cc: Matthew Wilcox
Cc: Shuah Khan
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
09 Sep, 2017
3 commits
-
This is mostly to keep the number of static checker warnings down so we
can spot new bugs instead of them being drowned in noise. This function
doesn't return normal kernel error codes but instead the return value is
used to display exactly which memory failed. I chose -1 as hopefully
that's a helpful thing to print.Link: http://lkml.kernel.org/r/20170817115420.uikisjvfmtrqkzjn@mwanda
Signed-off-by: Dan Carpenter
Cc: Matthew Wilcox
Cc: Stephen Rothwell
Cc: Kees Cook
Cc: Bjorn Helgaas
Cc: Mauro Carvalho Chehab
Cc: Heikki Krogerus
Cc: Daniel Micay
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
[akpm@linux-foundation.org: minor tweaks]
Link: http://lkml.kernel.org/r/20170720184539.31609-3-willy@infradead.org
Signed-off-by: Matthew Wilcox
Cc: "H. Peter Anvin"
Cc: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Cc: David Miller
Cc: Ingo Molnar
Cc: Ivan Kokshaysky
Cc: Matt Turner
Cc: Michael Ellerman
Cc: Minchan Kim
Cc: Ralf Baechle
Cc: Richard Henderson
Cc: Russell King
Cc: Sam Ravnborg
Cc: Sergey Senozhatsky
Cc: Thomas Gleixner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Patch series "Multibyte memset variations", v4.
A relatively common idiom we're missing is a function to fill an area of
memory with a pattern which is larger than a single byte. I first
noticed this with a zram patch which wanted to fill a page with an
'unsigned long' value. There turn out to be quite a few places in the
kernel which can benefit from using an optimised function rather than a
loop; sometimes text size, sometimes speed, and sometimes both. The
optimised PowerPC version (not included here) improves performance by
about 30% on POWER8 on just the raw memset_l().Most of the extra lines of code come from the three testcases I added.
This patch (of 8):
memset16(), memset32() and memset64() are like memset(), but allow the
caller to fill the destination with a value larger than a single byte.
memset_l() and memset_p() allow the caller to use unsigned long and
pointer values respectively.Link: http://lkml.kernel.org/r/20170720184539.31609-2-willy@infradead.org
Signed-off-by: Matthew Wilcox
Cc: "H. Peter Anvin"
Cc: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Cc: David Miller
Cc: Ingo Molnar
Cc: Ivan Kokshaysky
Cc: Matt Turner
Cc: Michael Ellerman
Cc: Minchan Kim
Cc: Ralf Baechle
Cc: Richard Henderson
Cc: Russell King
Cc: Sam Ravnborg
Cc: Sergey Senozhatsky
Cc: Thomas Gleixner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
13 Jul, 2017
1 commit
-
This adds support for compiling with a rough equivalent to the glibc
_FORTIFY_SOURCE=1 feature, providing compile-time and runtime buffer
overflow checks for string.h functions when the compiler determines the
size of the source or destination buffer at compile-time. Unlike glibc,
it covers buffer reads in addition to writes.GNU C __builtin_*_chk intrinsics are avoided because they would force a
much more complex implementation. They aren't designed to detect read
overflows and offer no real benefit when using an implementation based
on inline checks. Inline checks don't add up to much code size and
allow full use of the regular string intrinsics while avoiding the need
for a bunch of _chk functions and per-arch assembly to avoid wrapper
overhead.This detects various overflows at compile-time in various drivers and
some non-x86 core kernel code. There will likely be issues caught in
regular use at runtime too.Future improvements left out of initial implementation for simplicity,
as it's all quite optional and can be done incrementally:* Some of the fortified string functions (strncpy, strcat), don't yet
place a limit on reads from the source based on __builtin_object_size of
the source buffer.* Extending coverage to more string functions like strlcat.
* It should be possible to optionally use __builtin_object_size(x, 1) for
some functions (C strings) to detect intra-object overflows (like
glibc's _FORTIFY_SOURCE=2), but for now this takes the conservative
approach to avoid likely compatibility issues.* The compile-time checks should be made available via a separate config
option which can be enabled by default (or always enabled) once enough
time has passed to get the issues it catches fixed.Kees said:
"This is great to have. While it was out-of-tree code, it would have
blocked at least CVE-2016-3858 from being exploitable (improper size
argument to strlcpy()). I've sent a number of fixes for
out-of-bounds-reads that this detected upstream already"[arnd@arndb.de: x86: fix fortified memcpy]
Link: http://lkml.kernel.org/r/20170627150047.660360-1-arnd@arndb.de
[keescook@chromium.org: avoid panic() in favor of BUG()]
Link: http://lkml.kernel.org/r/20170626235122.GA25261@beast
[keescook@chromium.org: move from -mm, add ARCH_HAS_FORTIFY_SOURCE, tweak Kconfig help]
Link: http://lkml.kernel.org/r/20170526095404.20439-1-danielmicay@gmail.com
Link: http://lkml.kernel.org/r/1497903987-21002-8-git-send-email-keescook@chromium.org
Signed-off-by: Daniel Micay
Signed-off-by: Kees Cook
Signed-off-by: Arnd Bergmann
Acked-by: Kees Cook
Cc: Mark Rutland
Cc: Daniel Axtens
Cc: Rasmus Villemoes
Cc: Andy Shevchenko
Cc: Chris Metcalf
Cc: Thomas Gleixner
Cc: "H. Peter Anvin"
Cc: Ingo Molnar
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
05 May, 2017
1 commit
-
Pull USB updates from Greg KH:
"Here is the big USB patchset for 4.12-rc1.Lots of good stuff here, after many many many attempts, the kernel
finally has a working typeC interface, many thanks to Heikki and
Guenter and others who have taken the time to get this merged. It
wasn't an easy path for them at all.There's also a staging driver that uses this new api, which is why
it's coming in through this tree.Along with that, there's the usual huge number of changes for gadget
drivers, xhci, and other stuff. Johan also finally refactored pretty
much every driver that was looking at USB endpoints to do it in a
common way, which will help prevent any "badly-formed" devices from
causing problems in drivers. That too wasn't a simple task.All of these have been in linux-next for a while with no reported
issues"* tag 'usb-4.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (263 commits)
staging: typec: Fairchild FUSB302 Type-c chip driver
staging: typec: Type-C Port Controller Interface driver (tcpci)
staging: typec: USB Type-C Port Manager (tcpm)
usb: host: xhci: remove #ifdef around PM functions
usb: musb: don't mark of_dev_auxdata as initdata
usb: misc: legousbtower: Fix buffers on stack
USB: Revert "cdc-wdm: fix "out-of-sync" due to missing notifications"
usb: Make sure usb/phy/of gets built-in
USB: storage: e-mail update in drivers/usb/storage/unusual_devs.h
usb: host: xhci: print correct command ring address
usb: host: xhci: delete sp_dma_buffers for scratchpad
usb: host: xhci: using correct specification chapter reference for DCBAAP
xhci: switch to pci_alloc_irq_vectors
usb: host: xhci-plat: set resume_quirk() for R-Car controllers
usb: host: xhci-plat: add resume_quirk()
usb: host: xhci-plat: enable clk in resume timing
usb: host: plat: Enable xHCI plat runtime PM
USB: serial: ftdi_sio: add device ID for Microsemi/Arrow SF2PLUS Dev Kit
USB: serial: constify static arrays
usb: fix some references for /proc/bus/usb
...
03 Apr, 2017
1 commit
-
./lib/string.c:134: WARNING: Inline emphasis start-string without end-string.
./mm/filemap.c:522: WARNING: Inline interpreted text or phrase reference start-string without end-string.
./mm/filemap.c:1283: ERROR: Unexpected indentation.
./mm/filemap.c:3003: WARNING: Inline interpreted text or phrase reference start-string without end-string.
./mm/vmalloc.c:1544: WARNING: Inline emphasis start-string without end-string.
./mm/page_alloc.c:4245: ERROR: Unexpected indentation.
./ipc/util.c:676: ERROR: Unexpected indentation.
./drivers/pci/irq.c:35: WARNING: Block quote ends without a blank line; unexpected unindent.
./security/security.c:109: ERROR: Unexpected indentation.
./security/security.c:110: WARNING: Definition list ends without a blank line; unexpected unindent.
./block/genhd.c:275: WARNING: Inline strong start-string without end-string.
./block/genhd.c:283: WARNING: Inline strong start-string without end-string.
./include/linux/clk.h:134: WARNING: Inline emphasis start-string without end-string.
./include/linux/clk.h:134: WARNING: Inline emphasis start-string without end-string.
./ipc/util.c:477: ERROR: Unknown target name: "s".Signed-off-by: Mauro Carvalho Chehab
Acked-by: Bjorn Helgaas
Signed-off-by: Jonathan Corbet
23 Mar, 2017
1 commit
-
Make a simple helper for matching strings with sysfs
attribute files. In most parts the same as match_string(),
except sysfs_match_string() uses sysfs_streq() instead of
strcmp() for matching. This is more convenient when used
with sysfs attributes.Signed-off-by: Heikki Krogerus
Reviewed-by: Mika Westerberg
Reviewed-by: Felipe Balbi
Tested-by: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman
18 Mar, 2016
2 commits
-
Create the kstrtobool_from_user() helper and move strtobool() logic into
the new kstrtobool() (matching all the other kstrto* functions).
Provides an inline wrapper for existing strtobool() callers.Signed-off-by: Kees Cook
Cc: Joe Perches
Cc: Andy Shevchenko
Cc: Rasmus Villemoes
Cc: Daniel Borkmann
Cc: Amitkumar Karwar
Cc: Nishant Sarmukadam
Cc: Kalle Valo
Cc: Steve French
Cc: Michael Ellerman
Cc: Heiko Carstens
Cc: Martin Schwidefsky
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Occasionally we have to search for an occurrence of a string in an array
of strings. Make a simple helper for that purpose.Signed-off-by: Andy Shevchenko
Cc: "David S. Miller"
Cc: Bartlomiej Zolnierkiewicz
Cc: David Airlie
Cc: David Woodhouse
Cc: Dmitry Eremin-Solenikov
Cc: Greg Kroah-Hartman
Cc: Heikki Krogerus
Cc: Linus Walleij
Cc: Mika Westerberg
Cc: Rafael J. Wysocki
Cc: Sebastian Reichel
Cc: Tejun Heo
Cc: Rasmus Villemoes
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
11 Nov, 2015
1 commit
-
8-byte constant is too big for long and compiler complains about this.
lib/string.c:907:20: warning: constant 0x0101010101010101 is so big it is long
Append ULL suffix to explicitly show its type.
Signed-off-by: Andy Shevchenko
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
07 Oct, 2015
1 commit
-
It's possible that the destination can be shadowed in userspace
(as, for example, the perf buffers are now). So we should take
care not to leak data that could be inspected by userspace.Signed-off-by: Chris Metcalf
11 Sep, 2015
1 commit
-
The strscpy() API is intended to be used instead of strlcpy(),
and instead of most uses of strncpy().- Unlike strlcpy(), it doesn't read from memory beyond (src + size).
- Unlike strlcpy() or strncpy(), the API provides an easy way to check
for destination buffer overflow: an -E2BIG error return value.- The provided implementation is robust in the face of the source
buffer being asynchronously changed during the copy, unlike the
current implementation of strlcpy().- Unlike strncpy(), the destination buffer will be NUL-terminated
if the string in the source buffer is too long.- Also unlike strncpy(), the destination buffer will not be updated
beyond the NUL termination, avoiding strncpy's behavior of zeroing
the entire tail end of the destination buffer. (A memset() after
the strscpy() can be used if this behavior is desired.)- The implementation should be reasonably performant on all
platforms since it uses the asm/word-at-a-time.h API rather than
simple byte copy. Kernel-to-kernel string copy is not considered
to be performance critical in any case.Signed-off-by: Chris Metcalf
26 Jun, 2015
1 commit
-
Strings are sometimes sanitized by replacing a certain character (often
'/') by another (often '!'). In a few places, this is done the same way
Schlemiel the Painter would do it. Others are slightly smarter but still
do multiple strchr() calls. Introduce strreplace() to do this using a
single function call and a single pass over the string.One would expect the return value to be one of three things: void, s, or
the number of replacements made. I chose the fourth, returning a pointer
to the end of the string. This is more likely to be useful (for example
allowing the caller to avoid a strlen call).Signed-off-by: Rasmus Villemoes
Cc: "Theodore Ts'o"
Cc: Greg Kroah-Hartman
Cc: Neil Brown
Cc: Steven Rostedt
Cc: Joe Perches
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
04 May, 2015
1 commit
-
In commit 0b053c951829 ("lib: memzero_explicit: use barrier instead
of OPTIMIZER_HIDE_VAR"), we made memzero_explicit() more robust in
case LTO would decide to inline memzero_explicit() and eventually
find out it could be elimiated as dead store.While using barrier() works well for the case of gcc, recent efforts
from LLVMLinux people suggest to use llvm as an alternative to gcc,
and there, Stephan found in a simple stand-alone user space example
that llvm could nevertheless optimize and thus elimitate the memset().
A similar issue has been observed in the referenced llvm bug report,
which is regarded as not-a-bug.Based on some experiments, icc is a bit special on its own, while it
doesn't seem to eliminate the memset(), it could do so with an own
implementation, and then result in similar findings as with llvm.The fix in this patch now works for all three compilers (also tested
with more aggressive optimization levels). Arguably, in the current
kernel tree it's more of a theoretical issue, but imho, it's better
to be pedantic about it.It's clearly visible with gcc/llvm though, with the below code: if we
would have used barrier() only here, llvm would have omitted clearing,
not so with barrier_data() variant:static inline void memzero_explicit(void *s, size_t count)
{
memset(s, 0, count);
barrier_data(s);
}int main(void)
{
char buff[20];
memzero_explicit(buff, sizeof(buff));
return 0;
}$ gcc -O2 test.c
$ gdb a.out
(gdb) disassemble main
Dump of assembler code for function main:
0x0000000000400400 : lea -0x28(%rsp),%rax
0x0000000000400405 : movq $0x0,-0x28(%rsp)
0x000000000040040e : movq $0x0,-0x20(%rsp)
0x0000000000400417 : movl $0x0,-0x18(%rsp)
0x000000000040041f : xor %eax,%eax
0x0000000000400421 : retq
End of assembler dump.$ clang -O2 test.c
$ gdb a.out
(gdb) disassemble main
Dump of assembler code for function main:
0x00000000004004f0 : xorps %xmm0,%xmm0
0x00000000004004f3 : movaps %xmm0,-0x18(%rsp)
0x00000000004004f8 : movl $0x0,-0x8(%rsp)
0x0000000000400500 : lea -0x18(%rsp),%rax
0x0000000000400505 : xor %eax,%eax
0x0000000000400507 : retq
End of assembler dump.As gcc, clang, but also icc defines __GNUC__, it's sufficient to define
this in compiler-gcc.h only to be picked up. For a fallback or otherwise
unsupported compiler, we define it as a barrier. Similarly, for ecc which
does not support gcc inline asm.Reference: https://llvm.org/bugs/show_bug.cgi?id=15495
Reported-by: Stephan Mueller
Tested-by: Stephan Mueller
Signed-off-by: Daniel Borkmann
Cc: Theodore Ts'o
Cc: Stephan Mueller
Cc: Hannes Frederic Sowa
Cc: mancha security
Cc: Mark Charlebois
Cc: Behan Webster
Signed-off-by: Herbert Xu
20 Mar, 2015
1 commit
-
OPTIMIZER_HIDE_VAR(), as defined when using gcc, is insufficient to
ensure protection from dead store optimization.For the random driver and crypto drivers, calls are emitted ...
$ gdb vmlinux
(gdb) disassemble memzero_explicit
Dump of assembler code for function memzero_explicit:
0xffffffff813a18b0 : push %rbp
0xffffffff813a18b1 : mov %rsi,%rdx
0xffffffff813a18b4 : xor %esi,%esi
0xffffffff813a18b6 : mov %rsp,%rbp
0xffffffff813a18b9 : callq 0xffffffff813a7120
0xffffffff813a18be : pop %rbp
0xffffffff813a18bf : retq
End of assembler dump.(gdb) disassemble extract_entropy
[...]
0xffffffff814a5009 : mov %r12,%rdi
0xffffffff814a500c : mov $0xa,%esi
0xffffffff814a5011 : callq 0xffffffff813a18b0
0xffffffff814a5016 : mov -0x48(%rbp),%rax
[...]... but in case in future we might use facilities such as LTO, then
OPTIMIZER_HIDE_VAR() is not sufficient to protect gcc from a possible
eviction of the memset(). We have to use a compiler barrier instead.Minimal test example when we assume memzero_explicit() would *not* be
a call, but would have been *inlined* instead:static inline void memzero_explicit(void *s, size_t count)
{
memset(s, 0, count);
}int main(void)
{
char buff[20];snprintf(buff, sizeof(buff) - 1, "test");
printf("%s", buff);memzero_explicit(buff, sizeof(buff));
return 0;
}With := OPTIMIZER_HIDE_VAR():
(gdb) disassemble main
Dump of assembler code for function main:
[...]
0x0000000000400464 : callq 0x400410
0x0000000000400469 : xor %eax,%eax
0x000000000040046b : add $0x28,%rsp
0x000000000040046f : retq
End of assembler dump.With := barrier():
(gdb) disassemble main
Dump of assembler code for function main:
[...]
0x0000000000400464 : callq 0x400410
0x0000000000400469 : movq $0x0,(%rsp)
0x0000000000400471 : movq $0x0,0x8(%rsp)
0x000000000040047a : movl $0x0,0x10(%rsp)
0x0000000000400482 : xor %eax,%eax
0x0000000000400484 : add $0x28,%rsp
0x0000000000400488 : retq
End of assembler dump.As can be seen, movq, movq, movl are being emitted inlined
via memset().Reference: http://thread.gmane.org/gmane.linux.kernel.cryptoapi/13764/
Fixes: d4c5efdb9777 ("random: add and use memzero_explicit() for clearing data")
Cc: Theodore Ts'o
Signed-off-by: mancha security
Signed-off-by: Daniel Borkmann
Acked-by: Hannes Frederic Sowa
Acked-by: Stephan Mueller
Signed-off-by: Herbert Xu
15 Feb, 2015
1 commit
-
Pull crypto update from Herbert Xu:
"Here is the crypto update for 3.20:- Added 192/256-bit key support to aesni GCM.
- Added MIPS OCTEON MD5 support.
- Fixed hwrng starvation and race conditions.
- Added note that memzero_explicit is not a subsitute for memset.
- Added user-space interface for crypto_rng.
- Misc fixes"* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (71 commits)
crypto: tcrypt - do not allocate iv on stack for aead speed tests
crypto: testmgr - limit IV copy length in aead tests
crypto: tcrypt - fix buflen reminder calculation
crypto: testmgr - mark rfc4106(gcm(aes)) as fips_allowed
crypto: caam - fix resource clean-up on error path for caam_jr_init
crypto: caam - pair irq map and dispose in the same function
crypto: ccp - terminate ccp_support array with empty element
crypto: caam - remove unused local variable
crypto: caam - remove dead code
crypto: caam - don't emit ICV check failures to dmesg
hwrng: virtio - drop extra empty line
crypto: replace scatterwalk_sg_next with sg_next
crypto: atmel - Free memory in error path
crypto: doc - remove colons in comments
crypto: seqiv - Ensure that IV size is at least 8 bytes
crypto: cts - Weed out non-CBC algorithms
MAINTAINERS: add linux-crypto to hw random
crypto: cts - Remove bogus use of seqiv
crypto: qat - don't need qat_auth_state struct
crypto: algif_rng - fix sparse non static symbol warning
...
14 Feb, 2015
1 commit
-
Instead of potentially passing over the string twice in case c is not
found, just keep track of the last occurrence. According to
bloat-o-meter, this also cuts the generated code by a third (54 vs 36
bytes). Oh, and we get rid of those 7-space indented lines.Signed-off-by: Rasmus Villemoes
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
13 Feb, 2015
1 commit
-
Now that all in-tree users of strnicmp have been converted to
strncasecmp, the wrapper can be removed.Signed-off-by: Rasmus Villemoes
Cc: David Howells
Cc: Heiko Carstens
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
08 Jan, 2015
1 commit
-
Lets improve the comment to add a note on when to use memzero_explicit()
for those not digging through the git logs. We don't want people to
pollute places with memzero_explicit() where it's not really necessary.Reference: https://lkml.org/lkml/2015/1/4/190
Suggested-by: Herbert Xu
Signed-off-by: Daniel Borkmann
Signed-off-by: Herbert Xu
25 Oct, 2014
1 commit
-
Pull /dev/random updates from Ted Ts'o:
"This adds a memzero_explicit() call which is guaranteed not to be
optimized away by GCC. This is important when we are wiping
cryptographically sensitive material"* tag 'random_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random:
crypto: memzero_explicit - make sure to clear out sensitive data
random: add and use memzero_explicit() for clearing data
17 Oct, 2014
1 commit
-
zatimend has reported that in his environment (3.16/gcc4.8.3/corei7)
memset() calls which clear out sensitive data in extract_{buf,entropy,
entropy_user}() in random driver are being optimized away by gcc.Add a helper memzero_explicit() (similarly as explicit_bzero() variants)
that can be used in such cases where a variable with sensitive data is
being cleared out in the end. Other use cases might also be in crypto
code. [ I have put this into lib/string.c though, as it's always built-in
and doesn't need any dependencies then. ]Fixes kernel bugzilla: 82041
Reported-by: zatimend@hotmail.co.uk
Signed-off-by: Daniel Borkmann
Acked-by: Hannes Frederic Sowa
Cc: Alexey Dobriyan
Signed-off-by: Theodore Ts'o
Cc: stable@vger.kernel.org
14 Oct, 2014
2 commits
-
The previous patch made strnicmp into a wrapper for strncasecmp.
This patch makes all in-tree users of strnicmp call strncasecmp
directly, while still making sure that the strnicmp symbol can be used
by out-of-tree modules. It should be considered a temporary hack until
all in-tree callers have been converted.Signed-off-by: Rasmus Villemoes
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
lib/string.c contains two functions, strnicmp and strncasecmp, which do
roughly the same thing, namely compare two strings case-insensitively up
to a given bound. They have slightly different implementations, but the
only important difference is that strncasecmp doesn't handle len==0
appropriately; it effectively becomes strcasecmp in that case. strnicmp
correctly says that two strings are always equal in their first 0
characters.strncasecmp is the POSIX name for this functionality. So rename the
non-broken function to the standard name. To minimize the impact on the
rest of the kernel (and since both are exported to modules), make strnicmp
a wrapper for strncasecmp.Signed-off-by: Rasmus Villemoes
Cc: Grant Likely
Cc: Andi Kleen
Cc: Dan Carpenter
Cc: "H. Peter Anvin"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
14 Sep, 2014
1 commit
-
It used to be an ad-hoc hack defined by the x86 version of
that enabled a couple of library routines to know whether
an integer multiply is faster than repeated shifts and additions.This just makes it use the real Kconfig system instead, and makes x86
(which was the only architecture that did this) select the option.NOTE! Even for x86, this really is kind of wrong. If we cared, we would
probably not enable this for builds optimized for netburst (P4), where
shifts-and-adds are generally faster than multiplies. This patch does
*not* change that kind of logic, though, it is purely a syntactic change
with no code changes.This was triggered by the fact that we have other places that really
want to know "do I want to expand multiples by constants by hand or
not", particularly the hash generation code.Signed-off-by: Linus Torvalds
05 Jun, 2014
1 commit
-
For strncpy() and friends the source string may or may not have an actual
NUL character at the end. The documentation is confusing in this because
it specifically mentions that you are passing a "NUL-terminated" string.
Wikipedia says that "C-string" is an alternative name we can use instead.http://en.wikipedia.org/wiki/Null-terminated_string
Signed-off-by: Dan Carpenter
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
23 May, 2014
1 commit
-
The strchrnul() variant helpfully returns a the end of the string
instead of a NULL if the requested character is not found. This can
simplify string parsing code since it doesn't need to expicitly check
for a NULL return. If a valid string pointer is passed in, then a valid
null terminated string will always come back out.Signed-off-by: Grant Likely
14 Feb, 2014
1 commit
-
In LTO symbols implicitely referenced by the compiler need
to be visible. Earlier these symbols were visible implicitely
from being exported, but we disabled implicit visibility fo
EXPORTs when modules are disabled to improve code size. So
now these symbols have to be marked visible explicitely.Do this for __stack_chk_fail (with stack protector)
and memcmp.Signed-off-by: Andi Kleen
Link: http://lkml.kernel.org/r/1391845930-28580-10-git-send-email-ak@linux.intel.com
Signed-off-by: H. Peter Anvin
25 Mar, 2012
2 commits
-
Pull cleanup of fs/ and lib/ users of module.h from Paul Gortmaker:
"Fix up files in fs/ and lib/ dirs to only use module.h if they really
need it.These are trivial in scope vs the work done previously. We now have
things where any few remaining cleanups can be farmed out to arch or
subsystem maintainers, and I have done so when possible. What is
remaining here represents the bits that don't clearly lie within a
single arch/subsystem boundary, like the fs dir and the lib dir.Some duplicate includes arising from overlapping fixes from
independent subsystem maintainer submissions are also quashed."Fix up trivial conflicts due to clashes with other include file cleanups
(including some due to the previous bug.h cleanup pull).* tag 'module-for-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux:
lib: reduce the use of module.h wherever possible
fs: reduce the use of module.h wherever possible
includecheck: delete any duplicate instances of module.h -
Pull cleanup from Paul Gortmaker:
"The changes shown here are to unify linux's BUG support under the one
file. Due to historical reasons, we have some BUG code
in bug.h and some in kernel.h -- i.e. the support for BUILD_BUG in
linux/kernel.h predates the addition of linux/bug.h, but old code in
kernel.h wasn't moved to bug.h at that time. As a band-aid, kernel.h
was including to pseudo link them.This has caused confusion[1] and general yuck/WTF[2] reactions. Here
is an example that violates the principle of least surprise:CC lib/string.o
lib/string.c: In function 'strlcat':
lib/string.c:225:2: error: implicit declaration of function 'BUILD_BUG_ON'
make[2]: *** [lib/string.o] Error 1
$
$ grep linux/bug.h lib/string.c
#include
$We've included for the BUG infrastructure and yet we
still get a compile fail! [We've not kernel.h for BUILD_BUG_ON.] Ugh -
very confusing for someone who is new to kernel development.With the above in mind, the goals of this changeset are:
1) find and fix any include/*.h files that were relying on the
implicit presence of BUG code.
2) find and fix any C files that were consuming kernel.h and hence
relying on implicitly getting some/all BUG code.
3) Move the BUG related code living in kernel.h to
4) remove the asm/bug.h from kernel.h to finally break the chain.During development, the order was more like 3-4, build-test, 1-2. But
to ensure that git history for bisect doesn't get needless build
failures introduced, the commits have been reorderd to fix the problem
areas in advance.[1] https://lkml.org/lkml/2012/1/3/90
[2] https://lkml.org/lkml/2012/1/17/414"Fix up conflicts (new radeon file, reiserfs header cleanups) as per Paul
and linux-next.* tag 'bug-for-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux:
kernel.h: doesn't explicitly use bug.h, so don't include it.
bug: consolidate BUILD_BUG_ON with other bug code
BUG: headers with BUG/BUG_ON etc. need linux/bug.h
bug.h: add include of it to various implicit C users
lib: fix implicit users of kernel.h for TAINT_WARN
spinlock: macroize assert_spin_locked to avoid bug.h dependency
x86: relocate get/set debugreg fcns to include/asm/debugreg.