08 Apr, 2020

1 commit

  • Currently it is possible to specify a state machine table with 0 length,
    this is not valid as optional tables are specified by not defining
    the table as present. Further this allows by-passing the base tables
    range check against the next/check tables.

    Fixes: d901d6a298dc ("apparmor: dfa split verification of table headers")
    Reported-by: Mike Salvatore
    Signed-off-by: John Johansen

    John Johansen
     

21 Jan, 2020

1 commit

  • There are cases where the a special out of band transition that can
    not be triggered by input is useful in separating match conditions
    in the dfa encoding.

    The null_transition is currently used as an out of band transition
    for match conditions that can not contain a \0 in their input
    but apparmor needs an out of band transition for cases where
    the match condition is allowed to contain any input character.

    Achieve this by allowing for an explicit transition out of input
    range that can only be triggered by code.

    Signed-off-by: John Johansen

    John Johansen
     

19 Jan, 2020

2 commits


04 Dec, 2019

1 commit

  • …git/jj/linux-apparmor

    Pull apparmor updates from John Johansen:
    "Features:

    - increase left match history buffer size to provide improved
    conflict resolution in overlapping execution rules.

    - switch buffer allocation to use a memory pool and GFP_KERNEL where
    possible.

    - add compression of policy blobs to reduce memory usage.

    Cleanups:

    - fix spelling mistake "immutible" -> "immutable"

    Bug fixes:

    - fix unsigned len comparison in update_for_len macro

    - fix sparse warning for type-casting of current->real_cred"

    * tag 'apparmor-pr-2019-12-03' of git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor:
    apparmor: make it so work buffers can be allocated from atomic context
    apparmor: reduce rcu_read_lock scope for aa_file_perm mediation
    apparmor: fix wrong buffer allocation in aa_new_mount
    apparmor: fix unsigned len comparison with less than zero
    apparmor: increase left match history buffer size
    apparmor: Switch to GFP_KERNEL where possible
    apparmor: Use a memory pool instead per-CPU caches
    apparmor: Force type-casting of current->real_cred
    apparmor: fix spelling mistake "immutible" -> "immutable"
    apparmor: fix blob compression when ns is forced on a policy load
    apparmor: fix missing ZLIB defines
    apparmor: fix blob compression build failure on ppc
    apparmor: Initial implementation of raw policy blob compression

    Linus Torvalds
     

21 Jun, 2019

1 commit


05 Jun, 2019

1 commit

  • Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation version 2 of the license

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-only

    has been chosen to replace the boilerplate/reference in 315 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Allison Randal
    Reviewed-by: Armijn Hemel
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190531190115.503150771@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

03 May, 2018

1 commit


24 Mar, 2018

1 commit


10 Feb, 2018

6 commits


19 May, 2017

1 commit


09 May, 2017

1 commit

  • Patch series "kvmalloc", v5.

    There are many open coded kmalloc with vmalloc fallback instances in the
    tree. Most of them are not careful enough or simply do not care about
    the underlying semantic of the kmalloc/page allocator which means that
    a) some vmalloc fallbacks are basically unreachable because the kmalloc
    part will keep retrying until it succeeds b) the page allocator can
    invoke a really disruptive steps like the OOM killer to move forward
    which doesn't sound appropriate when we consider that the vmalloc
    fallback is available.

    As it can be seen implementing kvmalloc requires quite an intimate
    knowledge if the page allocator and the memory reclaim internals which
    strongly suggests that a helper should be implemented in the memory
    subsystem proper.

    Most callers, I could find, have been converted to use the helper
    instead. This is patch 6. There are some more relying on __GFP_REPEAT
    in the networking stack which I have converted as well and Eric Dumazet
    was not opposed [2] to convert them as well.

    [1] http://lkml.kernel.org/r/20170130094940.13546-1-mhocko@kernel.org
    [2] http://lkml.kernel.org/r/1485273626.16328.301.camel@edumazet-glaptop3.roam.corp.google.com

    This patch (of 9):

    Using kmalloc with the vmalloc fallback for larger allocations is a
    common pattern in the kernel code. Yet we do not have any common helper
    for that and so users have invented their own helpers. Some of them are
    really creative when doing so. Let's just add kv[mz]alloc and make sure
    it is implemented properly. This implementation makes sure to not make
    a large memory pressure for > PAGE_SZE requests (__GFP_NORETRY) and also
    to not warn about allocation failures. This also rules out the OOM
    killer as the vmalloc is a more approapriate fallback than a disruptive
    user visible action.

    This patch also changes some existing users and removes helpers which
    are specific for them. In some cases this is not possible (e.g.
    ext4_kvmalloc, libcfs_kvzalloc) because those seems to be broken and
    require GFP_NO{FS,IO} context which is not vmalloc compatible in general
    (note that the page table allocation is GFP_KERNEL). Those need to be
    fixed separately.

    While we are at it, document that __vmalloc{_node} about unsupported gfp
    mask because there seems to be a lot of confusion out there.
    kvmalloc_node will warn about GFP_KERNEL incompatible (which are not
    superset) flags to catch new abusers. Existing ones would have to die
    slowly.

    [sfr@canb.auug.org.au: f2fs fixup]
    Link: http://lkml.kernel.org/r/20170320163735.332e64b7@canb.auug.org.au
    Link: http://lkml.kernel.org/r/20170306103032.2540-2-mhocko@kernel.org
    Signed-off-by: Michal Hocko
    Signed-off-by: Stephen Rothwell
    Reviewed-by: Andreas Dilger [ext4 part]
    Acked-by: Vlastimil Babka
    Cc: John Hubbard
    Cc: David Miller
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michal Hocko
     

16 Jan, 2017

3 commits


12 Jul, 2016

3 commits


28 Apr, 2013

3 commits


14 Mar, 2012

1 commit


20 May, 2011

1 commit


31 Mar, 2011

1 commit


02 Aug, 2010

1 commit

  • A basic dfa matching engine based off the dfa engine in the Dragon
    Book. It uses simple row comb compression with a check field.

    This allows AppArmor to do pattern matching in linear time, and also
    avoids stack issues that an nfa based engine may have. The dfa
    engine uses a byte based comparison, with all values being valid.
    Any potential character encoding are handled user side when the dfa
    tables are created. By convention AppArmor uses \0 to separate two
    dependent path matches since \0 is not a valid path character
    (this is done in the link permission check).

    The dfa tables are generated in user space and are verified at load
    time to be internally consistent.

    There are several future improvements planned for the dfa engine:
    * The dfa engine may be converted to a hybrid nfa-dfa engine, with
    a fixed size limited stack. This would allow for size time
    tradeoffs, by inserting limited nfa states to help control
    state explosion that can occur with dfas.
    * The dfa engine may pickup the ability to do limited dynamic
    variable matching, instead of fixing all variables at policy
    load time.

    Signed-off-by: John Johansen
    Signed-off-by: James Morris

    John Johansen