25 Mar, 2018

1 commit


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

    Greg Kroah-Hartman
     

15 Sep, 2017

1 commit

  • Pull ipc compat cleanup and 64-bit time_t from Al Viro:
    "IPC copyin/copyout sanitizing, including 64bit time_t work from Deepa
    Dinamani"

    * 'work.ipc' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
    utimes: Make utimes y2038 safe
    ipc: shm: Make shmid_kernel timestamps y2038 safe
    ipc: sem: Make sem_array timestamps y2038 safe
    ipc: msg: Make msg_queue timestamps y2038 safe
    ipc: mqueue: Replace timespec with timespec64
    ipc: Make sys_semtimedop() y2038 safe
    get rid of SYSVIPC_COMPAT on ia64
    semtimedop(): move compat to native
    shmat(2): move compat to native
    msgrcv(2), msgsnd(2): move compat to native
    ipc(2): move compat to native
    ipc: make use of compat ipc_perm helpers
    semctl(): move compat to native
    semctl(): separate all layout-dependent copyin/copyout
    msgctl(): move compat to native
    msgctl(): split the actual work from copyin/copyout
    ipc: move compat shmctl to native
    shmctl: split the work from copyin/copyout

    Linus Torvalds
     

04 Sep, 2017

1 commit

  • time_t is not y2038 safe. Replace all uses of
    time_t by y2038 safe time64_t.

    Similarly, replace the calls to get_seconds() with
    y2038 safe ktime_get_real_seconds().
    Note that this preserves fast access on 64 bit systems,
    but 32 bit systems need sequence counters.

    The syscall interfaces themselves are not changed as part of
    the patch. They will be part of a different series.

    Signed-off-by: Deepa Dinamani
    Reviewed-by: Arnd Bergmann
    Signed-off-by: Al Viro

    Deepa Dinamani
     

16 Jul, 2017

1 commit


01 Jul, 2017

1 commit

  • This marks many critical kernel structures for randomization. These are
    structures that have been targeted in the past in security exploits, or
    contain functions pointers, pointers to function pointer tables, lists,
    workqueues, ref-counters, credentials, permissions, or are otherwise
    sensitive. This initial list was extracted from Brad Spengler/PaX Team's
    code in the last public patch of grsecurity/PaX based on my understanding
    of the code. Changes or omissions from the original code are mine and
    don't reflect the original grsecurity/PaX code.

    Left out of this list is task_struct, which requires special handling
    and will be covered in a subsequent patch.

    Signed-off-by: Kees Cook

    Kees Cook
     

28 Jan, 2014

1 commit

  • The ipc code does not adhere the typical linux coding style.
    This patch fixes lots of simple whitespace errors.

    - mostly autogenerated by
    scripts/checkpatch.pl -f --fix \
    --types=pointer_location,spacing,space_before_tab
    - one manual fixup (keep structure members tab-aligned)
    - removal of additional space_before_tab that were not found by --fix

    Tested with some of my msg and sem test apps.

    Andrew: Could you include it in -mm and move it towards Linus' tree?

    Signed-off-by: Manfred Spraul
    Suggested-by: Li Bin
    Cc: Joe Perches
    Acked-by: Rafael Aquini
    Cc: Davidlohr Bueso
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Manfred Spraul
     

13 Nov, 2013

