- 11 Apr, 2018 40 commits
-
-
Davidlohr Bueso authored
There is a permission discrepancy when consulting shm ipc object metadata between /proc/sysvipc/sem (0444) and the SEM_STAT semctl command. The later does permission checks for the object vs S_IRUGO. As such there can be cases where EACCESS is returned via syscall but the info is displayed anyways in the procfs files. While this might have security implications via info leaking (albeit no writing to the sma metadata), this behavior goes way back and showing all the objects regardless of the permissions was most likely an overlook - so we are stuck with it. Furthermore, modifying either the syscall or the procfs file can cause userspace programs to break (ie ipcs). Some applications require getting the procfs info (without root privileges) and can be rather slow in comparison with a syscall -- up to 500x in some reported cases for shm. This patch introduces a new SEM_STAT_ANY command such that the sem ipc object permissions are ignored, and only audited instead. In addition, I've left the lsm security hook checks in place, as if some policy can block the call, then the user has no other choice than just parsing the procfs file. Link: http://lkml.kernel.org/r/20180215162458.10059-3-dave@stgolabs.netSigned-off-by:
Davidlohr Bueso <dbueso@suse.de> Reported-by:
Robert Kettler <robert.kettler@outlook.com> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Kees Cook <keescook@chromium.org> Cc: Manfred Spraul <manfred@colorfullife.com> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Cc: Michal Hocko <mhocko@kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Davidlohr Bueso authored
Patch series "sysvipc: introduce STAT_ANY commands", v2. The following patches adds the discussed (see [1]) new command for shm as well as for sems and msq as they are subject to the same discrepancies for ipc object permission checks between the syscall and via procfs. These new commands are justified in that (1) we are stuck with this semantics as changing syscall and procfs can break userland; and (2) some users can benefit from performance (for large amounts of shm segments, for example) from not having to parse the procfs interface. Once merged, I will submit the necesary manpage updates. But I'm thinking something like: : diff --git a/man2/shmctl.2 b/man2/shmctl.2 : index 7bb503999941..bb00bbe21a57 100644 : --- a/man2/shmctl.2 : +++ b/man2/shmctl.2 : @@ -41,6 +41,7 @@ : .\" 2005-04-25, mtk -- noted aberrant Linux behavior w.r.t. new : .\" attaches to a segment that has already been marked for deletion. : .\" 2005-08-02, mtk: Added IPC_INFO, SHM_INFO, SHM_STAT descriptions. : +.\" 2018-02-13, dbueso: Added SHM_STAT_ANY description. : .\" : .TH SHMCTL 2 2017-09-15 "Linux" "Linux Programmer's Manual" : .SH NAME : @@ -242,6 +243,18 @@ However, the : argument is not a segment identifier, but instead an index into : the kernel's internal array that maintains information about : all shared memory segments on the system. : +.TP : +.BR SHM_STAT_ANY " (Linux-specific)" : +Return a : +.I shmid_ds : +structure as for : +.BR SHM_STAT . : +However, the : +.I shm_perm.mode : +is not checked for read access for : +.IR shmid , : +resembing the behaviour of : +/proc/sysvipc/shm. : .PP : The caller can prevent or allow swapping of a shared : memory segment with the following \fIcmd\fP values: : @@ -287,7 +300,7 @@ operation returns the index of the highest used entry in the : kernel's internal array recording information about all : shared memory segments. : (This information can be used with repeated : -.B SHM_STAT : +.B SHM_STAT/SHM_STAT_ANY : operations to obtain information about all shared memory segments : on the system.) : A successful : @@ -328,7 +341,7 @@ isn't accessible. : \fIshmid\fP is not a valid identifier, or \fIcmd\fP : is not a valid command. : Or: for a : -.B SHM_STAT : +.B SHM_STAT/SHM_STAT_ANY : operation, the index value specified in : .I shmid : referred to an array slot that is currently unused. This patch (of 3): There is a permission discrepancy when consulting shm ipc object metadata between /proc/sysvipc/shm (0444) and the SHM_STAT shmctl command. The later does permission checks for the object vs S_IRUGO. As such there can be cases where EACCESS is returned via syscall but the info is displayed anyways in the procfs files. While this might have security implications via info leaking (albeit no writing to the shm metadata), this behavior goes way back and showing all the objects regardless of the permissions was most likely an overlook - so we are stuck with it. Furthermore, modifying either the syscall or the procfs file can cause userspace programs to break (ie ipcs). Some applications require getting the procfs info (without root privileges) and can be rather slow in comparison with a syscall -- up to 500x in some reported cases. This patch introduces a new SHM_STAT_ANY command such that the shm ipc object permissions are ignored, and only audited instead. In addition, I've left the lsm security hook checks in place, as if some policy can block the call, then the user has no other choice than just parsing the procfs file. [1] https://lkml.org/lkml/2017/12/19/220 Link: http://lkml.kernel.org/r/20180215162458.10059-2-dave@stgolabs.netSigned-off-by:
Michal Hocko <mhocko@suse.com> Cc: Michael Kerrisk <mtk.manpages@gmail.com> Cc: Manfred Spraul <manfred@colorfullife.com> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Kees Cook <keescook@chromium.org> Cc: Robert Kettler <robert.kettler@outlook.com> Signed-off-by:
-
Chris Wilson authored
As using an unsafe module parameter is, by its very definition, an expected user action, emitting a warning is overkill. Nothing has yet gone wrong, and we add a taint flag for any future oops should something actually go wrong. So instead of having a user controllable pr_warn, downgrade it to a pr_notice for "a normal, but significant condition". We make use of unsafe kernel parameters in igt (https://cgit.freedesktop.org/drm/igt-gpu-tools/) (we have not yet succeeded in removing all such debugging options), which generates a warning and taints the kernel. The warning is unhelpful as we then need to filter it out again as we check that every test themselves do not provoke any kernel warnings. Link: http://lkml.kernel.org/r/20180226151919.9674-1-chris@chris-wilson.co.uk Fixes: 91f9d330 ("module: make it possible to have unsafe, tainting module params") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Randy Dunlap authored
Fix sizeof argument to be the same as the data variable name. Probably a copy/paste error. Mostly harmless since both variables are unsigned int. Fixes kernel bugzilla #197371: Possible access to unintended variable in "kernel/sysctl.c" line 1339 https://bugzilla.kernel.org/show_bug.cgi?id=197371 Link: http://lkml.kernel.org/r/e0d0531f-361e-ef5f-8499-32743ba907e1@infradead.orgSigned-off-by:
Randy Dunlap <rdunlap@infradead.org> Reported-by:
Petru Mihancea <petrum@gmail.com> Signed-off-by:
-
Ioan Nicu authored
Once the dma request is passed to the DMA engine, the DMA subsystem would hold a pointer to this structure and could call the completion callback after do_dma_request() has timed out. The current code deals with this by putting timed out SYNC requests to a pending list and freeing them later, when the mport cdev device is released. This still does not guarantee that the DMA subsystem is really done with those transfers, so in theory dma_xfer_callback/dma_req_free could be called after mport_cdev_release_dma and could potentially access already freed memory. This patch simplifies the current handling by using a kref in the mport dma request structure, so that it gets freed only when nobody uses it anymore. This also simplifies the code a bit, as FAF transfers are now handled in the same way as SYNC and ASYNC transfers. There is no need anymore for the pending list and for the dma workqueue which was used in case of FAF transfers, so we remove them both. Link: http://lkml.kernel.org/r/20180405203342.GA16191@nokia.comSigned-off-by:
Ioan Nicu <ioan.nicu.ext@nokia.com> Acked-by:
Alexandre Bounine <alex.bou9@gmail.com> Cc: Barry Wood <barry.wood@idt.com> Cc: Matt Porter <mporter@kernel.crashing.org> Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Logan Gunthorpe <logang@deltatee.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Frank Kunz <frank.kunz@nokia.com> Cc: Alexander Sverdlin <alexander.sverdlin@nokia.com> Signed-off-by:
-
Vasyl Gomonovych authored
Fix typo in the words 'receiver', 'specified', 'during' Link: http://lkml.kernel.org/r/20180321211035.8904-1-gomonovych@gmail.comSigned-off-by:
Vasyl Gomonovych <gomonovych@gmail.com> Cc: Matt Porter <mporter@kernel.crashing.org> Cc: Alexandre Bounine <alexandre.bounine@idt.com> Signed-off-by:
-
Kees Cook authored
Since the stack rlimit is used in multiple places during exec and it can be changed via other threads (via setrlimit()) or processes (via prlimit()), the assumption that the value doesn't change cannot be made. This leads to races with mm layout selection and argument size calculations. This changes the exec path to use the rlimit stored in bprm instead of in current. Before starting the thread, the bprm stack rlimit is stored back to current. Link: http://lkml.kernel.org/r/1518638796-20819-4-git-send-email-keescook@chromium.org Fixes: 64701dee ("exec: Use sane stack rlimit under secureexec") Signed-off-by:
Kees Cook <keescook@chromium.org> Reported-by:
Ben Hutchings <ben.hutchings@codethink.co.uk> Reported-by:
Andy Lutomirski <luto@kernel.org> Reported-by:
Brad Spengler <spender@grsecurity.net> Acked-by:
-
Kees Cook authored
Provide a final callback into fs/exec.c before start_thread() takes over, to handle any last-minute changes, like the coming restoration of the stack limit. Link: http://lkml.kernel.org/r/1518638796-20819-3-git-send-email-keescook@chromium.orgSigned-off-by:
-
Kees Cook authored
Patch series "exec: Pin stack limit during exec". Attempts to solve problems with the stack limit changing during exec continue to be frustrated[1][2]. In addition to the specific issues around the Stack Clash family of flaws, Andy Lutomirski pointed out[3] other places during exec where the stack limit is used and is assumed to be unchanging. Given the many places it gets used and the fact that it can be manipulated/raced via setrlimit() and prlimit(), I think the only way to handle this is to move away from the "current" view of the stack limit and instead attach it to the bprm, and plumb this down into the functions that need to know the stack limits. This series implements the approach. [1] 04e35f44 ("exec: avoid RLIMIT_STACK races with prlimit()") [2] 779f4e1c ("Revert "exec: avoid RLIMIT_STACK races with prlimit()"") [3] to security@kernel.org, "Subject: existing rlimit races?" This patch (of 3): Since it is possible that the stack rlimit can change externally during exec (either via another thread calling setrlimit() or another process calling prlimit()), provide a way to pass the rlimit down into the per-architecture mm layout functions so that the rlimit can stay in the bprm structure instead of sitting in the signal structure until exec is finalized. Link: http://lkml.kernel.org/r/1518638796-20819-2-git-send-email-keescook@chromium.orgSigned-off-by:
-
Alexey Dobriyan authored
All it takes to open a file and read 1 byte from it. seq_file will be allocated along with any private allocations, and more importantly seq file buffer which is 1 page by default. Link: http://lkml.kernel.org/r/20180310085252.GB17121@avx2Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Reviewed-by:
-
Alexey Dobriyan authored
For fine-grained debugging and usercopy protection. Link: http://lkml.kernel.org/r/20180310085027.GA17121@avx2Signed-off-by:
-
Andrew Morton authored
One use of the reiserfs_warning() macro in journal_init_dev() is missing a parameter, causing the following warning: REISERFS warning (device loop0): journal_init_dev: Cannot open '%s': %i journal_init_dev: This also causes a WARN_ONCE() warning in the vsprintf code, and then a panic if panic_on_warn is set. Please remove unsupported %/ in format string WARNING: CPU: 1 PID: 4480 at lib/vsprintf.c:2138 format_decode+0x77f/0x830 lib/vsprintf.c:2138 Kernel panic - not syncing: panic_on_warn set ... Just add another string argument to the macro invocation. Addresses https://syzkaller.appspot.com/bug?id=0627d4551fdc39bf1ef5d82cd9eef587047f7718 Link: http://lkml.kernel.org/r/d678ebe1-6f54-8090-df4c-b9affad62293@infradead.orgSigned-off-by:
Jeff Mahoney <jeffm@suse.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Jan Kara <jack@suse.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Matthew Wilcox authored
This playing with signals to allow only fatal signals appears to predate the introduction of wait_event_killable(), and I'm fairly sure that wait_event_killable is what was meant to happen here. [avagin@openvz.org: use wake_up() instead of wake_up_interruptible] Link: http://lkml.kernel.org/r/20180331022839.21277-1-avagin@openvz.org Link: http://lkml.kernel.org/r/20180319191609.23880-1-willy@infradead.orgSigned-off-by:
Matthew Wilcox <mawilcox@microsoft.com> Acked-by:
Ian Kent <raven@themaw.net> Cc: Matthew Wilcox <mawilcox@microsoft.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Aaro Koskinen authored
Use pr_cont() at the end of ramdisk loading. This will avoid the rotator and an extra newline appearing in the dmesg. Before: RAMDISK: Loading 2436KiB [1 disk] into ram disk... | done. After: RAMDISK: Loading 2436KiB [1 disk] into ram disk... done. Link: http://lkml.kernel.org/r/20180302205552.16031-1-aaro.koskinen@iki.fiSigned-off-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Reviewed-by:
-
Joe Perches authored
Using bool in a bitfield isn't a good idea as the alignment behavior is arch implementation defined. Suggest using unsigned int or u<8|16|32> instead. Link: http://lkml.kernel.org/r/e22fb871b1b7f2fda4b22f3a24e0d7f092eb612c.camel@perches.comSigned-off-by:
Joe Perches <joe@perches.com> Suggested-by:
Peter Zijlstra <peterz@infradead.org> Signed-off-by:
-
Heinrich Schuchardt authored
Allow a space between a colon and subsequent opening bracket. This sequence may occur in inline assembler statements like asm( "ldr %[out], [%[in]]\n\t" : [out] "=r" (ret) : [in] "r" (addr) ); Link: http://lkml.kernel.org/r/20180403191655.23700-1-xypron.glpk@gmx.deSigned-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de> Acked-by:
-
Joe Perches authored
Kernel style seems to prefer line wrapping an assignment with the assignment operator on the previous line like: <leading tabs> identifier = expression; over <leading tabs> identifier = expression; somewhere around a 50:1 ratio $ git grep -P "[^=]=\s*$" -- "*.[ch]" | wc -l 52008 $ git grep -P "^\s+[\*\/\+\|\%\-]?=[^=>]" | wc -l 1161 So add a --strict test for that condition. Link: http://lkml.kernel.org/r/1522275726.2210.12.camel@perches.comSigned-off-by:
-
Joe Perches authored
There are occasions where symbolic perms are used in a ternary like return (channel == 0) ? S_IRUGO | S_IWUSR : S_IRUGO; The current test will find the first use "S_IRUGO | S_IWUSR" but not the second use "S_IRUGO" on the same line. Improve the test to look for all instances on a line. Link: http://lkml.kernel.org/r/1522127944.12357.49.camel@perches.comSigned-off-by:
-
Claudio Fontana authored
completly -> completely wacking -> whacking Link: http://lkml.kernel.org/r/1520405394-5586-1-git-send-email-claudio.fontana@gliwa.comSigned-off-by:
Claudio Fontana <claudio.fontana@gliwa.com> Acked-by:
-
Joe Perches authored
The get_quoted_string function does not expect invalid arguments. The $stat test can return non-statements for complicated macros like TRACE_EVENT. Allow the $stat block and test for vsprintf misuses to exceed the actual block length and possibly test invalid lines by validating the arguments of get_quoted_string. Return "" if either get_quoted_string argument is undefined. Miscellanea: o Properly align the comment for the vsprintf extension test Link: http://lkml.kernel.org/r/9e9725342ca3dfc0f5e3e0b8ca3c482b0e5712cc.1520356392.git.joe@perches.comSigned-off-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
-
Tobin C. Harding authored
Usage of the new %px specifier potentially leaks sensitive information. Printing kernel addresses exposes the kernel layout in memory, this is potentially exploitable. We have tools in the kernel to help us do the right thing. We can have checkpatch warn developers of potential dangers of using %px. Have checkpatch emit a warning for usage of specifier %px. Link: http://lkml.kernel.org/r/1519700648-23108-5-git-send-email-me@tobin.ccSigned-off-by:
Tobin C. Harding <me@tobin.cc> Signed-off-by:
-
Tobin C. Harding authored
checkpatch currently contains duplicate code. We can define a sub routine and call that instead. This reduces code duplication and line count. Add subroutine get_stat_here(). Link: http://lkml.kernel.org/r/1519700648-23108-4-git-send-email-me@tobin.ccSigned-off-by:
-
Tobin C. Harding authored
Variables are declared and not used, we should remove them. Link: http://lkml.kernel.org/r/1519700648-23108-3-git-send-email-me@tobin.ccSigned-off-by:
-
Tobin C. Harding authored
checkpatch currently contains duplicate code. We can define a sub routine and call that instead. This reduces code duplication and line count. Add subroutine get_stat_real() Link: http://lkml.kernel.org/r/1519700648-23108-2-git-send-email-me@tobin.ccSigned-off-by:
-
Gilad Ben-Yossef authored
Add the crypto API *_ON_STACK to $declaration_macros. Resolves the following false warning: WARNING: Missing a blank line after declarations + int err; + SHASH_DESC_ON_STACK(desc, ctx_p->shash_tfm); Link: http://lkml.kernel.org/r/1518941636-4484-1-git-send-email-gilad@benyossef.comSigned-off-by:
Gilad Ben-Yossef <gilad@benyossef.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Rob Herring authored
Add SPDX license tag check based on the rules defined in Documentation/process/license-rules.rst. To summarize, SPDX license tags should be on the 1st line (or 2nd line in scripts) using the appropriate comment style for the file type. Link: http://lkml.kernel.org/r/20180202154026.15298-1-robh@kernel.orgSigned-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Philippe Ombredanne <pombredanne@nexb.com> Cc: Andy Whitcroft <apw@canonical.com> Cc: Joe Perches <joe@perches.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Igor Stoppa <igor.stoppa@huawei.com> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by:
-
Joe Perches authored
Bare email addresses with non alphanumeric characters require escape quoting before being substituted in the parse_email routine. e.g. Reported-by: syzbot+bbd8e9a06452cc48059b@syzkaller.appspotmail.com Do so. Link: http://lkml.kernel.org/r/1518631805.3678.12.camel@perches.comSigned-off-by:
-
Matthew Wilcox authored
The entire point of printing the pointers in list_debug is to see if there's any useful information in them (eg poison values, ASCII, etc); obscuring them to see if they compare equal makes them much less useful. If an attacker can force this message to be printed, we've already lost. Link: http://lkml.kernel.org/r/20180401223237.GV13332@bombadil.infradead.orgSigned-off-by:
-
Colin Ian King authored
test_ubsan_misaligned_access() is local to the source and does not need to be in global scope, so make it static. Cleans up sparse warning: lib/test_ubsan.c:91:6: warning: symbol 'test_ubsan_misaligned_access' was not declared. Should it be static? Link: http://lkml.kernel.org/r/20180313103048.28513-1-colin.king@canonical.comSigned-off-by:
Colin Ian King <colin.king@canonical.com> Cc: Jinbum Park <jinb.park7@gmail.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Kees Cook <keescook@chromium.org> Signed-off-by:
-
Jinbum Park authored
This is a test module for UBSAN. It triggers all undefined behaviors that linux supports now, and detect them. All test-cases have passed by compiling with gcc-5.5.0. If use gcc-4.9.x, misaligned, out-of-bounds, object-size-mismatch will not be detected. Because gcc-4.9.x doesn't support them. Link: http://lkml.kernel.org/r/20180309102247.GA2944@pjb1027-Latitude-E5410Signed-off-by:
Jinbum Park <jinb.park7@gmail.com> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Kees Cook <keescook@chromium.org> Signed-off-by:
-
Kees Cook authored
This avoids an accidental stack VLA (since the compiler thinks the value of "len" can change, even when marked "const"). This just replaces it with a #define so it will DTRT. Seen with -Wvla. Fixed as part of the directive to remove all VLAs from the kernel: https://lkml.org/lkml/2018/3/7/621 Link: http://lkml.kernel.org/r/20180307212555.GA17927@beastSigned-off-by:
-
Randy Dunlap authored
Keep all of the SOFTLOCKUP kconfig symbols together (instead of injecting the HARDLOCKUP symbols in the midst of them) so that the config tools display them with their dependencies. Tested with 'make {menuconfig/nconfig/gconfig/xconfig}'. Link: http://lkml.kernel.org/r/6be2d9ed-4656-5b94-460d-7f051e2c7570@infradead.org Fixes: 05a4a952 ("kernel/watchdog: split up config options") Signed-off-by: -
Alexandre Bounine authored
Link: http://lkml.kernel.org/r/1522958149-6157-1-git-send-email-alex.bou9@gmail.comSigned-off-by:
-
Kees Cook authored
The original intent for always adding the anonymous struct in task_struct was to make sure we had compiler coverage. However, this caused pathological padding of 40 bytes at the start of task_struct. Instead, move the anonymous struct to being only used when struct layout randomization is enabled. Link: http://lkml.kernel.org/r/20180327213609.GA2964@beast Fixes: 29e48ce8 ("task_struct: Allow randomized") Signed-off-by:
-
Miguel Ojeda authored
clang-format is a tool to format C/C++/... code according to a set of rules and heuristics. Like most tools, it is not perfect nor covers every single case, but it is good enough to be helpful. In particular, it is useful for quickly re-formatting blocks of code automatically, for reviewing full files in order to spot coding style mistakes, typos and possible improvements. It is also handy for sorting ``#includes``, for aligning variables and macros, for reflowing text and other similar tasks. It also serves as a teaching tool/guide for newcomers. The tool itself has been already included in the repositories of popular Linux distributions for a long time. The rules in this file are intended for clang-format >= 4, which is easily available in most distributions. This commit adds the configuration file that contains the rules that the tool uses to know how to format the code according to the kernel coding style. This gives us several advantages: * clang-format works out of the box with reasonable defaults; avoiding that everyone has to re-do the configuration. * Everyone agrees (eventually) on what is the most useful default configuration for most of the kernel. * If it becomes commonplace among kernel developers, clang-format may feel compelled to support us better. They already recognize the Linux kernel and its style in their documentation and in one of the style sub-options. Some of clang-format's features relevant for the kernel are: * Uses clang's tooling support behind the scenes to parse and rewrite the code. It is not based on ad-hoc regexps. * Supports reasonably well the Linux kernel coding style. * Fast enough to be used at the press of a key. * There are already integrations (either built-in or third-party) for many common editors used by kernel developers (e.g. vim, emacs, Sublime, Atom...) that allow you to format an entire file or, more usefully, just your selection. * Able to parse unified diffs -- you can, for instance, reformat only the lines changed by a git commit. * Able to reflow text comments as well. * Widely supported and used by hundreds of developers in highly complex projects and organizations (e.g. the LLVM project itself, Chromium, WebKit, Google, Mozilla...). Therefore, it will be supported for a long time. See more information about the tool at: https://clang.llvm.org/docs/ClangFormat.html https://clang.llvm.org/docs/ClangFormatStyleOptions.html Link: http://lkml.kernel.org/r/20180318171632.qfkemw3mwbcukth6@gmail.comSigned-off-by:Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Andy Whitcroft <apw@canonical.com> Cc: Joe Perches <joe@perches.com> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by:
-
Alexey Dobriyan authored
So "struct uts_namespace" can enjoy fine-grained SLAB debugging and usercopy protection. I'd prefer shorter name "utsns" but there is "user_namespace" already. Link: http://lkml.kernel.org/r/20180228215158.GA23146@avx2Signed-off-by:
-
Kees Cook authored
Since the randstruct plugin can intentionally produce extremely unusual kernel structure layouts (even performance pathological ones), some maintainers want to be able to trivially determine if an Oops is coming from a randstruct-built kernel, so as to keep their sanity when debugging. This adds the new flag and initializes taint_mask immediately when built with randstruct. Link: http://lkml.kernel.org/r/1519084390-43867-4-git-send-email-keescook@chromium.orgSigned-off-by:
-
Kees Cook authored
This consolidates the taint bit documentation into a single place with both numeric and letter values. Additionally adds the missing TAINT_AUX documentation. Link: http://lkml.kernel.org/r/1519084390-43867-3-git-send-email-keescook@chromium.orgSigned-off-by:
-
Kees Cook authored
This converts to using indexed initializers instead of comments, adds a comment on why the taint flags can't be an enum, and make sure that no one forgets to update the taint_flags when adding new bits. Link: http://lkml.kernel.org/r/1519084390-43867-2-git-send-email-keescook@chromium.orgSigned-off-by:
-
Alexey Dobriyan authored
The only tests I could come up with for /proc/uptime are: - test that values increase monotonically for 1 second, - bounce around CPUs and test the same thing. Avoid glibc like plague for affinity given patches like this: https://marc.info/?l=linux-kernel&m=152130031912594&w=4 Link: http://lkml.kernel.org/r/20180317165235.GB3445@avx2Signed-off-by:
-
