Re: [RFCv2 PATCH 0/7] A General Accelerator Framework, WarpDrive

On Fri, Sep 21, 2018 at 10:52:01AM -0400, Jerome Glisse wrote: > Received: from popscn.huawei.com [10.3.17.45] by Turing-Arch-b with POP3 > (fetchmail-6.3.26) for (single-drop); Fri, 21 Sep 2018 > 23:00:01 +0800 (CST) > Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by > DGGEML403-

Re: [PATCH RFCv2 3/6] mm/memory_hotplug: fix online/offline_pages called w.o. mem_hotplug_lock

On Mon, 2018-09-17 at 09:32 +0200, David Hildenbrand wrote: > Am 03.09.18 um 02:36 schrieb Rashmica: > > Hi David, > > > > > > On 21/08/18 20:44, David Hildenbrand wrote: > > > > > There seem to be some problems as result of 30467e0b3be ("mm, > > > hotplug: > > > fix concurrent memory hot-add de

[PATCH security-next v3 19/29] LSM: Prepare for reorganizing "security=" logic

This moves the string handling for "security=" boot parameter into a stored pointer instead of a string duplicate. This will allow easier handling of the string when switching logic to use the coming enable/disable infrastructure. Signed-off-by: Kees Cook --- security/security.c | 17 ---

[PATCH security-next v3 25/29] Yama: Initialize as ordered LSM

This converts Yama from being a direct "minor" LSM into an ordered LSM. Signed-off-by: Kees Cook --- include/linux/lsm_hooks.h | 5 - security/Kconfig | 2 +- security/security.c | 1 - security/yama/yama_lsm.c | 7 ++- 4 files changed, 7 insertions(+), 8 deletions(-) di

[PATCH security-next v3 26/29] LSM: Introduce enum lsm_order

In preparation for distinguishing the "capability" LSM from other LSMs, it must be ordered first. This introduces LSM_ORDER_MUTABLE for the general LSMs, LSM_ORDER_FIRST for capabilities, and LSM_ORDER_LAST for anything that must run last (e.g. Landlock may use this in the future). Signed-off-by:

[PATCH security-next v3 17/29] LSM: Introduce CONFIG_LSM_ENABLE

To provide a set of default-enabled LSMs at boot, this introduces the new CONFIG_LSM_ENABLE. A value of "all" means all builtin LSMs are enabled by default. Any unlisted LSMs will be implicitly disabled (excepting those with LSM-specific CONFIGs for enabling/disabling). The behavior of the LSM-spe

[PATCH security-next v3 22/29] LSM: Introduce CONFIG_LSM_ORDER

This provides a way to declare LSM initialization order via Kconfig. Signed-off-by: Kees Cook --- security/Kconfig| 16 security/security.c | 40 +--- 2 files changed, 53 insertions(+), 3 deletions(-) diff --git a/security/Kconfig b/secur

[PATCH security-next v3 24/29] LoadPin: Initialize as ordered LSM

This converts LoadPin from being a direct "minor" LSM into an ordered LSM. Signed-off-by: Kees Cook --- include/linux/lsm_hooks.h | 5 - security/Kconfig | 2 +- security/loadpin/loadpin.c | 7 ++- security/security.c| 1 - 4 files changed, 7 insertions(+), 8 deletions

[PATCH security-next v3 18/29] LSM: Introduce lsm.enable= and lsm.disable=

This introduces the "lsm.enable=..." and "lsm.disable=..." boot parameters which each can contain a comma-separated list of LSMs to enable or disable, respectively. The string "all" matches all LSMs. This has very similar functionality to the existing per-LSM enable handling ("apparmor.enabled=...

[PATCH security-next v3 20/29] LSM: Refactor "security=" in terms of enable/disable

For what are marked as the Legacy Major LSMs, make them effectively exclusive when selected on the "security=" boot parameter, to handle the future case of when a previously major LSMs become non-exclusive (e.g. when TOMOYO starts blob-sharing). Signed-off-by: Kees Cook --- security/security.c |

[PATCH security-next v3 03/29] LSM: Rename .security_initcall section to .lsm_info

In preparation for switching from initcall to just a regular set of pointers in a section, rename the internal section name. Cc: Arnd Bergmann Cc: James Morris Cc: "Serge E. Hallyn" Cc: Ard Biesheuvel Cc: linux-a...@vger.kernel.org Cc: linux-security-mod...@vger.kernel.org Signed-off-by: Kees

[PATCH security-next v3 06/29] vmlinux.lds.h: Move LSM_TABLE into INIT_DATA

Since the struct lsm_info table is not an initcall, we can just move it into INIT_DATA like all the other tables. Cc: linux-a...@vger.kernel.org Signed-off-by: Kees Cook --- arch/arc/kernel/vmlinux.lds.S| 1 - arch/arm/kernel/vmlinux-xip.lds.S| 1 - arch/arm64/kernel/vmlinux.lds.S

[PATCH security-next v3 12/29] LSM: Provide separate ordered initialization

This provides a place for ordered LSMs to be initialized, separate from the "major" LSMs. This is mainly a copy/paste from major_lsm_init() to ordered_lsm_init(), but it will change drastically in later patches. What is not obvious in the patch is that this change moves the integrity LSM from majo

[PATCH security-next v3 02/29] vmlinux.lds.h: Avoid copy/paste of security_init section

Avoid copy/paste by defining SECURITY_INIT in terms of SECURITY_INITCALL. Cc: Arnd Bergmann Cc: linux-a...@vger.kernel.org Signed-off-by: Kees Cook --- include/asm-generic/vmlinux.lds.h | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/include/asm-generic/vmlinux

[PATCH security-next v3 07/29] LSM: Convert security_initcall() into DEFINE_LSM()

Instead of using argument-based initializers, switch to defining the contents of struct lsm_info on a per-LSM basis. This also drops the final use of the now inaccurate "initcall" naming. Cc: John Johansen Cc: James Morris Cc: "Serge E. Hallyn" Cc: Paul Moore Cc: Stephen Smalley Cc: Casey Sch

[PATCH security-next v3 05/29] LSM: Convert from initcall to struct lsm_info

In preparation for doing more interesting LSM init probing, this converts the existing initcall system into an explicit call into a function pointer from a section-collected struct lsm_info array. Cc: James Morris Cc: "Serge E. Hallyn" Cc: Ard Biesheuvel Cc: Paul Moore Cc: linux-security-mod..

[PATCH security-next v3 01/29] LSM: Correctly announce start of LSM initialization

For a while now, the LSM core has said it was "initializED", rather than "initializING". This adjust the report to be more accurate (i.e. before this was reported before any LSMs had been initialized.) Signed-off-by: Kees Cook Reviewed-by: Casey Schaufler --- security/security.c | 3 ++- 1 file

[PATCH security-next v3 10/29] LSM: Don't ignore initialization failures

LSM initialization failures have traditionally been ignored. We should at least WARN when something goes wrong. Signed-off-by: Kees Cook --- security/security.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/security/security.c b/security/security.c index ee49b921d750..1f

[PATCH security-next v3 09/29] LSM: Provide init debugging infrastructure

Booting with "lsm.debug" will report future details on how LSM ordering decisions are being made. Signed-off-by: Kees Cook --- .../admin-guide/kernel-parameters.txt | 2 ++ security/security.c| 18 ++ 2 files changed, 20 insertions(+) diff -

[PATCH security-next v3 28/29] LSM: Separate idea of "major" LSM from "exclusive" LSM

In order to both support old "security=" Legacy Major LSM selection, and handling real exclusivity, this creates LSM_FLAG_EXCLUSIVE and updates the selection logic to handle them. Signed-off-by: Kees Cook --- include/linux/lsm_hooks.h | 1 + security/apparmor/lsm.c| 2 +- security/securit

[PATCH security-next v3 11/29] LSM: Introduce LSM_FLAG_LEGACY_MAJOR

This adds a flag for the current "major" LSMs to distinguish them when we have a universal method for ordering all LSMs. It's called "legacy" since the distinction of "major" will go away in the blob-sharing world. Signed-off-by: Kees Cook --- include/linux/lsm_hooks.h | 3 +++ security/apparmo

[PATCH security-next v3 27/29] capability: Initialize as LSM_ORDER_FIRST

This converts capabilities to use the new LSM_ORDER_FIRST position. Signed-off-by: Kees Cook --- include/linux/lsm_hooks.h | 2 -- security/commoncap.c | 8 +++- security/security.c | 9 - 3 files changed, 11 insertions(+), 8 deletions(-) diff --git a/include/linux/lsm_ho

[PATCH security-next v3 13/29] LoadPin: Rename "enable" to "enforce"

LoadPin's "enable" setting is really about enforcement, not whether or not the LSM is using LSM hooks. Instead, split this out so that LSM enabling can be logically distinct from whether enforcement is happening (for example, the pinning happens when the LSM is enabled, but the pin is only checked

[PATCH security-next v3 23/29] LSM: Introduce "lsm.order=" for boottime ordering

Provide a way to reorder LSM initialization using the new "lsm.order=" comma-separated list of LSMs. Any LSMs not listed will be added in builtin order. Signed-off-by: Kees Cook --- Documentation/admin-guide/kernel-parameters.txt | 6 ++ security/security.c | 14

[PATCH security-next v3 14/29] LSM: Plumb visibility into optional "enabled" state

In preparation for lifting the "is this LSM enabled?" logic out of the individual LSMs, pass in any special enabled state tracking (as needed for SELinux, AppArmor, and LoadPin). This should be an "int" to include handling any future cases where "enabled" is exposed via sysctl which has no "bool" t

[PATCH security-next v3 29/29] LSM: Add all exclusive LSMs to ordered initialization

This removes CONFIG_DEFAULT_SECURITY in favor of the explicit build-time ordering offered by CONFIG_LSM_ORDER, and adds all the exclusive LSMs to the ordered LSM initialization. The old meaning of CONFIG_DEFAULT_SECURITY is now captured by which exclusive LSM is listed first in the LSM order. Sign

[PATCH security-next v3 16/29] LSM: Prepare for arbitrary LSM enabling

Before now, all the LSMs that did not specify an "enable" variable in their struct lsm_info were considered enabled by default. This prepares to make LSM enabling more explicit. For all LSMs without an explicit "enable" variable, a hard-coded storage location is chosen, and all LSMs without an exte

[PATCH security-next v3 15/29] LSM: Lift LSM selection out of individual LSMs

As a prerequisite to adjusting LSM selection logic in the future, this moves the selection logic up out of the individual major LSMs, making their init functions only run when actually enabled. This considers all LSMs enabled by default unless they specified an external "enable" variable. Signed-o

[PATCH security-next v3 04/29] LSM: Remove initcall tracing

This partially reverts commit 58eacfffc417 ("init, tracing: instrument security and console initcall trace events") since security init calls are about to no longer resemble regular init calls. Cc: James Morris Cc: "Serge E. Hallyn" Cc: Abderrahmane Benbachir Cc: Steven Rostedt (VMware) Cc: li

[PATCH security-next v3 08/29] LSM: Record LSM name in struct lsm_info

In preparation for making LSM selections outside of the LSMs, include the name of LSMs in struct lsm_info. Cc: James Morris Signed-off-by: Kees Cook --- include/linux/lsm_hooks.h | 4 1 file changed, 4 insertions(+) diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h index

[PATCH security-next v3 21/29] LSM: Build ordered list of ordered LSMs for init

This constructs a list of ordered LSMs to initialize, using a hard-coded list of only "integrity": minor LSMs continue to have direct hook calls, and major LSMs continue to initialize separately. Signed-off-by: Kees Cook --- security/security.c | 59 +++--

[PATCH security-next v3 00/29] LSM: Explict LSM ordering

v3: - add CONFIG_LSM_ENABLE and refactor resulting logic v2: - add "lsm.order=" and CONFIG_LSM_ORDER instead of overloading "security=" - reorganize introduction of ordering logic code Overview: This refactors the LSM registration and initialization infrastructure to more centrally support diffe

Re: [PATCH v12 9/9] cpuset: Support forced turning off of partition flag

On 09/06/2018 05:20 PM, Waiman Long wrote: > On 08/27/2018 01:50 PM, Waiman Long wrote: >> On 08/27/2018 12:40 PM, Tejun Heo wrote: >>> Hello, Waiman. >>> >>> On Mon, Aug 27, 2018 at 10:41:24AM -0400, Waiman Long wrote: Cpuset allows arbitrary modification of cpu list in "cpuset.cpus" eve

Re: [RFC PATCH v4 00/27] Control Flow Enforcement: Shadow Stack

On Fri, 2018-09-21 at 15:53 -0700, Dave Hansen wrote: > On 09/21/2018 08:03 AM, Yu-cheng Yu wrote: > > The previous version of CET patches can be found in the following > > link: > > > > https://lkml.org/lkml/2018/8/30/608 > > So, this is an RFC, but there no mention of what you want comments *

Re: [PATCH v9 00/20] kasan: add software tag-based mode for arm64

On Fri, Sep 21, 2018 at 5:13 PM, Andrey Konovalov wrote: > This patchset adds a new software tag-based mode to KASAN [1]. > (Initially this mode was called KHWASAN, but it got renamed, > see the naming rationale at the end of this section). Reviewed-by: Dmitry Vyukov > The plan is to implement

Re: [PATCH v6 11/11] arm64: annotate user pointers casts detected by sparse

On Mon, Sep 17, 2018 at 7:01 PM, Andrey Konovalov wrote: > I took another look at the changes this patchset does to the kernel > and here are my thoughts: > > I see two ways how a (potentially tagged) user pointer gets into the kernel: > > 1. A pointer is passed to a syscall (directly as an argume

Re: [PATCH v5 00/15] Compiler Attributes

On Thu, Sep 20, 2018 at 07:22:46PM +0200, Miguel Ojeda wrote: > The Compiler Attributes series is an effort to disentangle > the include/linux/compiler*.h headers and bring them up to date. > > The main idea behind the series is to use feature checking macros > (i.e. __has_attribute) instead of co

Re: [PATCH 0/2] gpiolib: Fix issues introduced by fast bitmap processing path

Hi Marek, 2018-09-24 13:38 GMT+02:00, Marek Szyprowski : > Hi Janusz, > > On 2018-09-24 13:08, Janusz Krzysztofik wrote: >> 2018-09-24 11:43 GMT+02:00, Marek Szyprowski : >>> On 2018-09-24 01:53, Janusz Krzysztofik wrote: While investigating possible reasons of GPIO fast bitmap processing >>>

Re: [PATCH 0/2] gpiolib: Fix issues introduced by fast bitmap processing path

Hi Janusz, On 2018-09-24 13:08, Janusz Krzysztofik wrote: > 2018-09-24 11:43 GMT+02:00, Marek Szyprowski : >> On 2018-09-24 01:53, Janusz Krzysztofik wrote: >>> While investigating possible reasons of GPIO fast bitmap processing >>> related boot hang on Samsung Snow Chromebook, reported by Marek >

Re: [PATCH 0/2] gpiolib: Fix issues introduced by fast bitmap processing path

Hi Marek, 2018-09-24 11:43 GMT+02:00, Marek Szyprowski : > Hi Janusz, > > On 2018-09-24 01:53, Janusz Krzysztofik wrote: >> While investigating possible reasons of GPIO fast bitmap processing >> related boot hang on Samsung Snow Chromebook, reported by Marek >> Szyprowski (thanks!), I've discovere

Re: [PATCH 0/2] gpiolib: Fix issues introduced by fast bitmap processing path

Hi Janusz, On 2018-09-24 01:53, Janusz Krzysztofik wrote: > While investigating possible reasons of GPIO fast bitmap processing > related boot hang on Samsung Snow Chromebook, reported by Marek > Szyprowski (thanks!), I've discovered one coding bug, addressed by > PATCH 1/2 of this series, and one

Re: [PATCH v8 09/20] kasan: preassign tags to objects with ctors or SLAB_TYPESAFE_BY_RCU

On Fri, Sep 21, 2018 at 2:24 PM, Andrey Konovalov wrote: > On Fri, Sep 21, 2018 at 1:25 PM, Dmitry Vyukov wrote: >> On Wed, Sep 19, 2018 at 8:54 PM, Andrey Konovalov >> wrote: > >>> if (!shuffle) { >>> for_each_object_idx(p, idx, s, start, page->objects) { >>> -

[PATCH v5 00/15] Compiler Attributes

[ Please CC me I am not subcribed to this ML ] Quote from : The Compiler Attributes series is an effort to disentangle the include/linux/compiler*.h headers and bring them up to date. The main idea behind the series is to use feature checking macros (i.e. __h

Re: [PATCH 2/2] gpiolib: Fix array members of same chip processed separately

On Mon, Sep 24, 2018 at 1:52 AM Janusz Krzysztofik wrote: > New code introduced by commit bf9346f5d47b ("gpiolib: Identify arrays > matching GPIO hardware") forcibly tries to find an array member which > has its array index number equal to its hardware pin number and set > up an array info for po

Re: [PATCH 1/2] gpiolib: Fix missing updates of bitmap index

On Mon, Sep 24, 2018 at 1:52 AM Janusz Krzysztofik wrote: > In new code introduced by commit b17566a6b08b ("gpiolib: Implement fast > processing path in get/set array"), bitmap index is not updated with > next found zero bit position as it should while skipping over pins > already processed via f

Re: [PATCH v7 05/24] clocksource: Add a new timer-ingenic driver

On 24/09/2018 08:53, Paul Cercueil wrote: > > Le 24 sept. 2018 07:58, Daniel Lezcano a écrit : >> >> On 24/09/2018 07:49, Paul Cercueil wrote: >>> >>> Le 24 sept. 2018 07:35, Daniel Lezcano a >>> écrit : On 24/09/2018 07:24, Paul Cercueil wrote: > Hi Daniel, > > Le 24