Confidential! Open the attached for details
letter.rtf
Description: RTF file
On 31/07/2018 00:01, Paul Cercueil wrote:
[ ... ]
>>> +- ingenic,timer-channel: Specifies the TCU channel that should be
>>> used as
>>> + system timer. If not provided, the TCU channel 0 is used for the
>>> system timer.
>>> +
>>> +- ingenic,clocksource-channel: Specifies the TCU channel th
From: Bartosz Golaszewski
We check if the pointer returned by __nvmem_device_get() is not NULL
while we should actually check if it is not IS_ERR(nvmem). Fix it.
While we're at it: fix the next error path where we should assign an
error value to cell before returning.
Signed-off-by: Bartosz Gol
On Thu, Sep 27, 2018 at 1:38 PM Geert Uytterhoeven
wrote:
> This patch series fixes various (mostly harmless) issues introduced by
> commit 3027743f83f867d8 ("gpio: Remove VLA from gpiolib").
>
> As per the "one patch should fix one issue"-policy, this series contains 3
> patches, although they a
Fix incorrect line number in example output
Signed-off-by: Andrew Murray
---
Documentation/locking/lockstat.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/locking/lockstat.txt
b/Documentation/locking/lockstat.txt
index 5786ad2..fdbeb0c 100644
--- a/Documen
On 10/01/2018 05:00 AM, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski
We check if the pointer returned by __nvmem_device_get() is not NULL
while we should actually check if it is not IS_ERR(nvmem). Fix it.
While we're at it: fix the next error path where we should assign an
error value
pon., 1 paź 2018 o 18:03 David Lechner napisał(a):
>
> On 10/01/2018 05:00 AM, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski
> >
> > We check if the pointer returned by __nvmem_device_get() is not NULL
> > while we should actually check if it is not IS_ERR(nvmem). Fix it.
> >
> > While
On Mon, 24 Sep 2018, Kees Cook wrote:
> 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
On Mon, 24 Sep 2018, Kees Cook wrote:
> 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
On Mon, 24 Sep 2018, Kees Cook wrote:
> 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: l
On Mon, 24 Sep 2018, Kees Cook wrote:
> 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
On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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: Case
On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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
Reviewed-by: John Johansen
> ---
> include/asm-generic/vmlinux.lds.h | 13 ++---
> 1
On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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:
On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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: Abde
On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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: A
On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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
Reviewed-by: John Johansen
> ---
> arch/arc/kernel/vmlinux.lds.S
On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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. Hall
On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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
I'll leave this one until after the changes you have already discussed with
Tetsuo around, END
On 09/24/2018 05:18 PM, Kees Cook wrote:
> Booting with "lsm.debug" will report future details on how LSM ordering
> decisions are being made.
>
> Signed-off-by: Kees Cook
Reviewed-by: John Johansen
> ---
> .../admin-guide/kernel-parameters.txt | 2 ++
> security/security.c
On 09/24/2018 05:18 PM, Kees Cook wrote:
> LSM initialization failures have traditionally been ignored. We should
> at least WARN when something goes wrong.
>
> Signed-off-by: Kees Cook
about time
Reviewed-by: John Johansen
> ---
> security/security.c | 4 +++-
> 1 file changed, 3 insertions
On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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
Revie
On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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
On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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
On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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 "ena
On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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 s
On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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
On Mon, 1 Oct 2018 14:07:55 -0700
John Johansen wrote:
> On 09/24/2018 05:18 PM, Kees Cook wrote:
> > 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
On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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
On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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 exis
On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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:
On Mon, 24 Sep 2018, Kees Cook wrote:
> 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 "enabl
On Mon, Oct 1, 2018 at 2:47 PM, James Morris wrote:
> On Mon, 24 Sep 2018, Kees Cook wrote:
>
>> 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 a
On Mon, Oct 1, 2018 at 2:17 PM, John Johansen
wrote:
> On 09/24/2018 05:18 PM, Kees Cook wrote:
>> 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
On 10/01/2018 02:56 PM, Kees Cook wrote:
> On Mon, Oct 1, 2018 at 2:47 PM, James Morris wrote:
>> On Mon, 24 Sep 2018, Kees Cook wrote:
>>
>>> 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 S
On Mon, Oct 1, 2018 at 2:46 PM, John Johansen
wrote:
> On 09/24/2018 05:18 PM, Kees Cook wrote:
>> 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
On Mon, Oct 1, 2018 at 3:20 PM, John Johansen
wrote:
> On 10/01/2018 02:56 PM, Kees Cook wrote:
>> On Mon, Oct 1, 2018 at 2:47 PM, James Morris wrote:
>>> On Mon, 24 Sep 2018, Kees Cook wrote:
>>>
In preparation for lifting the "is this LSM enabled?" logic out of the
individual LSMs, pa
On Mon, Oct 1, 2018 at 2:23 PM, Steven Rostedt wrote:
> On Mon, 1 Oct 2018 14:07:55 -0700
> John Johansen wrote:
>
>> On 09/24/2018 05:18 PM, Kees Cook wrote:
>> > This partially reverts commit 58eacfffc417 ("init, tracing: instrument
>> > security and console initcall trace events") since securi
On 10/01/2018 03:27 PM, Kees Cook wrote:
> On Mon, Oct 1, 2018 at 2:46 PM, John Johansen
> wrote:
>> On 09/24/2018 05:18 PM, Kees Cook wrote:
>>> This introduces the "lsm.enable=..." and "lsm.disable=..." boot parameters
>>> which each can contain a comma-separated list of LSMs to enable or
>>> di
On 10/01/2018 03:29 PM, Kees Cook wrote:
> On Mon, Oct 1, 2018 at 3:20 PM, John Johansen
> wrote:
>> On 10/01/2018 02:56 PM, Kees Cook wrote:
>>> On Mon, Oct 1, 2018 at 2:47 PM, James Morris wrote:
On Mon, 24 Sep 2018, Kees Cook wrote:
> In preparation for lifting the "is this LSM e
On Mon, Oct 1, 2018 at 3:48 PM, John Johansen
wrote:
> On 10/01/2018 03:27 PM, Kees Cook wrote:
>> On Mon, Oct 1, 2018 at 2:46 PM, John Johansen
>> wrote:
>>> On 09/24/2018 05:18 PM, Kees Cook wrote:
This introduces the "lsm.enable=..." and "lsm.disable=..." boot parameters
which each c
On Mon, Oct 1, 2018 at 4:30 PM, Kees Cook wrote:
> If we keep it, "apparmor=0 lsm_enable=apparmor" would mean it's
> enabled. Is that okay?
Actually, what the v3 series does right now is leaves AppArmor and
SELinux alone -- whatever they configured for enable/disable is left
alone.
The problem I
On 10/01/2018 04:30 PM, Kees Cook wrote:
> On Mon, Oct 1, 2018 at 3:48 PM, John Johansen
> wrote:
>> On 10/01/2018 03:27 PM, Kees Cook wrote:
>>> On Mon, Oct 1, 2018 at 2:46 PM, John Johansen
>>> wrote:
On 09/24/2018 05:18 PM, Kees Cook wrote:
> This introduces the "lsm.enable=..." and "
On Mon, Oct 1, 2018 at 4:44 PM, John Johansen
wrote:
> On 10/01/2018 04:30 PM, Kees Cook wrote:
>> If we keep it, "apparmor=0 lsm_enable=apparmor" would mean it's
>> enabled. Is that okay?
>>
> ugh I would rather get rid of apparmor=0 or to emit a warning with apparmor
> disabled, but if we have t
On 10/01/2018 04:38 PM, Kees Cook wrote:
> On Mon, Oct 1, 2018 at 4:30 PM, Kees Cook wrote:
>> If we keep it, "apparmor=0 lsm_enable=apparmor" would mean it's
>> enabled. Is that okay?
>
> Actually, what the v3 series does right now is leaves AppArmor and
> SELinux alone -- whatever they configur
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
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
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.
Signed-off-by: Kees Cook
Reviewed-by: Casey Schaufler
---
security/security.c | 8 +---
1 file ch
In preparation for switching from initcall to just a regular set of
pointers in a section, rename the internal section name.
Signed-off-by: Kees Cook
Reviewed-by: Casey Schaufler
Reviewed-by: James Morris
Reviewed-by: John Johansen
---
include/asm-generic/vmlinux.lds.h | 10 +-
includ
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
Reviewed-by: James Morris
Reviewed-by:
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
Reviewed-by: Casey Schaufler
---
Documentation/admin-guide/kernel-parameters.txt | 6 ++
security/security.c
This converts capabilities to use the new LSM_ORDER_FIRST position.
Signed-off-by: Kees Cook
Reviewed-by: Casey Schaufler
---
include/linux/lsm_hooks.h | 2 --
security/commoncap.c | 9 -
security/security.c | 9 -
3 files changed, 12 insertions(+), 8 deletions(-)
di
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.
Signed-off-by: Kees Cook
Reviewed-by: Casey Schaufler
---
include/linux/lsm_hooks.h | 5 ++---
security/ap
LSM initialization failures have traditionally been ignored. We should
at least WARN when something goes wrong.
Signed-off-by: Kees Cook
Reviewed-by: Casey Schaufler
Reviewed-by: John Johansen
---
security/security.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/securi
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
Reviewed-by: Casey Schaufler
---
include/linux/lsm_hooks.h | 1 +
security/apparmor/lsm.
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
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
Booting with "lsm.debug" will report future details on how LSM ordering
decisions are being made.
Signed-off-by: Kees Cook
Reviewed-by: Casey Schaufler
Reviewed-by: John Johansen
---
.../admin-guide/kernel-parameters.txt | 2 ++
security/security.c| 18 +++
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
Reviewed-by: Casey Schaufler
Reviewed-by: John Johansen
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
Since the struct lsm_info table is not an initcall, we can just move it
into INIT_DATA like all the other tables.
Signed-off-by: Kees Cook
Reviewed-by: Casey Schaufler
Reviewed-by: John Johansen
---
arch/arc/kernel/vmlinux.lds.S| 1 -
arch/arm/kernel/vmlinux-xip.lds.S| 1 -
arch/
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.
Signed-off-by: Kees Cook
Reviewed-by: Casey Schaufler
Reviewed-by: James Morris
Reviewed-by: John
In preparation for making LSM selections outside of the LSMs, include
the name of LSMs in struct lsm_info.
Signed-off-by: Kees Cook
Reviewed-by: Casey Schaufler
---
include/linux/lsm_hooks.h | 1 +
security/apparmor/lsm.c| 1 +
security/integrity/iint.c | 1 +
security/selinux/hooks.c |
v4:
- add Reviewed-bys.
- cosmetic tweaks.
- New patches to fully centralize LSM "enable" decisions:
LSM: Finalize centralized LSM enabling logic
apparmor: Remove boot parameter
selinux: Remove boot parameter
v3:
- add CONFIG_LSM_ENABLE and refactor resulting logic
v2:
- add "lsm.orde
Avoid copy/paste by defining SECURITY_INIT in terms of SECURITY_INITCALL.
Signed-off-by: Kees Cook
Reviewed-by: Casey Schaufler
Reviewed-by: James Morris
Reviewed-by: John Johansen
---
include/asm-generic/vmlinux.lds.h | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff
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
Reviewed-by: Casey Schaufler
Reviewed-by
This converts Yama from being a direct "minor" LSM into an ordered LSM.
Signed-off-by: Kees Cook
Reviewed-by: Casey Schaufler
---
include/linux/lsm_hooks.h | 5 -
security/Kconfig | 2 +-
security/security.c | 1 -
security/yama/yama_lsm.c | 8 +++-
4 files changed, 8 in
This converts LoadPin from being a direct "minor" LSM into an ordered LSM.
Signed-off-by: Kees Cook
Reviewed-by: Casey Schaufler
---
include/linux/lsm_hooks.h | 5 -
security/Kconfig | 2 +-
security/loadpin/loadpin.c | 8 +++-
security/security.c| 1 -
4 files change
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
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
Reviewed-by: Casey Schaufl
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:
Since LSM enabling is now centralized with CONFIG_LSM_ENABLE and
"lsm.enable=...", this removes the LSM-specific enabling logic from
SELinux.
Signed-off-by: Kees Cook
---
.../admin-guide/kernel-parameters.txt | 9 --
security/selinux/Kconfig | 29 ---
Prior to this patch, default "enable" behavior was unchanged: SELinux
and AppArmor were controlled separately from the centralized control
defined by CONFIG_LSM_ENABLE and "lsm.enable=...". This changes the
logic to give all control over to the central logic.
Instead of allowing SELinux and AppArm
Since LSM enabling is now centralized with CONFIG_LSM_ENABLE and
"lsm.enable=...", this removes the LSM-specific enabling logic from
AppArmor, though it leaves the existing userspace API visibility into
/sys/module/apparmor/parameters/enabled.
Co-developed-by: John Johansen
Signed-off-by: Kees Co
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
This provides a way to declare LSM initialization order via Kconfig.
Signed-off-by: Kees Cook
Reviewed-by: Casey Schaufler
---
security/Kconfig| 16
security/security.c | 40 +---
2 files changed, 53 insertions(+), 3 deletions(-)
diff --
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
Reviewed-by: Casey Schaufler
---
security/security.c | 59
Texas Instruments INA3221 is a triple-channel shunt and bus
voltage monitor. This patch adds a DT binding doc for it.
Signed-off-by: Nicolin Chen
---
Changelog
v7->v9:
* N/A
v6->v7:
* Restored three channel examples and merged them with the parent one
v5->v6:
* Removed status property as no ne
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=...
An ina3221 chip has three input ports. Each port is used
to measure the voltage and current of its input source.
The DT binding now has defined bindings for their input
sources, so the driver should read these information and
handle accordingly.
This patch adds a new structure of input source spe
This series adds a initial DT binding doc for ina3221. It defines
a child node to describe the input source of each ina3221 channel.
Then it changes the driver to handle the information properly.
Changelog
v8->v9:
* Fixed a potential race condition (PATCH-2)
v7->v8:
* Refined two places in ina32
On 10/1/18 5:54 PM, Kees Cook wrote:
> 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
On 10/1/18 5:54 PM, Kees Cook wrote:
> Prior to this patch, default "enable" behavior was unchanged: SELinux
> and AppArmor were controlled separately from the centralized control
> defined by CONFIG_LSM_ENABLE and "lsm.enable=...". This changes the
> logic to give all control over to the central l
On Mon, Oct 1, 2018 at 6:06 PM, Randy Dunlap wrote:
> On 10/1/18 5:54 PM, Kees Cook wrote:
>> 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
On Mon, Oct 1, 2018 at 6:18 PM, Randy Dunlap wrote:
> On 10/1/18 5:54 PM, Kees Cook wrote:
>> Prior to this patch, default "enable" behavior was unchanged: SELinux
>> and AppArmor were controlled separately from the centralized control
>> defined by CONFIG_LSM_ENABLE and "lsm.enable=...". This cha
85 matches
Mail list logo