1 commit

  • On 64 bit systems the test for negative message sizes is bogus as the
    size, which may be positive when evaluated as a long, will get truncated
    to an int when passed to load_msg(). So a long might very well contain a
    positive value but when truncated to an int it would become negative.

    That in combination with a small negative value of msg_ctlmax (which will
    be promoted to an unsigned type for the comparison against msgsz, making
    it a big positive value and therefore make it pass the check) will lead to
    two problems: 1/ The kmalloc() call in alloc_msg() will allocate a too
    small buffer as the addition of alen is effectively a subtraction. 2/ The
    copy_from_user() call in load_msg() will first overflow the buffer with
    userland data and then, when the userland access generates an access
    violation, the fixup handler copy_user_handle_tail() will try to fill the
    remainder with zeros -- roughly 4GB. That almost instantly results in a
    system crash or reset.

    ,-[ Reproducer (needs to be run as root) ]--
    | #include
    | #include
    | #include
    | #include
    |
    | int main(void) {
    | long msg = 1;
    | int fd;
    |
    | fd = open("/proc/sys/kernel/msgmax", O_WRONLY);
    | write(fd, "-1", 2);
    | close(fd);
    |
    | msgsnd(0, &msg, 0xfffffff0, IPC_NOWAIT);
    |
    | return 0;
    | }
    '---

    Fix the issue by preventing msgsz from getting truncated by consistently
    using size_t for the message length. This way the size checks in
    do_msgsnd() could still be passed with a negative value for msg_ctlmax but
    we would fail on the buffer allocation in that case and error out.

    Also change the type of m_ts from int to size_t to avoid similar nastiness
    in other code paths -- it is used in similar constructs, i.e. signed vs.
    unsigned checks. It should never become negative under normal
    circumstances, though.

    Setting msg_ctlmax to a negative value is an odd configuration and should
    be prevented. As that might break existing userland, it will be handled
    in a separate commit so it could easily be reverted and reworked without
    reintroducing the above described bug.

    Hardening mechanisms for user copy operations would have catched that bug
    early -- e.g. checking slab object sizes on user copy operations as the
    usercopy feature of the PaX patch does. Or, for that matter, detect the
    long vs. int sign change due to truncation, as the size overflow plugin
    of the very same patch does.

    [akpm@linux-foundation.org: fix i386 min() warnings]
    Signed-off-by: Mathias Krause
    Cc: Pax Team
    Cc: Davidlohr Bueso
    Cc: Brad Spengler
    Cc: Manfred Spraul
    Cc: [ v2.3.27+ -- yes, that old ;) ]
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mathias Krause
     

05 Jan, 2013

2 commits

  • This test can be used to check wheither kernel supports IPC message queue
    copy and restore features (required by CRIU project).

    Signed-off-by: Stanislav Kinsbursky
    Cc: Serge Hallyn
    Cc: "Eric W. Biederman"
    Cc: Pavel Emelyanov
    Cc: Al Viro
    Cc: KOSAKI Motohiro
    Cc: Michael Kerrisk
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Stanislav Kinsbursky
     
  • Move all message related manipulation into one function msg_fill().
    Actually, two functions because of the compat one.

    [akpm@linux-foundation.org: checkpatch fixes]
    Signed-off-by: Stanislav Kinsbursky
    Cc: Serge Hallyn
    Cc: "Eric W. Biederman"
    Cc: Pavel Emelyanov
    Cc: Al Viro
    Cc: KOSAKI Motohiro
    Cc: Michael Kerrisk
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Stanislav Kinsbursky
     

13 Oct, 2012

1 commit


07 Jun, 2008

1 commit

  • When posting:

    [PATCH 1/8] Scaling msgmni to the amount of lowmem

    (see http://article.gmane.org/gmane.linux.kernel/637849/) I changed the
    MSGPOOL value to make it fit what is said in the man pages (i.e. a size
    in bytes).

    But Michael Kerrisk rightly complained that this change could affect the
    ABI. So I'm posting this patch to make MSGPOOL expressed back in Kbytes.
    Michael, on his side, has fixed the man page.

    Signed-off-by: Nadia Derbey
    Cc: Pierre Peiffer
    Cc: Manfred Spraul
    Acked-by: Michael Kerrisk
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Nadia Derbey
     

29 Apr, 2008

1 commit

  • On large systems we'd like to allow a larger number of message queues. In
    some cases up to 32K. However simply setting MSGMNI to a larger value may
    cause problems for smaller systems.

    The first patch of this series introduces a default maximum number of message
    queue ids that scales with the amount of lowmem.

    Since msgmni is per namespace and there is no amount of memory dedicated to
    each namespace so far, the second patch of this series scales msgmni to the
    number of ipc namespaces too.

    Since msgmni depends on the amount of memory, it becomes necessary to
    recompute it upon memory add/remove. In the 4th patch, memory hotplug
    management is added: a notifier block is registered into the memory hotplug
    notifier chain for the ipc subsystem. Since the ipc namespaces are not linked
    together, they have their own notification chain: one notifier_block is
    defined per ipc namespace. Each time an ipc namespace is created (removed) it
    registers (unregisters) its notifier block in (from) the ipcns chain. The
    callback routine registered in the memory chain invokes the ipcns notifier
    chain with the IPCNS_MEMCHANGE event. Each callback routine registered in the
    ipcns namespace, in turn, recomputes msgmni for the owning namespace.

    The 5th patch makes it possible to keep the memory hotplug notifier chain's
    lock for a lesser amount of time: instead of directly notifying the ipcns
    notifier chain upon memory add/remove, a work item is added to the global
    workqueue. When activated, this work item is the one who notifies the ipcns
    notifier chain.

    Since msgmni depends on the number of ipc namespaces, it becomes necessary to
    recompute it upon ipc namespace creation / removal. The 6th patch uses the
    ipc namespace notifier chain for that purpose: that chain is notified each
    time an ipc namespace is created or removed. This makes it possible to
    recompute msgmni for all the namespaces each time one of them is created or
    removed.

    When msgmni is explicitely set from userspace, we should avoid recomputing it
    upon memory add/remove or ipcns creation/removal. This is what the 7th patch
    does: it simply unregisters the ipcns callback routine as soon as msgmni has
    been changed from procfs or sysctl().

    Even if msgmni is set by hand, it should be possible to make it back
    automatically recomputed upon memory add/remove or ipcns creation/removal.
    This what is achieved in patch 8: if set to a negative value, msgmni is added
    back to the ipcns notifier chain, making it automatically recomputed again.

    This patch:

    Compute msg_ctlmni to make it scale with the amount of lowmem. msg_ctlmni is
    now set to make the message queues occupy 1/32 of the available lowmem.

    Some cleaning has also been done for the MSGPOOL constant: the msgctl man page
    says it's not used, but it also defines it as a size in bytes (the code
    expresses it in Kbytes).

    Signed-off-by: Nadia Derbey
    Cc: Yasunori Goto
    Cc: Matt Helsley
    Cc: Mingming Cao
    Cc: Pierre Peiffer
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Nadia Derbey
     

20 Oct, 2007

1 commit

  • This patch introduces ipcs storage into IDRs. The main changes are:
    . This ipc_ids structure is changed: the entries array is changed into a
    root idr structure.
    . The grow_ary() routine is removed: it is not needed anymore when adding
    an ipc structure, since we are now using the IDR facility.
    . The ipc_rmid() routine interface is changed:
    . there is no need for this routine to return the pointer passed in as
    argument: it is now declared as a void
    . since the id is now part of the kern_ipc_perm structure, no need to
    have it as an argument to the routine

    Signed-off-by: Nadia Derbey
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Nadia Derbey
     

08 Dec, 2006

1 commit

  • Currently we allocate 64k space on the user stack and use it the msgbuf for
    sys_{msgrcv,msgsnd} for compat and the results are later copied in user [
    by copy_in_user]. This patch introduces helper routines for
    sys_{msgrcv,msgsnd} as below:

    do_msgsnd() : Accepts the mtype and user space ptr to the buffer along with
    the msqid and msgflg.

    do_msgrcv() : Accepts a kernel space ptr to mtype and a userspace ptr to
    the buffer. The mtype has to be copied back the user space msgbuf by the
    caller.

    These changes avoid the need to allocate the msgsize on the userspace (
    thus removing the size limt ) and the overhead of an extra copy_in_user().

    Signed-off-by: Suzuki K P
    Cc: Arnd Bergmann
    Cc: "David S. Miller"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    suzuki
     

25 Apr, 2006

1 commit


08 Sep, 2005

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds