* Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)
From: Stephen Smalley @ 2019-05-22 13:56 UTC (permalink / raw)
To: Jarkko Sakkinen, Sean Christopherson
Cc: Andy Lutomirski, James Morris, Serge E. Hallyn, LSM List,
Paul Moore, Eric Paris, selinux, Jethro Beekman, Xing, Cedric,
Hansen, Dave, Thomas Gleixner, Dr. Greg, Linus Torvalds, LKML,
X86 ML, linux-sgx@vger.kernel.org, Andrew Morton,
nhorman@redhat.com, npmccallum@redhat.com, Ayoun, Serge,
Katz-zamir, Shay, Huang, Haitao, Andy Shevchenko, Svahn, Kai,
Borislav Petkov, Josh Triplett, Huang, Kai, David Rientjes
In-Reply-To: <20190522132227.GD31176@linux.intel.com>
On 5/22/19 9:22 AM, Jarkko Sakkinen wrote:
> On Wed, May 22, 2019 at 04:20:22PM +0300, Jarkko Sakkinen wrote:
>> On Tue, May 21, 2019 at 08:51:40AM -0700, Sean Christopherson wrote:
>>> Except that mmap() is more or less required to guarantee that ELRANGE
>>> established by ECREATE is available. And we want to disallow mmap() as
>>> soon as the first EADD is done so that userspace can't remap the enclave's
>>> VMAs via munmap()->mmap() and gain execute permissions to pages that were
>>> EADD'd as NX.
>>
>> We don't want to guarantee such thing and it is not guaranteed. It does
>> not fit at all to the multi process work done. Enclaves are detached
>> from any particular process addresse spaces. It is responsibility of
>> process to open windows to them.
>>
>> That would be completely against work that we've done lately.
>
> Example use case: you have a process that just constructs an enclave
> and sends it to another process or processes for use. The constructor
> process could have basically anything on that range. This was the key
> goal of the fd based enclave work.
What exactly happens in the constructor versus the recipient processes?
Which process performs each of the necessary open(), mmap(), and ioctl()
calls for setting up the enclave? Can you provide a high level overview
of the sequence of userspace calls by the constructor and by the
recipient similar to what Sean showed earlier for just a single process?
^ permalink raw reply
* Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)
From: Jarkko Sakkinen @ 2019-05-22 13:22 UTC (permalink / raw)
To: Sean Christopherson
Cc: Andy Lutomirski, James Morris, Serge E. Hallyn, LSM List,
Paul Moore, Stephen Smalley, Eric Paris, selinux, Jethro Beekman,
Xing, Cedric, Hansen, Dave, Thomas Gleixner, Dr. Greg,
Linus Torvalds, LKML, X86 ML, linux-sgx@vger.kernel.org,
Andrew Morton, nhorman@redhat.com, npmccallum@redhat.com,
Ayoun, Serge, Katz-zamir, Shay, Huang, Haitao, Andy Shevchenko,
Svahn, Kai, Borislav Petkov, Josh Triplett, Huang, Kai,
David Rientjes
In-Reply-To: <20190522132022.GC31176@linux.intel.com>
On Wed, May 22, 2019 at 04:20:22PM +0300, Jarkko Sakkinen wrote:
> On Tue, May 21, 2019 at 08:51:40AM -0700, Sean Christopherson wrote:
> > Except that mmap() is more or less required to guarantee that ELRANGE
> > established by ECREATE is available. And we want to disallow mmap() as
> > soon as the first EADD is done so that userspace can't remap the enclave's
> > VMAs via munmap()->mmap() and gain execute permissions to pages that were
> > EADD'd as NX.
>
> We don't want to guarantee such thing and it is not guaranteed. It does
> not fit at all to the multi process work done. Enclaves are detached
> from any particular process addresse spaces. It is responsibility of
> process to open windows to them.
>
> That would be completely against work that we've done lately.
Example use case: you have a process that just constructs an enclave
and sends it to another process or processes for use. The constructor
process could have basically anything on that range. This was the key
goal of the fd based enclave work.
/Jarkko
^ permalink raw reply
* Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)
From: Jarkko Sakkinen @ 2019-05-22 13:20 UTC (permalink / raw)
To: Sean Christopherson
Cc: Andy Lutomirski, James Morris, Serge E. Hallyn, LSM List,
Paul Moore, Stephen Smalley, Eric Paris, selinux, Jethro Beekman,
Xing, Cedric, Hansen, Dave, Thomas Gleixner, Dr. Greg,
Linus Torvalds, LKML, X86 ML, linux-sgx@vger.kernel.org,
Andrew Morton, nhorman@redhat.com, npmccallum@redhat.com,
Ayoun, Serge, Katz-zamir, Shay, Huang, Haitao, Andy Shevchenko,
Svahn, Kai, Borislav Petkov, Josh Triplett, Huang, Kai,
David Rientjes
In-Reply-To: <20190521155140.GE22089@linux.intel.com>
On Tue, May 21, 2019 at 08:51:40AM -0700, Sean Christopherson wrote:
> Except that mmap() is more or less required to guarantee that ELRANGE
> established by ECREATE is available. And we want to disallow mmap() as
> soon as the first EADD is done so that userspace can't remap the enclave's
> VMAs via munmap()->mmap() and gain execute permissions to pages that were
> EADD'd as NX.
We don't want to guarantee such thing and it is not guaranteed. It does
not fit at all to the multi process work done. Enclaves are detached
from any particular process addresse spaces. It is responsibility of
process to open windows to them.
That would be completely against work that we've done lately.
> Actually, conceptually it's probably more intuitive to disallow mmap() at
> ECREATE, i.e. the act of creating an enclave pins the associated virtual
> address range until the enclave is destroyed.
/Jarkko
^ permalink raw reply
* Re: sleep in selinux_audit_rule_init
From: Stephen Smalley @ 2019-05-22 13:16 UTC (permalink / raw)
To: Mimi Zohar, Janne Karhunen, paul; +Cc: linux-integrity, linux-security-module
In-Reply-To: <1558530022.4347.11.camel@linux.ibm.com>
On 5/22/19 9:00 AM, Mimi Zohar wrote:
> On Wed, 2019-05-22 at 08:41 -0400, Stephen Smalley wrote:
>> Another potentially worrisome aspect of the current
>> ima_lsm_update_rules() logic is that it does a BUG_ON() if the attempt
>> to update the rule fails, which could occur if e.g. one had an IMA
>> policy rule based on a given domain/type and that domain/type were
>> removed from policy (e.g. via policy module removal). Contrast with the
>> handling in audit_dupe_lsm_field(). The existing ima_lsm_update_rules()
>> logic could also yield a BUG_ON upon transient memory allocation failure.
>
> The original design was based on the assumption that SELinux labels
> could not be removed, only new ones could be added. Sounds like that
> isn't the case any longer.
That's never really been the case for SELinux; it has always been
possible to reload with a policy that renders previously valid security
contexts invalid. What has changed over time is the ability of SELinux
to gracefully handle the situation where a security context is rendered
invalid upon a policy reload and then later restored to validity via a
subsequent policy reload (e.g. removing a policy module and then
re-adding it), but even that deferred mapping of contexts support has
been around since 2008.
What you are likely thinking of is the conventional practice of
distributions, which is generally to not remove domains/types from their
policy or to at least retain a type alias for compatibility reasons.
But that's just a convention, not guaranteed by any mechanism, and users
are free to remove policy modules.
^ permalink raw reply
* Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)
From: Jarkko Sakkinen @ 2019-05-22 13:10 UTC (permalink / raw)
To: Jethro Beekman
Cc: Andy Lutomirski, Sean Christopherson, James Morris,
Serge E. Hallyn, LSM List, Paul Moore, Stephen Smalley,
Eric Paris, selinux@vger.kernel.org, Xing, Cedric, Hansen, Dave,
Thomas Gleixner, Dr. Greg, Linus Torvalds, LKML, X86 ML,
linux-sgx@vger.kernel.org, Andrew Morton, nhorman@redhat.com,
npmccallum@redhat.com, Ayoun, Serge, Katz-zamir, Shay,
Huang, Haitao, Andy Shevchenko, Svahn, Kai, Borislav Petkov,
Josh Triplett, Huang, Kai, David Rientjes
In-Reply-To: <c373cb32-16b2-e17d-b554-e4f2f295f497@fortanix.com>
On Tue, May 21, 2019 at 03:24:18PM +0000, Jethro Beekman wrote:
> On 2019-05-21 08:19, Jarkko Sakkinen wrote:
> > We could even disallow mmap() before EINIT done.
> This would be extremely annoying in software because now you have to save
> the all the page permissions somewhere between EADD and mprotect.
Actually you don't have to use mprotect anymore that much.
You can just do multiple mmap's even with v20 after EINIT, one
for each region (albeit it does not enforce above).
/Jarkko
^ permalink raw reply
* Re: sleep in selinux_audit_rule_init
From: Mimi Zohar @ 2019-05-22 13:00 UTC (permalink / raw)
To: Stephen Smalley, Janne Karhunen, paul
Cc: linux-integrity, linux-security-module
In-Reply-To: <4a725f06-8244-8264-a911-df7ca1c66789@tycho.nsa.gov>
On Wed, 2019-05-22 at 08:41 -0400, Stephen Smalley wrote:
> Another potentially worrisome aspect of the current
> ima_lsm_update_rules() logic is that it does a BUG_ON() if the attempt
> to update the rule fails, which could occur if e.g. one had an IMA
> policy rule based on a given domain/type and that domain/type were
> removed from policy (e.g. via policy module removal). Contrast with the
> handling in audit_dupe_lsm_field(). The existing ima_lsm_update_rules()
> logic could also yield a BUG_ON upon transient memory allocation failure.
The original design was based on the assumption that SELinux labels
could not be removed, only new ones could be added. Sounds like that
isn't the case any longer.
Mimi
^ permalink raw reply
* Re: sleep in selinux_audit_rule_init
From: Janne Karhunen @ 2019-05-22 12:47 UTC (permalink / raw)
To: Stephen Smalley; +Cc: Mimi Zohar, paul, linux-integrity, linux-security-module
In-Reply-To: <e8dcc9a2-594d-f81a-32a7-e18f591c6062@tycho.nsa.gov>
On Wed, May 22, 2019 at 3:20 PM Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > I managed to hit a following BUG, looks like ima can call
> > selinux_audit_rule_init that can sleep in rcu critical section in
> > ima_match_policy():
> >
> > __might_sleep
> > kmem_cache_alloc_trace
> > selinux_audit_rule_init <<< kzalloc (.. GFP_KERNEL)
> > security_audit_rule_init
> > ima_match_policy <<< list_for_each_entry_rcu
> > ima_get_action
> > process_measurement
> > ima_file_check
> > path_openat
> > do_filp_open
> > ..
> >
> > I guess this is the ima_match_rules() calling ima_lsm_update_rules()
> > when it concludes that the selinux policy may have been reloaded.
> >
> > The easy way for me to fix my own butt in this regard is to change the
> > selinux allocation not to wait, but Paul would you be OK with such
> > change? The alternative looks like a pretty big change in the ima?
>
> This is perhaps a sign of a deeper bug in IMA; if they are in the middle
> of matching against their policy rules, then they shouldn't be
> updating/modifying those rules in the middle of match processing? How
> is that safe under RCU?
Heh indeed...
> If you look at how the audit subsystem deals with the same problem, they
> have a callback (audit_update_lsm_rules) that is called upon an AVC
> reset (hence upon a policy reload) and can update all of their rules at
> that time, not lazily during matching. Since that time, a more general
> notifier mechanism was added, register_lsm_notifier(), and is used by
> infiniband to update its state upon policy changes.
I guess the same approach could work here. I'll see how that would
look like exactly..
--
Janne
^ permalink raw reply
* Re: sleep in selinux_audit_rule_init
From: Stephen Smalley @ 2019-05-22 12:41 UTC (permalink / raw)
To: Janne Karhunen, Mimi Zohar, paul; +Cc: linux-integrity, linux-security-module
In-Reply-To: <e8dcc9a2-594d-f81a-32a7-e18f591c6062@tycho.nsa.gov>
On 5/22/19 8:20 AM, Stephen Smalley wrote:
> On 5/22/19 7:49 AM, Janne Karhunen wrote:
>> Hi,
>>
>> I managed to hit a following BUG, looks like ima can call
>> selinux_audit_rule_init that can sleep in rcu critical section in
>> ima_match_policy():
>>
>> __might_sleep
>> kmem_cache_alloc_trace
>> selinux_audit_rule_init <<< kzalloc (.. GFP_KERNEL)
>> security_audit_rule_init
>> ima_match_policy <<< list_for_each_entry_rcu
>> ima_get_action
>> process_measurement
>> ima_file_check
>> path_openat
>> do_filp_open
>> ..
>>
>> I guess this is the ima_match_rules() calling ima_lsm_update_rules()
>> when it concludes that the selinux policy may have been reloaded.
>>
>> The easy way for me to fix my own butt in this regard is to change the
>> selinux allocation not to wait, but Paul would you be OK with such
>> change? The alternative looks like a pretty big change in the ima?
>
> This is perhaps a sign of a deeper bug in IMA; if they are in the middle
> of matching against their policy rules, then they shouldn't be
> updating/modifying those rules in the middle of match processing? How
> is that safe under RCU?
>
> If you look at how the audit subsystem deals with the same problem, they
> have a callback (audit_update_lsm_rules) that is called upon an AVC
> reset (hence upon a policy reload) and can update all of their rules at
> that time, not lazily during matching. Since that time, a more general
> notifier mechanism was added, register_lsm_notifier(), and is used by
> infiniband to update its state upon policy changes.
Another potentially worrisome aspect of the current
ima_lsm_update_rules() logic is that it does a BUG_ON() if the attempt
to update the rule fails, which could occur if e.g. one had an IMA
policy rule based on a given domain/type and that domain/type were
removed from policy (e.g. via policy module removal). Contrast with the
handling in audit_dupe_lsm_field(). The existing ima_lsm_update_rules()
logic could also yield a BUG_ON upon transient memory allocation failure.
^ permalink raw reply
* Re: sleep in selinux_audit_rule_init
From: Stephen Smalley @ 2019-05-22 12:20 UTC (permalink / raw)
To: Janne Karhunen, Mimi Zohar, paul; +Cc: linux-integrity, linux-security-module
In-Reply-To: <CAE=NcrYsfQ2ijJJMEyTFoWnFqF2qGS=B2JNsVaE8WUNcGS7D9Q@mail.gmail.com>
On 5/22/19 7:49 AM, Janne Karhunen wrote:
> Hi,
>
> I managed to hit a following BUG, looks like ima can call
> selinux_audit_rule_init that can sleep in rcu critical section in
> ima_match_policy():
>
> __might_sleep
> kmem_cache_alloc_trace
> selinux_audit_rule_init <<< kzalloc (.. GFP_KERNEL)
> security_audit_rule_init
> ima_match_policy <<< list_for_each_entry_rcu
> ima_get_action
> process_measurement
> ima_file_check
> path_openat
> do_filp_open
> ..
>
> I guess this is the ima_match_rules() calling ima_lsm_update_rules()
> when it concludes that the selinux policy may have been reloaded.
>
> The easy way for me to fix my own butt in this regard is to change the
> selinux allocation not to wait, but Paul would you be OK with such
> change? The alternative looks like a pretty big change in the ima?
This is perhaps a sign of a deeper bug in IMA; if they are in the middle
of matching against their policy rules, then they shouldn't be
updating/modifying those rules in the middle of match processing? How
is that safe under RCU?
If you look at how the audit subsystem deals with the same problem, they
have a callback (audit_update_lsm_rules) that is called upon an AVC
reset (hence upon a policy reload) and can update all of their rules at
that time, not lazily during matching. Since that time, a more general
notifier mechanism was added, register_lsm_notifier(), and is used by
infiniband to update its state upon policy changes.
^ permalink raw reply
* sleep in selinux_audit_rule_init
From: Janne Karhunen @ 2019-05-22 11:49 UTC (permalink / raw)
To: Mimi Zohar, paul; +Cc: linux-integrity, linux-security-module
Hi,
I managed to hit a following BUG, looks like ima can call
selinux_audit_rule_init that can sleep in rcu critical section in
ima_match_policy():
__might_sleep
kmem_cache_alloc_trace
selinux_audit_rule_init <<< kzalloc (.. GFP_KERNEL)
security_audit_rule_init
ima_match_policy <<< list_for_each_entry_rcu
ima_get_action
process_measurement
ima_file_check
path_openat
do_filp_open
..
I guess this is the ima_match_rules() calling ima_lsm_update_rules()
when it concludes that the selinux policy may have been reloaded.
The easy way for me to fix my own butt in this regard is to change the
selinux allocation not to wait, but Paul would you be OK with such
change? The alternative looks like a pretty big change in the ima?
--
Janne
^ permalink raw reply
* Re: [RFC 2/2] Add the ability to lock down access to the running kernel image
From: James Morris @ 2019-05-22 2:48 UTC (permalink / raw)
To: Matthew Garrett; +Cc: linux-security-module, linux-kernel, David Howells
In-Reply-To: <20190521224013.3782-3-matthewgarrett@google.com>
On Tue, 21 May 2019, Matthew Garrett wrote:
> + int (*locked_down)(const char *where, enum lockdown_level level);
> +static int lockdown_is_locked_down(const char *what, enum lockdown_level level)
I'm guessing 'what' is the best option here.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [RFC] Turn lockdown into an LSM
From: James Morris @ 2019-05-22 2:40 UTC (permalink / raw)
To: Matthew Garrett; +Cc: linux-security-module, linux-kernel, Andy Lutomirski
In-Reply-To: <20190521224013.3782-1-matthewgarrett@google.com>
On Tue, 21 May 2019, Matthew Garrett wrote:
> Hi James,
>
> This is a quick attempt to integrate lockdown into the existing LSM
> framework. It adds a new lockdown security hook and an LSM that defines
> the existing coarse-grained policy, and also adds a new
> DEFINE_EARLY_LSM() definition in order to permit lockdown (and
> potentially other modules) to be initialised at the top of kernel init
> in order to allow policy to be imposed on stuff that happens in
> setup_arch(). The goal here is to allow policy to be devolved to other
> LSMs on systems that have a secure mechanism for loading LSM policy
> early in boot, allowing creation of arbitrarily complicated policies
> without interfering with the common-case coarse-grained approach.
>
> This should probably be extended so a uapi-exposed constant is passed to
> the hook in order to make it easier to write policy in other LSMs, but
> does this broadly look like you were imagining?
This looks promising!
An LSM could also potentially implement its own policy for the hook.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH 10/10] docs: fix broken documentation links
From: Federico Vaga @ 2019-05-21 22:56 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, x86, linux-acpi, linux-edac, netdev, devicetree,
linux-pci, linux-arm-kernel, linux-amlogic, linux-arm-msm,
linux-gpio, linux-i2c, linuxppc-dev, xen-devel,
platform-driver-x86, devel, kvm, virtualization, devel, linux-mm,
linux-security-module, linux-kselftest
In-Reply-To: <4fd1182b4a41feb2447c7ccde4d7f0a6b3c92686.1558362030.git.mchehab+samsung@kernel.org>
On Monday, May 20, 2019 4:47:39 PM CEST Mauro Carvalho Chehab wrote:
> Mostly due to x86 and acpi conversion, several documentation
> links are still pointing to the old file. Fix them.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> Documentation/acpi/dsd/leds.txt | 2 +-
> Documentation/admin-guide/kernel-parameters.rst | 6 +++---
> Documentation/admin-guide/kernel-parameters.txt | 16 ++++++++--------
> Documentation/admin-guide/ras.rst | 2 +-
> .../devicetree/bindings/net/fsl-enetc.txt | 7 +++----
> .../bindings/pci/amlogic,meson-pcie.txt | 2 +-
> .../bindings/regulator/qcom,rpmh-regulator.txt | 2 +-
> Documentation/devicetree/booting-without-of.txt | 2 +-
> Documentation/driver-api/gpio/board.rst | 2 +-
> Documentation/driver-api/gpio/consumer.rst | 2 +-
> .../firmware-guide/acpi/enumeration.rst | 2 +-
> .../firmware-guide/acpi/method-tracing.rst | 2 +-
> Documentation/i2c/instantiating-devices | 2 +-
> Documentation/sysctl/kernel.txt | 4 ++--
> .../translations/it_IT/process/4.Coding.rst | 2 +-
> .../translations/it_IT/process/howto.rst | 2 +-
> .../it_IT/process/stable-kernel-rules.rst | 4 ++--
> .../translations/zh_CN/process/4.Coding.rst | 2 +-
> Documentation/x86/x86_64/5level-paging.rst | 2 +-
> Documentation/x86/x86_64/boot-options.rst | 4 ++--
> .../x86/x86_64/fake-numa-for-cpusets.rst | 2 +-
> MAINTAINERS | 6 +++---
> arch/arm/Kconfig | 2 +-
> arch/arm64/kernel/kexec_image.c | 2 +-
> arch/powerpc/Kconfig | 2 +-
> arch/x86/Kconfig | 16 ++++++++--------
> arch/x86/Kconfig.debug | 2 +-
> arch/x86/boot/header.S | 2 +-
> arch/x86/entry/entry_64.S | 2 +-
> arch/x86/include/asm/bootparam_utils.h | 2 +-
> arch/x86/include/asm/page_64_types.h | 2 +-
> arch/x86/include/asm/pgtable_64_types.h | 2 +-
> arch/x86/kernel/cpu/microcode/amd.c | 2 +-
> arch/x86/kernel/kexec-bzimage64.c | 2 +-
> arch/x86/kernel/pci-dma.c | 2 +-
> arch/x86/mm/tlb.c | 2 +-
> arch/x86/platform/pvh/enlighten.c | 2 +-
> drivers/acpi/Kconfig | 10 +++++-----
> drivers/net/ethernet/faraday/ftgmac100.c | 2 +-
> .../fieldbus/Documentation/fieldbus_dev.txt | 4 ++--
> drivers/vhost/vhost.c | 2 +-
> include/acpi/acpi_drivers.h | 2 +-
> include/linux/fs_context.h | 2 +-
> include/linux/lsm_hooks.h | 2 +-
> mm/Kconfig | 2 +-
> security/Kconfig | 2 +-
> tools/include/linux/err.h | 2 +-
> tools/objtool/Documentation/stack-validation.txt | 4 ++--
> tools/testing/selftests/x86/protection_keys.c | 2 +-
> 49 files changed, 78 insertions(+), 79 deletions(-)
>
> diff --git a/Documentation/acpi/dsd/leds.txt
> b/Documentation/acpi/dsd/leds.txt index 81a63af42ed2..cc58b1a574c5 100644
> --- a/Documentation/acpi/dsd/leds.txt
> +++ b/Documentation/acpi/dsd/leds.txt
> @@ -96,4 +96,4 @@ where
>
> <URL:http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-da
> ta-extension-UUID-v1.1.pdf>, referenced 2019-02-21.
>
> -[7] Documentation/acpi/dsd/data-node-reference.txt
> +[7] Documentation/firmware-guide/acpi/dsd/data-node-references.rst
> diff --git a/Documentation/admin-guide/kernel-parameters.rst
> b/Documentation/admin-guide/kernel-parameters.rst index
> 0124980dca2d..8d3273e32eb1 100644
> --- a/Documentation/admin-guide/kernel-parameters.rst
> +++ b/Documentation/admin-guide/kernel-parameters.rst
> @@ -167,7 +167,7 @@ parameter is applicable::
> X86-32 X86-32, aka i386 architecture is enabled.
> X86-64 X86-64 architecture is enabled.
> More X86-64 boot options can be found in
> - Documentation/x86/x86_64/boot-options.txt
.
> + Documentation/x86/x86_64/boot-options.rst.
> X86 Either 32-bit or 64-bit x86 (same as X86-32+X86-64)
> X86_UV SGI UV support is enabled.
> XEN Xen support is enabled
> @@ -181,10 +181,10 @@ In addition, the following text indicates that the
> option:: Parameters denoted with BOOT are actually interpreted by the boot
> loader, and have no meaning to the kernel directly.
> Do not modify the syntax of boot loader parameters without extreme
> -need or coordination with <Documentation/x86/boot.txt>.
> +need or coordination with <Documentation/x86/boot.rst>.
>
> There are also arch-specific kernel-parameters not documented here.
> -See for example <Documentation/x86/x86_64/boot-options.txt>.
> +See for example <Documentation/x86/x86_64/boot-options.rst>.
>
> Note that ALL kernel parameters listed below are CASE SENSITIVE, and that
> a trailing = on the name of any parameter states that that parameter will
> diff --git a/Documentation/admin-guide/kernel-parameters.txt
> b/Documentation/admin-guide/kernel-parameters.txt index
> 138f6664b2e2..bc5f202d42ec 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -53,7 +53,7 @@
> ACPI_DEBUG_PRINT statements, e.g.,
> ACPI_DEBUG_PRINT((ACPI_DB_INFO, ...
> The debug_level mask defaults to "info".
See
> - Documentation/acpi/debug.txt for more
information about
> + Documentation/firmware-guide/acpi/debug.rst
for more information about
> debug layers and levels.
>
> Enable processor driver info messages:
> @@ -963,7 +963,7 @@
> for details.
>
> nompx [X86] Disables Intel Memory Protection
Extensions.
> - See Documentation/x86/intel_mpx.txt for
more
> + See Documentation/x86/intel_mpx.rst for
more
> information about the feature.
>
> nopku [X86] Disable Memory Protection Keys CPU
feature found
> @@ -1189,7 +1189,7 @@
> that is to be dynamically loaded by Linux.
If there are
> multiple variables with the same name but
with different
> vendor GUIDs, all of them will be loaded.
See
> - Documentation/acpi/ssdt-overlays.txt for
details.
> + Documentation/admin-guide/acpi/ssdt-
overlays.rst for details.
>
>
> eisa_irq_edge= [PARISC,HW]
> @@ -2383,7 +2383,7 @@
>
> mce [X86-32] Machine Check Exception
>
> - mce=option [X86-64] See Documentation/x86/x86_64/boot-
options.txt
> + mce=option [X86-64] See Documentation/x86/x86_64/boot-
options.rst
>
> md= [HW] RAID subsystems devices and level
> See Documentation/admin-guide/md.rst.
> @@ -2439,7 +2439,7 @@
> set according to the
> CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE
kernel config
> option.
> - See Documentation/memory-hotplug.txt.
> + See Documentation/admin-guide/mm/memory-
hotplug.rst.
>
> memmap=exactmap [KNL,X86] Enable setting of an exact
> E820 memory map, as specified by the user.
> @@ -2528,7 +2528,7 @@
> mem_encrypt=on: Activate
SME
> mem_encrypt=off: Do not activate SME
>
> - Refer to Documentation/x86/amd-memory-
encryption.txt
> + Refer to Documentation/x86/amd-memory-
encryption.rst
> for details on when memory encryption can
be activated.
>
> mem_sleep_default= [SUSPEND] Default system suspend mode:
> @@ -3528,7 +3528,7 @@
> See Documentation/blockdev/paride.txt.
>
> pirq= [SMP,APIC] Manual mp-table setup
> - See Documentation/x86/i386/IO-APIC.txt.
> + See Documentation/x86/i386/IO-APIC.rst.
>
> plip= [PPT,NET] Parallel port network link
> Format: { parport<nr> | timid | 0 }
> @@ -5054,7 +5054,7 @@
> Can be used multiple times for multiple
devices.
>
> vga= [BOOT,X86-32] Select a particular video
mode
> - See Documentation/x86/boot.txt and
> + See Documentation/x86/boot.rst and
> Documentation/svga.txt.
> Use vga=ask for menu.
> This is actually a boot loader parameter;
the value is
> diff --git a/Documentation/admin-guide/ras.rst
> b/Documentation/admin-guide/ras.rst index c7495e42e6f4..2b20f5f7380d 100644
> --- a/Documentation/admin-guide/ras.rst
> +++ b/Documentation/admin-guide/ras.rst
> @@ -199,7 +199,7 @@ Architecture (MCA)\ [#f3]_.
> mode).
>
> .. [#f3] For more details about the Machine Check Architecture (MCA),
> - please read Documentation/x86/x86_64/machinecheck at the Kernel tree.
> + please read Documentation/x86/x86_64/machinecheck.rst at the Kernel tree.
>
> EDAC - Error Detection And Correction
> *************************************
> diff --git a/Documentation/devicetree/bindings/net/fsl-enetc.txt
> b/Documentation/devicetree/bindings/net/fsl-enetc.txt index
> c812e25ae90f..25fc687419db 100644
> --- a/Documentation/devicetree/bindings/net/fsl-enetc.txt
> +++ b/Documentation/devicetree/bindings/net/fsl-enetc.txt
> @@ -16,8 +16,8 @@ Required properties:
> In this case, the ENETC node should include a "mdio" sub-node
> that in turn should contain the "ethernet-phy" node describing the
> external phy. Below properties are required, their bindings
> -already defined in ethernet.txt or phy.txt, under
> -Documentation/devicetree/bindings/net/*.
> +already defined in Documentation/devicetree/bindings/net/ethernet.txt or
> +Documentation/devicetree/bindings/net/phy.txt.
>
> Required:
>
> @@ -51,8 +51,7 @@ Example:
> connection:
>
> In this case, the ENETC port node defines a fixed link connection,
> -as specified by "fixed-link.txt", under
> -Documentation/devicetree/bindings/net/*.
> +as specified by Documentation/devicetree/bindings/net/fixed-link.txt.
>
> Required:
>
> diff --git a/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
> b/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt index
> 12b18f82d441..efa2c8b9b85a 100644
> --- a/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
> @@ -3,7 +3,7 @@ Amlogic Meson AXG DWC PCIE SoC controller
> Amlogic Meson PCIe host controller is based on the Synopsys DesignWare PCI
> core. It shares common functions with the PCIe DesignWare core driver and
> inherits common properties defined in
> -Documentation/devicetree/bindings/pci/designware-pci.txt.
> +Documentation/devicetree/bindings/pci/designware-pcie.txt.
>
> Additional properties are described here:
>
> diff --git
> a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
> b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt index
> 7ef2dbe48e8a..14d2eee96b3d 100644
> --- a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
> +++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
> @@ -97,7 +97,7 @@ Second Level Nodes - Regulators
> sent for this regulator including those which are
for a
> strictly lower power state.
>
> -Other properties defined in Documentation/devicetree/bindings/regulator.txt
> +Other properties defined in
> Documentation/devicetree/bindings/regulator/regulator.txt may also be used.
> regulator-initial-mode and regulator-allowed-modes may be specified for
> VRM regulators using mode values from
> include/dt-bindings/regulator/qcom,rpmh-regulator.h.
> regulator-allow-bypass diff --git
> a/Documentation/devicetree/booting-without-of.txt
> b/Documentation/devicetree/booting-without-of.txt index
> e86bd2f64117..60f8640f2b2f 100644
> --- a/Documentation/devicetree/booting-without-of.txt
> +++ b/Documentation/devicetree/booting-without-of.txt
> @@ -277,7 +277,7 @@ it with special cases.
> the decompressor (the real mode entry point goes to the same 32bit
> entry point once it switched into protected mode). That entry point
> supports one calling convention which is documented in
> - Documentation/x86/boot.txt
> + Documentation/x86/boot.rst
> The physical pointer to the device-tree block (defined in chapter II)
> is passed via setup_data which requires at least boot protocol 2.09.
> The type filed is defined as
> diff --git a/Documentation/driver-api/gpio/board.rst
> b/Documentation/driver-api/gpio/board.rst index b37f3f7b8926..ce91518bf9f4
> 100644
> --- a/Documentation/driver-api/gpio/board.rst
> +++ b/Documentation/driver-api/gpio/board.rst
> @@ -101,7 +101,7 @@ with the help of _DSD (Device Specific Data), introduced
> in ACPI 5.1:: }
>
> For more information about the ACPI GPIO bindings see
> -Documentation/acpi/gpio-properties.txt.
> +Documentation/firmware-guide/acpi/gpio-properties.rst.
>
> Platform Data
> -------------
> diff --git a/Documentation/driver-api/gpio/consumer.rst
> b/Documentation/driver-api/gpio/consumer.rst index
> 5e4d8aa68913..fdecb6d711db 100644
> --- a/Documentation/driver-api/gpio/consumer.rst
> +++ b/Documentation/driver-api/gpio/consumer.rst
> @@ -437,7 +437,7 @@ case, it will be handled by the GPIO subsystem
> automatically. However, if the _DSD is not present, the mappings between
> GpioIo()/GpioInt() resources and GPIO connection IDs need to be provided by
> device drivers.
>
> -For details refer to Documentation/acpi/gpio-properties.txt
> +For details refer to Documentation/firmware-guide/acpi/gpio-properties.rst
>
>
> Interacting With the Legacy GPIO Subsystem
> diff --git a/Documentation/firmware-guide/acpi/enumeration.rst
> b/Documentation/firmware-guide/acpi/enumeration.rst index
> 6b32b7be8c85..65f5bb5725ac 100644
> --- a/Documentation/firmware-guide/acpi/enumeration.rst
> +++ b/Documentation/firmware-guide/acpi/enumeration.rst
> @@ -339,7 +339,7 @@ a code like this::
> There are also devm_* versions of these functions which release the
> descriptors once the device is released.
>
> -See Documentation/acpi/gpio-properties.txt for more information about the
> +See Documentation/firmware-guide/acpi/gpio-properties.rst for more
> information about the _DSD binding related to GPIOs.
>
> MFD devices
> diff --git a/Documentation/firmware-guide/acpi/method-tracing.rst
> b/Documentation/firmware-guide/acpi/method-tracing.rst index
> d0b077b73f5f..0aa7e2c5d32a 100644
> --- a/Documentation/firmware-guide/acpi/method-tracing.rst
> +++ b/Documentation/firmware-guide/acpi/method-tracing.rst
> @@ -68,7 +68,7 @@ c. Filter out the debug layer/level matched logs when the
> specified
>
> Where:
> 0xXXXXXXXX/0xYYYYYYYY
> - Refer to Documentation/acpi/debug.txt for possible debug layer/level
> + Refer to Documentation/firmware-guide/acpi/debug.rst for possible
> debug layer/level masking values.
> \PPPP.AAAA.TTTT.HHHH
> Full path of a control method that can be found in the ACPI namespace.
> diff --git a/Documentation/i2c/instantiating-devices
> b/Documentation/i2c/instantiating-devices index 0d85ac1935b7..5a3e2f331e8c
> 100644
> --- a/Documentation/i2c/instantiating-devices
> +++ b/Documentation/i2c/instantiating-devices
> @@ -85,7 +85,7 @@ Method 1c: Declare the I2C devices via ACPI
> -------------------------------------------
>
> ACPI can also describe I2C devices. There is special documentation for this
> -which is currently located at Documentation/acpi/enumeration.txt. +which
> is currently located at Documentation/firmware-guide/acpi/enumeration.rst.
>
>
> Method 2: Instantiate the devices explicitly
> diff --git a/Documentation/sysctl/kernel.txt
> b/Documentation/sysctl/kernel.txt index f0c86fbb3b48..92f7f34b021a 100644
> --- a/Documentation/sysctl/kernel.txt
> +++ b/Documentation/sysctl/kernel.txt
> @@ -155,7 +155,7 @@ is 0x15 and the full version number is 0x234, this file
> will contain the value 340 = 0x154.
>
> See the type_of_loader and ext_loader_type fields in
> -Documentation/x86/boot.txt for additional information.
> +Documentation/x86/boot.rst for additional information.
>
> ==============================================================
>
> @@ -167,7 +167,7 @@ The complete bootloader version number. In the example
> above, this file will contain the value 564 = 0x234.
>
> See the type_of_loader and ext_loader_ver fields in
> -Documentation/x86/boot.txt for additional information.
> +Documentation/x86/boot.rst for additional information.
>
> ==============================================================
>
> diff --git a/Documentation/translations/it_IT/process/4.Coding.rst
> b/Documentation/translations/it_IT/process/4.Coding.rst index
> c05b89e616dd..1d23e951491f 100644
> --- a/Documentation/translations/it_IT/process/4.Coding.rst
> +++ b/Documentation/translations/it_IT/process/4.Coding.rst
> @@ -370,7 +370,7 @@ con cosa stanno lavorando. Consultate:
> Documentation/ABI/README per avere una descrizione di come questi documenti
> devono essere impostati e quali informazioni devono essere fornite.
>
> -Il file
> :ref:`Documentation/translations/it_IT/admin-guide/kernel-parameters.rst
> <kernelparameters>` +Il file
> :ref:`Documentation/admin-guide/kernel-parameters.rst <kernelparameters>`
> descrive tutti i parametri di avvio del kernel. Ogni patch che aggiunga
> nuovi parametri dovrebbe aggiungere nuove voci a questo file.
ACK
I will provide later a patch that adds that translation (just the .rst file)
> diff --git a/Documentation/translations/it_IT/process/howto.rst
> b/Documentation/translations/it_IT/process/howto.rst index
> 9903ac7c566b..44e6077730e8 100644
> --- a/Documentation/translations/it_IT/process/howto.rst
> +++ b/Documentation/translations/it_IT/process/howto.rst
> @@ -131,7 +131,7 @@ Di seguito una lista di file che sono presenti nei
> sorgente del kernel e che "Linux kernel patch submission format"
> http://linux.yyz.us/patch-format.html
>
> - :ref:`Documentation/process/translations/it_IT/stable-api-nonsense.rst
> <it_stable_api_nonsense>` +
> :ref:`Documentation/translations/it_IT/process/stable-api-nonsense.rst
> <it_stable_api_nonsense>`
ACK
> Questo file descrive la motivazioni sottostanti la conscia decisione di
> non avere un API stabile all'interno del kernel, incluso cose come: diff
> --git a/Documentation/translations/it_IT/process/stable-kernel-rules.rst
> b/Documentation/translations/it_IT/process/stable-kernel-rules.rst index
> 48e88e5ad2c5..4f206cee31a7 100644
> --- a/Documentation/translations/it_IT/process/stable-kernel-rules.rst
> +++ b/Documentation/translations/it_IT/process/stable-kernel-rules.rst
> @@ -33,7 +33,7 @@ Regole sul tipo di patch che vengono o non vengono
> accettate nei sorgenti - Non deve includere alcuna correzione "banale"
> (correzioni grammaticali, pulizia dagli spazi bianchi, eccetera).
> - Deve rispettare le regole scritte in
> - :ref:`Documentation/translation/it_IT/process/submitting-patches.rst
> <it_submittingpatches>` +
> :ref:`Documentation/translations/it_IT/process/submitting-patches.rst
> <it_submittingpatches>` - Questa patch o una equivalente deve esistere già
> nei sorgenti principali di Linux
ACK
>
> @@ -43,7 +43,7 @@ Procedura per sottomettere patch per i sorgenti -stable
>
> - Se la patch contiene modifiche a dei file nelle cartelle net/ o
> drivers/net, allora seguite le linee guida descritte in
> - :ref:`Documentation/translation/it_IT/networking/netdev-FAQ.rst
> <it_netdev-FAQ>`; +
> :ref:`Documentation/translations/it_IT/networking/netdev-FAQ.rst
> <it_netdev-FAQ>`; ma solo dopo aver verificato al seguente indirizzo che la
> patch non sia già in coda:
>
ACK
Thanks for the fixes, out of curiosity. How did you spot those mistakes?
> https://patchwork.ozlabs.org/bundle/davem/stable/?series=&submitter=&state=
> *&q=&archive= diff --git
> a/Documentation/translations/zh_CN/process/4.Coding.rst
> b/Documentation/translations/zh_CN/process/4.Coding.rst index
> 5301e9d55255..8bb777941394 100644
> --- a/Documentation/translations/zh_CN/process/4.Coding.rst
> +++ b/Documentation/translations/zh_CN/process/4.Coding.rst
> @@ -241,7 +241,7 @@ scripts/coccinelle目录下已经打包了相当多的内核“语义补丁”
>
> 任何添加新用户空间界面的代码（包括新的sysfs或/proc文件）都应该包含该界面的
> 文档，该文档使用户空间开发人员能够知道他们在使用什么。请参阅
> -Documentation/abi/readme，了解如何格式化此文档以及需要提供哪些信息。
> +Documentation/ABI/README，了解如何格式化此文档以及需要提供哪些信息。
>
> 文件 :ref:`Documentation/admin-guide/kernel-parameters.rst
> <kernelparameters>` 描述了内核的所有引导时间参数。任何添加新参数的补丁都应该向该文件添加适当的
> diff --git a/Documentation/x86/x86_64/5level-paging.rst
> b/Documentation/x86/x86_64/5level-paging.rst index
> ab88a4514163..44856417e6a5 100644
> --- a/Documentation/x86/x86_64/5level-paging.rst
> +++ b/Documentation/x86/x86_64/5level-paging.rst
> @@ -20,7 +20,7 @@ physical address space. This "ought to be enough for
> anybody" ©. QEMU 2.9 and later support 5-level paging.
>
> Virtual memory layout for 5-level paging is described in
> -Documentation/x86/x86_64/mm.txt
> +Documentation/x86/x86_64/mm.rst
>
>
> Enabling 5-level paging
> diff --git a/Documentation/x86/x86_64/boot-options.rst
> b/Documentation/x86/x86_64/boot-options.rst index
> 2f69836b8445..6a4285a3c7a4 100644
> --- a/Documentation/x86/x86_64/boot-options.rst
> +++ b/Documentation/x86/x86_64/boot-options.rst
> @@ -9,7 +9,7 @@ only the AMD64 specific ones are listed here.
>
> Machine check
> =============
> -Please see Documentation/x86/x86_64/machinecheck for sysfs runtime
> tunables. +Please see Documentation/x86/x86_64/machinecheck.rst for sysfs
> runtime tunables.
>
> mce=off
> Disable machine check
> @@ -89,7 +89,7 @@ APICs
> Don't use the local APIC (alias for i386 compatibility)
>
> pirq=...
> - See Documentation/x86/i386/IO-APIC.txt
> + See Documentation/x86/i386/IO-APIC.rst
>
> noapictimer
> Don't set up the APIC timer
> diff --git a/Documentation/x86/x86_64/fake-numa-for-cpusets.rst
> b/Documentation/x86/x86_64/fake-numa-for-cpusets.rst index
> 74fbb78b3c67..04df57b9aa3f 100644
> --- a/Documentation/x86/x86_64/fake-numa-for-cpusets.rst
> +++ b/Documentation/x86/x86_64/fake-numa-for-cpusets.rst
> @@ -18,7 +18,7 @@ For more information on the features of cpusets, see
> Documentation/cgroup-v1/cpusets.txt.
> There are a number of different configurations you can use for your needs.
> For more information on the numa=fake command line option and its various
> ways of -configuring fake nodes, see
> Documentation/x86/x86_64/boot-options.txt. +configuring fake nodes, see
> Documentation/x86/x86_64/boot-options.rst.
>
> For the purposes of this introduction, we'll assume a very primitive NUMA
> emulation setup of "numa=fake=4*512,". This will split our system memory
> into diff --git a/MAINTAINERS b/MAINTAINERS
> index 0c84bf76d165..47aa4f6defb9 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3874,7 +3874,7 @@
> F: Documentation/devicetree/bindings/hwmon/cirrus,lochnagar.txt
> F: Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.txt
> F: Documentation/devicetree/bindings/regulator/cirrus,lochnagar.txt
> F: Documentation/devicetree/bindings/sound/cirrus,lochnagar.txt
> -F: Documentation/hwmon/lochnagar
> +F: Documentation/hwmon/lochnagar.rst
>
> CISCO FCOE HBA DRIVER
> M: Satish Kharat <satishkh@cisco.com>
> @@ -11272,7 +11272,7 @@ NXP FXAS21002C DRIVER
> M: Rui Miguel Silva <rmfrfs@gmail.com>
> L: linux-iio@vger.kernel.org
> S: Maintained
> -F: Documentation/devicetree/bindings/iio/gyroscope/fxas21002c.txt
> +F: Documentation/devicetree/bindings/iio/gyroscope/nxp,fxas21002c.txt
> F: drivers/iio/gyro/fxas21002c_core.c
> F: drivers/iio/gyro/fxas21002c.h
> F: drivers/iio/gyro/fxas21002c_i2c.c
> @@ -13043,7 +13043,7 @@ M: Niklas Cassel <niklas.cassel@linaro.org>
> L: netdev@vger.kernel.org
> S: Maintained
> F: drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> -F: Documentation/devicetree/bindings/net/qcom,dwmac.txt
> +F: Documentation/devicetree/bindings/net/qcom,ethqos.txt
>
> QUALCOMM GENERIC INTERFACE I2C DRIVER
> M: Alok Chauhan <alokc@codeaurora.org>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 8869742a85df..0f220264cc23 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1263,7 +1263,7 @@ config SMP
> uniprocessor machines. On a uniprocessor machine, the kernel
> will run faster if you say N here.
>
> - See also <file:Documentation/x86/i386/IO-APIC.txt>,
> + See also <file:Documentation/x86/i386/IO-APIC.rst>,
> <file:Documentation/lockup-watchdogs.txt> and the SMP-HOWTO
available at
> <http://tldp.org/HOWTO/SMP-HOWTO.html>.
>
> diff --git a/arch/arm64/kernel/kexec_image.c
> b/arch/arm64/kernel/kexec_image.c index 07bf740bea91..31cc2f423aa8 100644
> --- a/arch/arm64/kernel/kexec_image.c
> +++ b/arch/arm64/kernel/kexec_image.c
> @@ -53,7 +53,7 @@ static void *image_load(struct kimage *image,
>
> /*
> * We require a kernel with an unambiguous Image header. Per
> - * Documentation/booting.txt, this is the case when image_size
> + * Documentation/arm64/booting.txt, this is the case when
image_size
> * is non-zero (practically speaking, since v3.17).
> */
> h = (struct arm64_image_header *)kernel;
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 8c1c636308c8..e868d2bd48b8 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -898,7 +898,7 @@ config PPC_MEM_KEYS
> page-based protections, but without requiring modification of
the
> page tables when an application changes protection domains.
>
> - For details, see Documentation/vm/protection-keys.rst
> + For details, see Documentation/x86/protection-keys.rst
>
> If unsure, say y.
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 2bbbd4d1ba31..78fdf2dd71d1 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -395,7 +395,7 @@ config SMP
> Y to "Enhanced Real Time Clock Support", below. The "Advanced
Power
> Management" code will be disabled if you say Y here.
>
> - See also <file:Documentation/x86/i386/IO-APIC.txt>,
> + See also <file:Documentation/x86/i386/IO-APIC.rst>,
> <file:Documentation/lockup-watchdogs.txt> and the SMP-HOWTO
available at
> <http://www.tldp.org/docs.html#howto>.
>
> @@ -1290,7 +1290,7 @@ config MICROCODE
> the Linux kernel.
>
> The preferred method to load microcode from a detached initrd is
> described - in Documentation/x86/microcode.txt. For that you
need to
> enable + in Documentation/x86/microcode.rst. For that you need to enable
> CONFIG_BLK_DEV_INITRD in order for the loader to be able to scan the initrd
> for microcode blobs.
>
> @@ -1329,7 +1329,7 @@ config MICROCODE_OLD_INTERFACE
> It is inadequate because it runs too late to be able to properly
> load microcode on a machine and it needs special tools. Instead,
you
> should've switched to the early loading method with the initrd
or
> - builtin microcode by now: Documentation/x86/microcode.txt
> + builtin microcode by now: Documentation/x86/microcode.rst
>
> config X86_MSR
> tristate "/dev/cpu/*/msr - Model-specific register support"
> @@ -1478,7 +1478,7 @@ config X86_5LEVEL
> A kernel with the option enabled can be booted on machines that
> support 4- or 5-level paging.
>
> - See Documentation/x86/x86_64/5level-paging.txt for more
> + See Documentation/x86/x86_64/5level-paging.rst for more
> information.
>
> Say N if unsure.
> @@ -1626,7 +1626,7 @@ config ARCH_MEMORY_PROBE
> depends on X86_64 && MEMORY_HOTPLUG
> help
> This option enables a sysfs memory/probe interface for testing.
> - See Documentation/memory-hotplug.txt for more information.
> + See Documentation/admin-guide/mm/memory-hotplug.rst for more
> information. If you are unsure how to answer this question, answer N.
>
> config ARCH_PROC_KCORE_TEXT
> @@ -1783,7 +1783,7 @@ config MTRR
> You can safely say Y even if your machine doesn't have MTRRs,
you'll
> just add about 9 KB to your kernel.
>
> - See <file:Documentation/x86/mtrr.txt> for more information.
> + See <file:Documentation/x86/mtrr.rst> for more information.
>
> config MTRR_SANITIZER
> def_bool y
> @@ -1895,7 +1895,7 @@ config X86_INTEL_MPX
> process and adds some branches to paths used during
> exec() and munmap().
>
> - For details, see Documentation/x86/intel_mpx.txt
> + For details, see Documentation/x86/intel_mpx.rst
>
> If unsure, say N.
>
> @@ -1911,7 +1911,7 @@ config X86_INTEL_MEMORY_PROTECTION_KEYS
> page-based protections, but without requiring modification of
the
> page tables when an application changes protection domains.
>
> - For details, see Documentation/x86/protection-keys.txt
> + For details, see Documentation/x86/protection-keys.rst
>
> If unsure, say y.
>
> diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
> index f730680dc818..59f598543203 100644
> --- a/arch/x86/Kconfig.debug
> +++ b/arch/x86/Kconfig.debug
> @@ -156,7 +156,7 @@ config IOMMU_DEBUG
> code. When you use it make sure you have a big enough
> IOMMU/AGP aperture. Most of the options enabled by this can
> be set more finegrained using the iommu= command line
> - options. See Documentation/x86/x86_64/boot-options.txt for more
> + options. See Documentation/x86/x86_64/boot-options.rst for more
> details.
>
> config IOMMU_LEAK
> diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
> index 850b8762e889..90d791ca1a95 100644
> --- a/arch/x86/boot/header.S
> +++ b/arch/x86/boot/header.S
> @@ -313,7 +313,7 @@ start_sys_seg: .word SYSSEG
# obsolete and meaningless,
> but just
>
> type_of_loader: .byte 0 # 0 means ancient
bootloader, newer
> # bootloaders know
to change this.
> - # See
Documentation/x86/boot.txt for
> + # See
Documentation/x86/boot.rst for
> # assigned ids
>
> # flags, unused bits must be zero (RFU) bit within loadflags
> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
> index 11aa3b2afa4d..33f9fc38d014 100644
> --- a/arch/x86/entry/entry_64.S
> +++ b/arch/x86/entry/entry_64.S
> @@ -8,7 +8,7 @@
> *
> * entry.S contains the system-call and fault low-level handling routines.
> *
> - * Some of this is documented in Documentation/x86/entry_64.txt
> + * Some of this is documented in Documentation/x86/entry_64.rst
> *
> * A note on terminology:
> * - iret frame: Architecture defined interrupt frame from SS to RIP
> diff --git a/arch/x86/include/asm/bootparam_utils.h
> b/arch/x86/include/asm/bootparam_utils.h index f6f6ef436599..101eb944f13c
> 100644
> --- a/arch/x86/include/asm/bootparam_utils.h
> +++ b/arch/x86/include/asm/bootparam_utils.h
> @@ -24,7 +24,7 @@ static void sanitize_boot_params(struct boot_params
> *boot_params) * IMPORTANT NOTE TO BOOTLOADER AUTHORS: do not simply clear
> * this field. The purpose of this field is to guarantee
> * compliance with the x86 boot spec located in
> - * Documentation/x86/boot.txt . That spec says that the
> + * Documentation/x86/boot.rst . That spec says that the
> * *whole* structure should be cleared, after which only the
> * portion defined by struct setup_header (boot_params->hdr)
> * should be copied in.
> diff --git a/arch/x86/include/asm/page_64_types.h
> b/arch/x86/include/asm/page_64_types.h index 793c14c372cb..288b065955b7
> 100644
> --- a/arch/x86/include/asm/page_64_types.h
> +++ b/arch/x86/include/asm/page_64_types.h
> @@ -48,7 +48,7 @@
>
> #define __START_KERNEL_map _AC(0xffffffff80000000, UL)
>
> -/* See Documentation/x86/x86_64/mm.txt for a description of the memory map.
> */ +/* See Documentation/x86/x86_64/mm.rst for a description of the memory
> map. */
>
> #define __PHYSICAL_MASK_SHIFT 52
>
> diff --git a/arch/x86/include/asm/pgtable_64_types.h
> b/arch/x86/include/asm/pgtable_64_types.h index 88bca456da99..52e5f5f2240d
> 100644
> --- a/arch/x86/include/asm/pgtable_64_types.h
> +++ b/arch/x86/include/asm/pgtable_64_types.h
> @@ -103,7 +103,7 @@ extern unsigned int ptrs_per_p4d;
> #define PGDIR_MASK (~(PGDIR_SIZE - 1))
>
> /*
> - * See Documentation/x86/x86_64/mm.txt for a description of the memory map.
> + * See Documentation/x86/x86_64/mm.rst for a description of the memory
> map. *
> * Be very careful vs. KASLR when changing anything here. The KASLR address
> * range must not overlap with anything except the KASAN shadow area, which
> diff --git a/arch/x86/kernel/cpu/microcode/amd.c
> b/arch/x86/kernel/cpu/microcode/amd.c index e1f3ba19ba54..06d4e67f31ab
> 100644
> --- a/arch/x86/kernel/cpu/microcode/amd.c
> +++ b/arch/x86/kernel/cpu/microcode/amd.c
> @@ -61,7 +61,7 @@ static u8 amd_ucode_patch[PATCH_MAX_SIZE];
>
> /*
> * Microcode patch container file is prepended to the initrd in cpio
> - * format. See Documentation/x86/microcode.txt
> + * format. See Documentation/x86/microcode.rst
> */
> static const char
> ucode_path[] __maybe_unused = "kernel/x86/microcode/AuthenticAMD.bin";
> diff --git a/arch/x86/kernel/kexec-bzimage64.c
> b/arch/x86/kernel/kexec-bzimage64.c index 22f60dd26460..b07e7069b09e 100644
> --- a/arch/x86/kernel/kexec-bzimage64.c
> +++ b/arch/x86/kernel/kexec-bzimage64.c
> @@ -416,7 +416,7 @@ static void *bzImage64_load(struct kimage *image, char
> *kernel, efi_map_offset = params_cmdline_sz;
> efi_setup_data_offset = efi_map_offset + ALIGN(efi_map_sz, 16);
>
> - /* Copy setup header onto bootparams. Documentation/x86/boot.txt
*/
> + /* Copy setup header onto bootparams. Documentation/x86/boot.rst */
> setup_header_size = 0x0202 + kernel[0x0201] - setup_hdr_offset;
>
> /* Is there a limit on setup header size? */
> diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
> index dcd272dbd0a9..f62b498b18fb 100644
> --- a/arch/x86/kernel/pci-dma.c
> +++ b/arch/x86/kernel/pci-dma.c
> @@ -70,7 +70,7 @@ void __init pci_iommu_alloc(void)
> }
>
> /*
> - * See <Documentation/x86/x86_64/boot-options.txt> for the iommu kernel
> + * See <Documentation/x86/x86_64/boot-options.rst> for the iommu kernel
> * parameter documentation.
> */
> static __init int iommu_setup(char *p)
> diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
> index 7f61431c75fb..400c1ba033aa 100644
> --- a/arch/x86/mm/tlb.c
> +++ b/arch/x86/mm/tlb.c
> @@ -711,7 +711,7 @@ void native_flush_tlb_others(const struct cpumask
> *cpumask, }
>
> /*
> - * See Documentation/x86/tlb.txt for details. We choose 33
> + * See Documentation/x86/tlb.rst for details. We choose 33
> * because it is large enough to cover the vast majority (at
> * least 95%) of allocations, and is small enough that we are
> * confident it will not cause too much overhead. Each single
> diff --git a/arch/x86/platform/pvh/enlighten.c
> b/arch/x86/platform/pvh/enlighten.c index 1861a2ba0f2b..c0a502f7e3a7 100644
> --- a/arch/x86/platform/pvh/enlighten.c
> +++ b/arch/x86/platform/pvh/enlighten.c
> @@ -86,7 +86,7 @@ static void __init init_pvh_bootparams(bool xen_guest)
> }
>
> /*
> - * See Documentation/x86/boot.txt.
> + * See Documentation/x86/boot.rst.
> *
> * Version 2.12 supports Xen entry point but we will use default
x86/PC
> * environment (i.e. hardware_subarch 0).
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 283ee94224c6..2438f37f2ca1 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -333,7 +333,7 @@ config ACPI_CUSTOM_DSDT_FILE
> depends on !STANDALONE
> help
> This option supports a custom DSDT by linking it into the
kernel.
> - See Documentation/acpi/dsdt-override.txt
> + See Documentation/admin-guide/acpi/dsdt-override.rst
>
> Enter the full path name to the file which includes the AmlCode
> or dsdt_aml_code declaration.
> @@ -355,7 +355,7 @@ config ACPI_TABLE_UPGRADE
> This option provides functionality to upgrade arbitrary ACPI
tables
> via initrd. No functional change if no ACPI tables are passed
via
> initrd, therefore it's safe to say Y.
> - See Documentation/acpi/initrd_table_override.txt for details
> + See Documentation/admin-guide/acpi/initrd_table_override.rst for
details
>
> config ACPI_TABLE_OVERRIDE_VIA_BUILTIN_INITRD
> bool "Override ACPI tables from built-in initrd"
> @@ -365,7 +365,7 @@ config ACPI_TABLE_OVERRIDE_VIA_BUILTIN_INITRD
> This option provides functionality to override arbitrary ACPI
tables
> from built-in uncompressed initrd.
>
> - See Documentation/acpi/initrd_table_override.txt for details
> + See Documentation/admin-guide/acpi/initrd_table_override.rst for
details
>
> config ACPI_DEBUG
> bool "Debug Statements"
> @@ -374,7 +374,7 @@ config ACPI_DEBUG
> output and increases the kernel size by around 50K.
>
> Use the acpi.debug_layer and acpi.debug_level kernel command-
line
> - parameters documented in Documentation/acpi/debug.txt and
> + parameters documented in Documentation/firmware-guide/acpi/
debug.rst and
> Documentation/admin-guide/kernel-parameters.rst to control the type and
> amount of debug output.
>
> @@ -445,7 +445,7 @@ config ACPI_CUSTOM_METHOD
> help
> This debug facility allows ACPI AML methods to be inserted and/
or
> replaced without rebooting the system. For details refer to:
> - Documentation/acpi/method-customizing.txt.
> + Documentation/firmware-guide/acpi/method-customizing.rst.
>
> NOTE: This option is security sensitive, because it allows
arbitrary
> kernel memory to be written to by root (uid=0) users, allowing
them
> diff --git a/drivers/net/ethernet/faraday/ftgmac100.c
> b/drivers/net/ethernet/faraday/ftgmac100.c index b17b79e612a3..ac6280ad43a1
> 100644
> --- a/drivers/net/ethernet/faraday/ftgmac100.c
> +++ b/drivers/net/ethernet/faraday/ftgmac100.c
> @@ -1075,7 +1075,7 @@ static int ftgmac100_mii_probe(struct ftgmac100 *priv,
> phy_interface_t intf) }
>
> /* Indicate that we support PAUSE frames (see comment in
> - * Documentation/networking/phy.txt)
> + * Documentation/networking/phy.rst)
> */
> phy_support_asym_pause(phydev);
>
> diff --git a/drivers/staging/fieldbus/Documentation/fieldbus_dev.txt
> b/drivers/staging/fieldbus/Documentation/fieldbus_dev.txt index
> 56af3f650fa3..89fb8e14676f 100644
> --- a/drivers/staging/fieldbus/Documentation/fieldbus_dev.txt
> +++ b/drivers/staging/fieldbus/Documentation/fieldbus_dev.txt
> @@ -54,8 +54,8 @@ a limited few common behaviours and properties. This
> allows us to define a simple interface consisting of a character device and
> a set of sysfs files:
>
> See:
> -Documentation/ABI/testing/sysfs-class-fieldbus-dev
> -Documentation/ABI/testing/fieldbus-dev-cdev
> +drivers/staging/fieldbus/Documentation/ABI/sysfs-class-fieldbus-dev
> +drivers/staging/fieldbus/Documentation/ABI/fieldbus-dev-cdev
>
> Note that this simple interface does not provide a way to modify adapter
> configuration settings. It is therefore useful only for adapters that get
> their diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index 1e3ed41ae1f3..69938dbae2d0 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -1694,7 +1694,7 @@ EXPORT_SYMBOL_GPL(vhost_dev_ioctl);
>
> /* TODO: This is really inefficient. We need something like get_user()
> * (instruction directly accesses the data, with an exception table entry
> - * returning -EFAULT). See Documentation/x86/exception-tables.txt.
> + * returning -EFAULT). See Documentation/x86/exception-tables.rst.
> */
> static int set_bit_to_user(int nr, void __user *addr)
> {
> diff --git a/include/acpi/acpi_drivers.h b/include/acpi/acpi_drivers.h
> index de1804aeaf69..98e3db7a89cd 100644
> --- a/include/acpi/acpi_drivers.h
> +++ b/include/acpi/acpi_drivers.h
> @@ -25,7 +25,7 @@
> #define ACPI_MAX_STRING 80
>
> /*
> - * Please update drivers/acpi/debug.c and Documentation/acpi/debug.txt
> + * Please update drivers/acpi/debug.c and
> Documentation/firmware-guide/acpi/debug.rst * if you add to this list.
> */
> #define ACPI_BUS_COMPONENT 0x00010000
> diff --git a/include/linux/fs_context.h b/include/linux/fs_context.h
> index 1f966670c8dc..623eb58560b9 100644
> --- a/include/linux/fs_context.h
> +++ b/include/linux/fs_context.h
> @@ -85,7 +85,7 @@ struct fs_parameter {
> * Superblock creation fills in ->root whereas reconfiguration begins with
> this * already set.
> *
> - * See Documentation/filesystems/mounting.txt
> + * See Documentation/filesystems/mount_api.txt
> */
> struct fs_context {
> const struct fs_context_operations *ops;
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index 47f58cfb6a19..df1318d85f7d 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -77,7 +77,7 @@
> * state. This is called immediately after commit_creds().
> *
> * Security hooks for mount using fs_context.
> - * [See also Documentation/filesystems/mounting.txt]
> + * [See also Documentation/filesystems/mount_api.txt]
> *
> * @fs_context_dup:
> * Allocate and attach a security structure to sc->security. This
pointer
> diff --git a/mm/Kconfig b/mm/Kconfig
> index ee8d1f311858..6e5fb81bde4b 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -165,7 +165,7 @@ config MEMORY_HOTPLUG_DEFAULT_ONLINE
> onlining policy (/sys/devices/system/memory/auto_online_blocks)
which
> determines what happens to newly added memory regions. Policy
setting
> can always be changed at runtime.
> - See Documentation/memory-hotplug.txt for more information.
> + See Documentation/admin-guide/mm/memory-hotplug.rst for more
> information.
>
> Say Y here if you want all hot-plugged memory blocks to appear
in
> 'online' state by default.
> diff --git a/security/Kconfig b/security/Kconfig
> index aeac3676dd4d..6d75ed71970c 100644
> --- a/security/Kconfig
> +++ b/security/Kconfig
> @@ -62,7 +62,7 @@ config PAGE_TABLE_ISOLATION
> ensuring that the majority of kernel addresses are not mapped
> into userspace.
>
> - See Documentation/x86/pti.txt for more details.
> + See Documentation/x86/pti.rst for more details.
>
> config SECURITY_INFINIBAND
> bool "Infiniband Security Hooks"
> diff --git a/tools/include/linux/err.h b/tools/include/linux/err.h
> index 2f5a12b88a86..25f2bb3a991d 100644
> --- a/tools/include/linux/err.h
> +++ b/tools/include/linux/err.h
> @@ -20,7 +20,7 @@
> * Userspace note:
> * The same principle works for userspace, because 'error' pointers
> * fall down to the unused hole far from user space, as described
> - * in Documentation/x86/x86_64/mm.txt for x86_64 arch:
> + * in Documentation/x86/x86_64/mm.rst for x86_64 arch:
> *
> * 0000000000000000 - 00007fffffffffff (=47 bits) user space, different per
> mm hole caused by [48:63] sign extension * ffffffffffe00000 -
> ffffffffffffffff (=2 MB) unused hole
> diff --git a/tools/objtool/Documentation/stack-validation.txt
> b/tools/objtool/Documentation/stack-validation.txt index
> 4dd11a554b9b..de094670050b 100644
> --- a/tools/objtool/Documentation/stack-validation.txt
> +++ b/tools/objtool/Documentation/stack-validation.txt
> @@ -21,7 +21,7 @@ instructions). Similarly, it knows how to follow switch
> statements, for which gcc sometimes uses jump tables.
>
> (Objtool also has an 'orc generate' subcommand which generates debuginfo
> -for the ORC unwinder. See Documentation/x86/orc-unwinder.txt in the
> +for the ORC unwinder. See Documentation/x86/orc-unwinder.rst in the
> kernel tree for more details.)
>
>
> @@ -101,7 +101,7 @@ b) ORC (Oops Rewind Capability) unwind table generation
> band. So it doesn't affect runtime performance and it can be
> reliable even when interrupts or exceptions are involved.
>
> - For more details, see Documentation/x86/orc-unwinder.txt.
> + For more details, see Documentation/x86/orc-unwinder.rst.
>
> c) Higher live patching compatibility rate
>
> diff --git a/tools/testing/selftests/x86/protection_keys.c
> b/tools/testing/selftests/x86/protection_keys.c index
> 5d546dcdbc80..798a5ddeee55 100644
> --- a/tools/testing/selftests/x86/protection_keys.c
> +++ b/tools/testing/selftests/x86/protection_keys.c
> @@ -1,6 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0
> /*
> - * Tests x86 Memory Protection Keys (see
> Documentation/x86/protection-keys.txt) + * Tests x86 Memory Protection Keys
> (see Documentation/x86/protection-keys.rst) *
> * There are examples in here of:
> * * how to set protection keys on memory
^ permalink raw reply
* [RFC 1/2] security: Support early LSMs
From: Matthew Garrett @ 2019-05-21 22:40 UTC (permalink / raw)
To: jmorris
Cc: linux-security-module, linux-kernel, Matthew Garrett,
Matthew Garrett
In-Reply-To: <20190521224013.3782-1-matthewgarrett@google.com>
The lockdown module is intended to allow for kernels to be locked down
early in boot - sufficiently early that we don't have the ability to
kmalloc() yet. Add support for early initialisation of some LSMs, and
then add them to the list of names when we do full initialisation later.
Signed-off-by: Matthew Garrett <mjg59@google.com>
---
include/asm-generic/vmlinux.lds.h | 8 +++++-
include/linux/lsm_hooks.h | 6 ++++
include/linux/security.h | 1 +
init/main.c | 1 +
security/security.c | 48 +++++++++++++++++++++++++------
5 files changed, 54 insertions(+), 10 deletions(-)
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 3d7a6a9c2370..e9761ed1f5b3 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -208,8 +208,13 @@
__start_lsm_info = .; \
KEEP(*(.lsm_info.init)) \
__end_lsm_info = .;
+#define EARLY_LSM_TABLE() . = ALIGN(8); \
+ __start_early_lsm_info = .; \
+ KEEP(*(.early_lsm_info.init)) \
+ __end_early_lsm_info = .;
#else
#define LSM_TABLE()
+#define EARLY_LSM_TABLE()
#endif
#define ___OF_TABLE(cfg, name) _OF_TABLE_##cfg(name)
@@ -610,7 +615,8 @@
ACPI_PROBE_TABLE(irqchip) \
ACPI_PROBE_TABLE(timer) \
EARLYCON_TABLE() \
- LSM_TABLE()
+ LSM_TABLE() \
+ EARLY_LSM_TABLE()
#define INIT_TEXT \
*(.init.text .init.text.*) \
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 22fc786d723a..1a841d134e05 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2074,12 +2074,18 @@ struct lsm_info {
};
extern struct lsm_info __start_lsm_info[], __end_lsm_info[];
+extern struct lsm_info __start_early_lsm_info[], __end_early_lsm_info[];
#define DEFINE_LSM(lsm) \
static struct lsm_info __lsm_##lsm \
__used __section(.lsm_info.init) \
__aligned(sizeof(unsigned long))
+#define DEFINE_EARLY_LSM(lsm) \
+ static struct lsm_info __early_lsm_##lsm \
+ __used __section(.early_lsm_info.init) \
+ __aligned(sizeof(unsigned long))
+
#ifdef CONFIG_SECURITY_SELINUX_DISABLE
/*
* Assuring the safety of deleting a security module is up to
diff --git a/include/linux/security.h b/include/linux/security.h
index 13537a49ae97..f4363a1339a8 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -191,6 +191,7 @@ int unregister_lsm_notifier(struct notifier_block *nb);
/* prototypes */
extern int security_init(void);
+extern int early_security_init(void);
/* Security operations */
int security_binder_set_context_mgr(struct task_struct *mgr);
diff --git a/init/main.c b/init/main.c
index e2e80ca3165a..6bdceaaeddbd 100644
--- a/init/main.c
+++ b/init/main.c
@@ -555,6 +555,7 @@ asmlinkage __visible void __init start_kernel(void)
boot_cpu_init();
page_address_init();
pr_notice("%s", linux_banner);
+ early_security_init();
setup_arch(&command_line);
/*
* Set up the the initial canary and entropy after arch
diff --git a/security/security.c b/security/security.c
index ed9b8cbf21cf..e3a7d4e96541 100644
--- a/security/security.c
+++ b/security/security.c
@@ -37,6 +37,7 @@
/* How many LSMs were built into the kernel? */
#define LSM_COUNT (__end_lsm_info - __start_lsm_info)
+#define EARLY_LSM_COUNT (__end_early_lsm_info - __start_early_lsm_info)
struct security_hook_heads security_hook_heads __lsm_ro_after_init;
static ATOMIC_NOTIFIER_HEAD(lsm_notifier_chain);
@@ -281,6 +282,8 @@ static void __init ordered_lsm_parse(const char *order, const char *origin)
static void __init lsm_early_cred(struct cred *cred);
static void __init lsm_early_task(struct task_struct *task);
+static int lsm_append(const char *new, char **result);
+
static void __init ordered_lsm_init(void)
{
struct lsm_info **lsm;
@@ -327,15 +330,11 @@ static void __init ordered_lsm_init(void)
kfree(ordered_lsms);
}
-/**
- * security_init - initializes the security framework
- *
- * This should be called early in the kernel initialization sequence.
- */
-int __init security_init(void)
+int __init early_security_init(void)
{
int i;
struct hlist_head *list = (struct hlist_head *) &security_hook_heads;
+ struct lsm_info *lsm;
pr_info("Security Framework initializing\n");
@@ -343,6 +342,30 @@ int __init security_init(void)
i++)
INIT_HLIST_HEAD(&list[i]);
+ for (lsm = __start_early_lsm_info; lsm < __end_early_lsm_info; lsm++) {
+ if (!lsm->enabled)
+ lsm->enabled = &lsm_enabled_true;
+ initialize_lsm(lsm);
+ }
+
+ return 0;
+}
+
+/**
+ * security_init - initializes the security framework
+ *
+ * This should be called early in the kernel initialization sequence.
+ */
+int __init security_init(void)
+{
+ struct lsm_info *lsm;
+
+ /* Append the names of the early LSM modules now */
+ for (lsm = __start_early_lsm_info; lsm < __end_early_lsm_info; lsm++) {
+ if (lsm->enabled)
+ lsm_append(lsm->name, &lsm_names);
+ }
+
/* Load LSMs in specified order. */
ordered_lsm_init();
@@ -388,7 +411,7 @@ static bool match_last_lsm(const char *list, const char *lsm)
return !strcmp(last, lsm);
}
-static int lsm_append(char *new, char **result)
+static int lsm_append(const char *new, char **result)
{
char *cp;
@@ -426,8 +449,15 @@ void __init security_add_hooks(struct security_hook_list *hooks, int count,
hooks[i].lsm = lsm;
hlist_add_tail_rcu(&hooks[i].list, hooks[i].head);
}
- if (lsm_append(lsm, &lsm_names) < 0)
- panic("%s - Cannot get early memory.\n", __func__);
+
+ /*
+ * Don't try to append during early_security_init(), we'll come back
+ * and fix this up afterwards.
+ */
+ if (slab_is_available()) {
+ if (lsm_append(lsm, &lsm_names) < 0)
+ panic("%s - Cannot get early memory.\n", __func__);
+ }
}
int call_lsm_notifier(enum lsm_event event, void *data)
--
2.21.0.1020.gf2820cf01a-goog
^ permalink raw reply related
* [RFC 2/2] Add the ability to lock down access to the running kernel image
From: Matthew Garrett @ 2019-05-21 22:40 UTC (permalink / raw)
To: jmorris; +Cc: linux-security-module, linux-kernel, David Howells,
Matthew Garrett
In-Reply-To: <20190521224013.3782-1-matthewgarrett@google.com>
From: David Howells <dhowells@redhat.com>
Provide a single call to allow kernel code to determine whether the system
should be locked down, thereby disallowing various accesses that might
allow the running kernel image to be changed including the loading of
modules that aren't validly signed with a key we recognise, fiddling with
MSR registers and disallowing hibernation.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
---
Documentation/ABI/testing/lockdown | 19 +++
.../admin-guide/kernel-parameters.txt | 9 +
Documentation/admin-guide/lockdown.rst | 60 +++++++
include/linux/kernel.h | 7 +
include/linux/lsm_hooks.h | 2 +
include/linux/security.h | 6 +-
security/Kconfig | 3 +-
security/Makefile | 2 +
security/lockdown/Kconfig | 46 +++++
security/lockdown/Makefile | 1 +
security/lockdown/lockdown.c | 157 ++++++++++++++++++
security/security.c | 6 +
12 files changed, 316 insertions(+), 2 deletions(-)
create mode 100644 Documentation/ABI/testing/lockdown
create mode 100644 Documentation/admin-guide/lockdown.rst
create mode 100644 security/lockdown/Kconfig
create mode 100644 security/lockdown/Makefile
create mode 100644 security/lockdown/lockdown.c
diff --git a/Documentation/ABI/testing/lockdown b/Documentation/ABI/testing/lockdown
new file mode 100644
index 000000000000..5bd51e20917a
--- /dev/null
+++ b/Documentation/ABI/testing/lockdown
@@ -0,0 +1,19 @@
+What: security/lockdown
+Date: March 2019
+Contact: Matthew Garrett <mjg59@google.com>
+Description:
+ If CONFIG_LOCK_DOWN_KERNEL is enabled, the kernel can be
+ moved to a more locked down state at runtime by writing to
+ this attribute. Valid values are:
+
+ integrity:
+ The kernel will disable functionality that allows
+ userland to modify the running kernel image, other
+ than through the loading or execution of appropriately
+ signed objects.
+
+ confidentiality:
+ The kernel will disable all functionality disabled by
+ the integrity mode, but additionally will disable
+ features that potentially permit userland to obtain
+ confidential information stored within the kernel.
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 91c0251fdb86..594d268d92ba 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2213,6 +2213,15 @@
lockd.nlm_udpport=M [NFS] Assign UDP port.
Format: <integer>
+ lockdown= [SECURITY]
+ { integrity | confidentiality }
+ Enable the kernel lockdown feature. If set to
+ integrity, kernel features that allow userland to
+ modify the running kernel are disabled. If set to
+ confidentiality, kernel features that allow userland
+ to extract confidential information from the kernel
+ are also disabled.
+
locktorture.nreaders_stress= [KNL]
Set the number of locking read-acquisition kthreads.
Defaults to being automatically set based on the
diff --git a/Documentation/admin-guide/lockdown.rst b/Documentation/admin-guide/lockdown.rst
new file mode 100644
index 000000000000..d05dcedd20d1
--- /dev/null
+++ b/Documentation/admin-guide/lockdown.rst
@@ -0,0 +1,60 @@
+Kernel lockdown functionality
+-----------------------------
+
+.. CONTENTS
+..
+.. - Overview.
+.. - Enabling Lockdown.
+
+========
+Overview
+========
+
+Traditionally Linux systems have been run with the presumption that a
+process running with full capabilities is effectively equivalent in
+privilege to the kernel itself. The lockdown feature attempts to draw
+a stronger boundary between privileged processes and the kernel,
+increasing the level of trust that can be placed in the kernel even in
+the face of hostile processes.
+
+Lockdown can be run in two modes - integrity and confidentiality. In
+integrity mode, kernel features that allow arbitrary modification of
+the running kernel image are disabled. Confidentiality mode behaves in
+the same way as integrity mode, but also blocks features that
+potentially allow a hostile userland process to extract secret
+information from the kernel.
+
+Note that lockdown depends upon the correct behaviour of the
+kernel. Exploitable vulnerabilities in the kernel may still permit
+arbitrary modification of the kernel or make it possible to disable
+lockdown features.
+
+=================
+Enabling Lockdown
+=================
+
+Lockdown can be enabled in multiple ways.
+
+Kernel configuration
+====================
+
+The kernel can be statically configured by setting either
+CONFIG_LOCK_DOWN_KERNEL_FORCE_INTEGRITY or
+CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY. A kernel configured
+with CONFIG_LOCK_DOWN_KERNEL_FORCE_INTEGRITY may be booted into
+confidentiality mode using one of the other mechanisms, but otherwise
+the kernel will always boot into the configured mode.
+
+Kernel command line
+===================
+
+Passing lockdown=integrity or lockdown=confidentiality on the kernel
+command line will configure lockdown into the appropriate mode.
+
+Runtime configuration
+=====================
+
+/sys/kernel/security/lockdown will indicate the current lockdown
+state. The system state may be made stricter by writing either
+"integrity" or "confidentiality" into this file, but any attempts to
+make it less strict will fail.
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 8f0e68e250a7..7ce52151b76c 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -340,6 +340,13 @@ static inline void refcount_error_report(struct pt_regs *regs, const char *err)
{ }
#endif
+enum lockdown_level {
+ LOCKDOWN_NONE,
+ LOCKDOWN_INTEGRITY,
+ LOCKDOWN_CONFIDENTIALITY,
+ LOCKDOWN_MAX,
+};
+
/* Internal, do not use. */
int __must_check _kstrtoul(const char *s, unsigned int base, unsigned long *res);
int __must_check _kstrtol(const char *s, unsigned int base, long *res);
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 1a841d134e05..0377d8ee6454 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -1781,6 +1781,7 @@ union security_list_options {
int (*bpf_prog_alloc_security)(struct bpf_prog_aux *aux);
void (*bpf_prog_free_security)(struct bpf_prog_aux *aux);
#endif /* CONFIG_BPF_SYSCALL */
+ int (*locked_down)(const char *where, enum lockdown_level level);
};
struct security_hook_heads {
@@ -2016,6 +2017,7 @@ struct security_hook_heads {
struct hlist_head bpf_prog_alloc_security;
struct hlist_head bpf_prog_free_security;
#endif /* CONFIG_BPF_SYSCALL */
+ struct hlist_head locked_down;
} __randomize_layout;
/*
diff --git a/include/linux/security.h b/include/linux/security.h
index f4363a1339a8..87102694b033 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -384,6 +384,7 @@ void security_inode_invalidate_secctx(struct inode *inode);
int security_inode_notifysecctx(struct inode *inode, void *ctx, u32 ctxlen);
int security_inode_setsecctx(struct dentry *dentry, void *ctx, u32 ctxlen);
int security_inode_getsecctx(struct inode *inode, void **ctx, u32 *ctxlen);
+int security_is_locked_down(const char *where, enum lockdown_level level);
#else /* CONFIG_SECURITY */
static inline int call_lsm_notifier(enum lsm_event event, void *data)
@@ -1173,6 +1174,10 @@ static inline int security_inode_getsecctx(struct inode *inode, void **ctx, u32
{
return -EOPNOTSUPP;
}
+static inline int security_is_locked_down(const char *where, enum lockdown_level level)
+{
+ return 0;
+}
#endif /* CONFIG_SECURITY */
#ifdef CONFIG_SECURITY_NETWORK
@@ -1800,4 +1805,3 @@ static inline void security_bpf_prog_free(struct bpf_prog_aux *aux)
#endif /* CONFIG_BPF_SYSCALL */
#endif /* ! __LINUX_SECURITY_H */
-
diff --git a/security/Kconfig b/security/Kconfig
index 1d6463fb1450..c35aa72103df 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -236,12 +236,13 @@ source "security/apparmor/Kconfig"
source "security/loadpin/Kconfig"
source "security/yama/Kconfig"
source "security/safesetid/Kconfig"
+source "security/lockdown/Kconfig"
source "security/integrity/Kconfig"
config LSM
string "Ordered list of enabled LSMs"
- default "yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor"
+ default "lockdown,yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor"
help
A comma-separated list of LSMs, in initialization order.
Any LSMs left off this list will be ignored. This can be
diff --git a/security/Makefile b/security/Makefile
index c598b904938f..be1dd9d2cb2f 100644
--- a/security/Makefile
+++ b/security/Makefile
@@ -11,6 +11,7 @@ subdir-$(CONFIG_SECURITY_APPARMOR) += apparmor
subdir-$(CONFIG_SECURITY_YAMA) += yama
subdir-$(CONFIG_SECURITY_LOADPIN) += loadpin
subdir-$(CONFIG_SECURITY_SAFESETID) += safesetid
+subdir-$(CONFIG_SECURITY_LOCKDOWN_LSM) += lockdown
# always enable default capabilities
obj-y += commoncap.o
@@ -27,6 +28,7 @@ obj-$(CONFIG_SECURITY_APPARMOR) += apparmor/
obj-$(CONFIG_SECURITY_YAMA) += yama/
obj-$(CONFIG_SECURITY_LOADPIN) += loadpin/
obj-$(CONFIG_SECURITY_SAFESETID) += safesetid/
+obj-$(CONFIG_SECURITY_LOCKDOWN_LSM) += lockdown/
obj-$(CONFIG_CGROUP_DEVICE) += device_cgroup.o
# Object integrity file lists
diff --git a/security/lockdown/Kconfig b/security/lockdown/Kconfig
new file mode 100644
index 000000000000..431cd2b9a14e
--- /dev/null
+++ b/security/lockdown/Kconfig
@@ -0,0 +1,46 @@
+config SECURITY_LOCKDOWN_LSM
+ bool "Basic module for enforcing kernel lockdown"
+ depends on SECURITY
+ help
+ Build support for an LSM that enforces a coarse kernel lockdown
+ behaviour.
+
+config SECURITY_LOCKDOWN_LSM_EARLY
+ bool "Enable lockdown LSM early in init"
+ depends on SECURITY_LOCKDOWN_LSM
+ help
+ Enable the lockdown LSM early in boot. This is necessary in order
+ to ensure that lockdown enforcement can be carried out on kernel
+ boot parameters that are otherwise parsed before the security
+ subsystem is fully initialised.
+
+choice
+ prompt "Kernel default lockdown mode"
+ default LOCK_DOWN_KERNEL_FORCE_NONE
+ depends on SECURITY_LOCKDOWN_LSM
+ help
+ The kernel can be configured to default to differing levels of
+ lockdown.
+
+config LOCK_DOWN_KERNEL_FORCE_NONE
+ bool "None"
+ help
+ No lockdown functionality is enabled by default. Lockdown may be
+ enabled via the kernel commandline or /sys/kernel/security/lockdown.
+
+config LOCK_DOWN_KERNEL_FORCE_INTEGRITY
+ bool "Integrity"
+ help
+ The kernel runs in integrity mode by default. Features that allow
+ the kernel to be modified at runtime are disabled.
+
+config LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY
+ bool "Confidentiality"
+ help
+ The kernel runs in confidentiality mode by default. Features that
+ allow the kernel to be modified at runtime or that permit userland
+ code to read confidential material held inside the kernel are
+ disabled.
+
+endchoice
+
diff --git a/security/lockdown/Makefile b/security/lockdown/Makefile
new file mode 100644
index 000000000000..e3634b9017e7
--- /dev/null
+++ b/security/lockdown/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_SECURITY_LOCKDOWN_LSM) += lockdown.o
diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
new file mode 100644
index 000000000000..6c707492344b
--- /dev/null
+++ b/security/lockdown/lockdown.c
@@ -0,0 +1,157 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Lock down the kernel
+ *
+ * Copyright (C) 2016 Red Hat, Inc. All Rights Reserved.
+ * Written by David Howells (dhowells@redhat.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public Licence
+ * as published by the Free Software Foundation; either version
+ * 2 of the Licence, or (at your option) any later version.
+ */
+
+#include <linux/security.h>
+#include <linux/export.h>
+#include <linux/lsm_hooks.h>
+
+static enum lockdown_level kernel_locked_down;
+
+char *lockdown_levels[LOCKDOWN_MAX] = {"none", "integrity", "confidentiality"};
+
+/*
+ * Put the kernel into lock-down mode.
+ */
+static int lock_kernel_down(const char *where, enum lockdown_level level)
+{
+ if (kernel_locked_down >= level)
+ return -EPERM;
+
+ kernel_locked_down = level;
+ pr_notice("Kernel is locked down from %s; see man kernel_lockdown.7\n",
+ where);
+ return 0;
+}
+
+static int __init lockdown_param(char *level)
+{
+ if (!level)
+ return -EINVAL;
+
+ if (strcmp(level, "integrity") == 0)
+ lock_kernel_down("command line", LOCKDOWN_INTEGRITY);
+ else if (strcmp(level, "confidentiality") == 0)
+ lock_kernel_down("command line", LOCKDOWN_CONFIDENTIALITY);
+ else
+ return -EINVAL;
+
+ return 0;
+}
+
+early_param("lockdown", lockdown_param);
+
+/**
+ * lockdown_is_locked_down - Find out if the kernel is locked down
+ * @what: Tag to use in notice generated if lockdown is in effect
+ */
+static int lockdown_is_locked_down(const char *what, enum lockdown_level level)
+{
+ if ((kernel_locked_down >= level) && what)
+ pr_notice("Lockdown: %s is restricted; see man kernel_lockdown.7\n",
+ what);
+ return (kernel_locked_down >= level);
+}
+
+static struct security_hook_list lockdown_hooks[] __lsm_ro_after_init = {
+ LSM_HOOK_INIT(locked_down, lockdown_is_locked_down),
+};
+
+static int __init lockdown_lsm_init(void)
+{
+#if defined(CONFIG_LOCK_DOWN_KERNEL_FORCE_INTEGRITY)
+ lock_kernel_down("Kernel configuration", LOCKDOWN_INTEGRITY);
+#elif defined(CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY)
+ lock_kernel_down("Kernel configuration", LOCKDOWN_CONFIDENTIALITY);
+#endif
+ security_add_hooks(lockdown_hooks, ARRAY_SIZE(lockdown_hooks),
+ "lockdown");
+ return 0;
+}
+
+static ssize_t lockdown_read(struct file *filp, char __user *buf, size_t count,
+ loff_t *ppos)
+{
+ char temp[80];
+ int i, offset=0;
+
+ for (i = LOCKDOWN_NONE; i < LOCKDOWN_MAX; i++) {
+ if (lockdown_levels[i]) {
+ const char *label = lockdown_levels[i];
+
+ if (kernel_locked_down == i)
+ offset += sprintf(temp+offset, "[%s] ", label);
+ else
+ offset += sprintf(temp+offset, "%s ", label);
+ }
+ }
+
+ /* Convert the last space to a newline if needed. */
+ if (offset > 0)
+ temp[offset-1] = '\n';
+
+ return simple_read_from_buffer(buf, count, ppos, temp, strlen(temp));
+}
+
+static ssize_t lockdown_write(struct file *file, const char __user *buf,
+ size_t n, loff_t *ppos)
+{
+ char *state;
+ int i, len, err = -EINVAL;
+
+ state = memdup_user_nul(buf, n);
+ if (IS_ERR(state))
+ return PTR_ERR(state);
+
+ len = strlen(state);
+ if (len && state[len-1] == '\n') {
+ state[len-1] = '\0';
+ len--;
+ }
+
+ for (i = 0; i < LOCKDOWN_MAX; i++) {
+ const char *label = lockdown_levels[i];
+
+ if (label && !strcmp(state, label))
+ err = lock_kernel_down("securityfs", i);
+ }
+
+ kfree(state);
+ return err ? err : n;
+}
+
+static const struct file_operations lockdown_ops = {
+ .read = lockdown_read,
+ .write = lockdown_write,
+};
+
+static int __init lockdown_secfs_init(void)
+{
+ struct dentry *dentry;
+
+ dentry = securityfs_create_file("lockdown", 0600, NULL, NULL,
+ &lockdown_ops);
+ if (IS_ERR(dentry))
+ return PTR_ERR(dentry);
+
+ return 0;
+}
+
+core_initcall(lockdown_secfs_init);
+
+#ifdef CONFIG_SECURITY_LOCKDOWN_LSM_EARLY
+DEFINE_EARLY_LSM(lockdown) = {
+#else
+DEFINE_LSM(lockdown) = {
+#endif
+ .name = "lockdown",
+ .init = lockdown_lsm_init,
+};
diff --git a/security/security.c b/security/security.c
index e3a7d4e96541..73ccf3be55bf 100644
--- a/security/security.c
+++ b/security/security.c
@@ -2370,3 +2370,9 @@ void security_bpf_prog_free(struct bpf_prog_aux *aux)
call_void_hook(bpf_prog_free_security, aux);
}
#endif /* CONFIG_BPF_SYSCALL */
+
+int security_is_locked_down(const char *where, enum lockdown_level level)
+{
+ return call_int_hook(locked_down, 0, where, level);
+}
+EXPORT_SYMBOL(security_is_locked_down);
--
2.21.0.1020.gf2820cf01a-goog
^ permalink raw reply related
* [RFC] Turn lockdown into an LSM
From: Matthew Garrett @ 2019-05-21 22:40 UTC (permalink / raw)
To: jmorris; +Cc: linux-security-module, linux-kernel
Hi James,
This is a quick attempt to integrate lockdown into the existing LSM
framework. It adds a new lockdown security hook and an LSM that defines
the existing coarse-grained policy, and also adds a new
DEFINE_EARLY_LSM() definition in order to permit lockdown (and
potentially other modules) to be initialised at the top of kernel init
in order to allow policy to be imposed on stuff that happens in
setup_arch(). The goal here is to allow policy to be devolved to other
LSMs on systems that have a secure mechanism for loading LSM policy
early in boot, allowing creation of arbitrarily complicated policies
without interfering with the common-case coarse-grained approach.
This should probably be extended so a uapi-exposed constant is passed to
the hook in order to make it easier to write policy in other LSMs, but
does this broadly look like you were imagining?
^ permalink raw reply
* Re: [PATCH] Smack: Restore the smackfsdef mount option
From: Casey Schaufler @ 2019-05-21 22:25 UTC (permalink / raw)
To: LKML, Al Viro, dhowells; +Cc: jose.bollo, Linux Security Module list
In-Reply-To: <1ebab7e7-f7ee-b910-9cc8-5d826eee8e97@schaufler-ca.com>
On 5/20/2019 3:48 PM, Casey Schaufler wrote:
> The 5.1 mount system rework changed the smackfsdef mount option
> to smackfsdefault. This fixes the regression by making smackfsdef
> treated the same way as smackfsdefault. The change was made in
> commit c3300aaf95fb4 from Al Viro.
>
> Reported-by: Jose Bollo <jose.bollo@iot.bzh>
> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Al, Dave, is this patch in keeping with the intent
of the mount rework? Is there a different way I should
do it? Do you want to take it as a fix for the mount
work, or should I push it?
Thank you.
> ---
> ??security/smack/smack_lsm.c | 2 ++
> ??1 file changed, 2 insertions(+)
>
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index b9abcdb36a73..915cf598e164 100644
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -68,6 +68,7 @@ static struct {
> ???????? int len;
> ???????? int opt;
> ??} smk_mount_opts[] = {
> +?????? {"smackfsdef", sizeof("smackfsdef") - 1, Opt_fsdefault},
> ???????? A(fsdefault), A(fsfloor), A(fshat), A(fsroot), A(fstransmute)
> ??};
> ??#undef A
> @@ -682,6 +683,7 @@ static int smack_fs_context_dup(struct fs_context
> *fc,
> ??}
>
> ??static const struct fs_parameter_spec smack_param_specs[] = {
> +?????? fsparam_string("fsdef",?????????????? Opt_fsdefault),
> ???????? fsparam_string("fsdefault",?????? Opt_fsdefault),
> ???????? fsparam_string("fsfloor",?????? Opt_fsfloor),
> ???????? fsparam_string("fshat",?????????????? Opt_fshat),
>
^ permalink raw reply
* Re: [GIT PULL] SELinux fixes for v5.2 (#1)
From: pr-tracker-bot @ 2019-05-21 19:55 UTC (permalink / raw)
To: Paul Moore; +Cc: Linus Torvalds, selinux, linux-security-module, linux-kernel
In-Reply-To: <CAHC9VhTvU7kQ7D8OwRPvc0tpjtXVK6FiiT07WuQyjtJ80TeQrQ@mail.gmail.com>
The pull request you sent on Tue, 21 May 2019 12:49:55 -0400:
> git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git tags/selinux-pr-20190521
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9c7db5004280767566e91a33445bf93aa479ef02
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* [GIT PULL] SELinux fixes for v5.2 (#1)
From: Paul Moore @ 2019-05-21 16:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: selinux, linux-security-module, linux-kernel
Hi Linus,
One small SELinux patch for v5.2 to fix a problem when disconnecting a
SCTP socket with connect(AF_UNSPEC). Please merge this fix for v5.2.
Thanks,
-Paul
--
The following changes since commit 35a196bef449b5824033865b963ed9a43fb8c730:
proc: prevent changes to overridden credentials (2019-04-29 09:51:21 -0400)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git
tags/selinux-pr-20190521
for you to fetch changes up to 05174c95b83f8aca0c47b87115abb7a6387aafa5:
selinux: do not report error on connect(AF_UNSPEC)
(2019-05-20 21:46:02 -0400)
----------------------------------------------------------------
selinux/stable-5.2 PR 20190521
----------------------------------------------------------------
Paolo Abeni (1):
selinux: do not report error on connect(AF_UNSPEC)
security/selinux/hooks.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)
From: Sean Christopherson @ 2019-05-21 15:51 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: Andy Lutomirski, James Morris, Serge E. Hallyn, LSM List,
Paul Moore, Stephen Smalley, Eric Paris, selinux, Jethro Beekman,
Xing, Cedric, Hansen, Dave, Thomas Gleixner, Dr. Greg,
Linus Torvalds, LKML, X86 ML, linux-sgx@vger.kernel.org,
Andrew Morton, nhorman@redhat.com, npmccallum@redhat.com,
Ayoun, Serge, Katz-zamir, Shay, Huang, Haitao, Andy Shevchenko,
Svahn, Kai, Borislav Petkov, Josh Triplett, Huang, Kai,
David Rientjes
In-Reply-To: <20190521151836.GA4843@linux.intel.com>
On Tue, May 21, 2019 at 06:19:37PM +0300, Jarkko Sakkinen wrote:
> On Mon, May 20, 2019 at 02:41:05PM +0300, Jarkko Sakkinen wrote:
> > On Thu, May 16, 2019 at 05:26:15PM -0700, Andy Lutomirski wrote:
> > > Is userspace actually requred to mmap() the enclave prior to EADDing things?
> >
> > Nope, not since v20. Here is what I wrote about API to the kernel
> > documentation:
> >
> > "The enclave life-cycle starts by opening `/dev/sgx/enclave`. After this
> > there is already a data structure inside kernel tracking the enclave
> > that is initially uncreated. After this a set of ioctl's can be used to
> > create, populate and initialize the enclave.
> >
> > You can close (if you want) the fd after you've mmap()'d. As long as the
> > file is open the enclave stays alive so you might want to do that after
> > you don't need it anymore. Even munmap() won't destruct the enclave if
> > the file is open. Neither will closing the fd as long as you have
> > mmap() done over the fd (even if it does not across the range defined in
> > SECS)."
> >
> > Enclave can be created and initialized without doing a single mmap()
> > call.
>
> We could even disallow mmap() before EINIT done. The way enclave
> management internally works right now is quite robust and completely
> detached from requiring process address space for anything.
Except that mmap() is more or less required to guarantee that ELRANGE
established by ECREATE is available. And we want to disallow mmap() as
soon as the first EADD is done so that userspace can't remap the enclave's
VMAs via munmap()->mmap() and gain execute permissions to pages that were
EADD'd as NX.
Actually, conceptually it's probably more intuitive to disallow mmap() at
ECREATE, i.e. the act of creating an enclave pins the associated virtual
address range until the enclave is destroyed.
^ permalink raw reply
* Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)
From: Jethro Beekman @ 2019-05-21 15:24 UTC (permalink / raw)
To: Jarkko Sakkinen, Andy Lutomirski
Cc: Sean Christopherson, James Morris, Serge E. Hallyn, LSM List,
Paul Moore, Stephen Smalley, Eric Paris, selinux@vger.kernel.org,
Xing, Cedric, Hansen, Dave, Thomas Gleixner, Dr. Greg,
Linus Torvalds, LKML, X86 ML, linux-sgx@vger.kernel.org,
Andrew Morton, nhorman@redhat.com, npmccallum@redhat.com,
Ayoun, Serge, Katz-zamir, Shay, Huang, Haitao, Andy Shevchenko,
Svahn, Kai, Borislav Petkov, Josh Triplett, Huang, Kai,
David Rientjes
In-Reply-To: <20190521151836.GA4843@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 275 bytes --]
On 2019-05-21 08:19, Jarkko Sakkinen wrote:
> We could even disallow mmap() before EINIT done.
This would be extremely annoying in software because now you have to
save the all the page permissions somewhere between EADD and mprotect.
--
Jethro Beekman | Fortanix
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3990 bytes --]
^ permalink raw reply
* Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)
From: Jarkko Sakkinen @ 2019-05-21 15:19 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Sean Christopherson, James Morris, Serge E. Hallyn, LSM List,
Paul Moore, Stephen Smalley, Eric Paris, selinux, Jethro Beekman,
Xing, Cedric, Hansen, Dave, Thomas Gleixner, Dr. Greg,
Linus Torvalds, LKML, X86 ML, linux-sgx@vger.kernel.org,
Andrew Morton, nhorman@redhat.com, npmccallum@redhat.com,
Ayoun, Serge, Katz-zamir, Shay, Huang, Haitao, Andy Shevchenko,
Svahn, Kai, Borislav Petkov, Josh Triplett, Huang, Kai,
David Rientjes
In-Reply-To: <20190520114105.GD27805@linux.intel.com>
On Mon, May 20, 2019 at 02:41:05PM +0300, Jarkko Sakkinen wrote:
> On Thu, May 16, 2019 at 05:26:15PM -0700, Andy Lutomirski wrote:
> > Is userspace actually requred to mmap() the enclave prior to EADDing things?
>
> Nope, not since v20. Here is what I wrote about API to the kernel
> documentation:
>
> "The enclave life-cycle starts by opening `/dev/sgx/enclave`. After this
> there is already a data structure inside kernel tracking the enclave
> that is initially uncreated. After this a set of ioctl's can be used to
> create, populate and initialize the enclave.
>
> You can close (if you want) the fd after you've mmap()'d. As long as the
> file is open the enclave stays alive so you might want to do that after
> you don't need it anymore. Even munmap() won't destruct the enclave if
> the file is open. Neither will closing the fd as long as you have
> mmap() done over the fd (even if it does not across the range defined in
> SECS)."
>
> Enclave can be created and initialized without doing a single mmap()
> call.
We could even disallow mmap() before EINIT done. The way enclave
management internally works right now is quite robust and completely
detached from requiring process address space for anything.
/Jarkko
^ permalink raw reply
* Re: [PATCH v2 3/4] gfp: mm: introduce __GFP_NO_AUTOINIT
From: Michal Hocko @ 2019-05-21 14:25 UTC (permalink / raw)
To: Alexander Potapenko
Cc: Kees Cook, Andrew Morton, Christoph Lameter, Kernel Hardening,
Masahiro Yamada, James Morris, Serge E. Hallyn, Nick Desaulniers,
Kostya Serebryany, Dmitry Vyukov, Sandeep Patil, Laura Abbott,
Randy Dunlap, Jann Horn, Mark Rutland, Souptick Joarder,
Matthew Wilcox, Linux Memory Management List,
linux-security-module
In-Reply-To: <CAG_fn=W9Y7=RZREi5S8z-sAMg2GfPsWqrHo+UawXWiRbhrNd0Q@mail.gmail.com>
On Tue 21-05-19 16:18:37, Alexander Potapenko wrote:
> On Fri, May 17, 2019 at 7:11 PM Michal Hocko <mhocko@kernel.org> wrote:
> >
> > On Fri 17-05-19 09:27:54, Kees Cook wrote:
> > > On Fri, May 17, 2019 at 04:01:08PM +0200, Michal Hocko wrote:
> > > > On Fri 17-05-19 15:37:14, Alexander Potapenko wrote:
> > > > > > > > Freeing a memory is an opt-in feature and the slab allocator can already
> > > > > > > > tell many (with constructor or GFP_ZERO) do not need it.
> > > > > > > Sorry, I didn't understand this piece. Could you please elaborate?
> > > > > >
> > > > > > The allocator can assume that caches with a constructor will initialize
> > > > > > the object so additional zeroying is not needed. GFP_ZERO should be self
> > > > > > explanatory.
> > > > > Ah, I see. We already do that, see the want_init_on_alloc()
> > > > > implementation here: https://patchwork.kernel.org/patch/10943087/
> > > > > > > > So can we go without this gfp thing and see whether somebody actually
> > > > > > > > finds a performance problem with the feature enabled and think about
> > > > > > > > what can we do about it rather than add this maint. nightmare from the
> > > > > > > > very beginning?
> > > > > > >
> > > > > > > There were two reasons to introduce this flag initially.
> > > > > > > The first was double initialization of pages allocated for SLUB.
> > > > > >
> > > > > > Could you elaborate please?
> > > > > When the kernel allocates an object from SLUB, and SLUB happens to be
> > > > > short on free pages, it requests some from the page allocator.
> > > > > Those pages are initialized by the page allocator
> > > >
> > > > ... when the feature is enabled ...
> > > >
> > > > > and split into objects. Finally SLUB initializes one of the available
> > > > > objects and returns it back to the kernel.
> > > > > Therefore the object is initialized twice for the first time (when it
> > > > > comes directly from the page allocator).
> > > > > This cost is however amortized by SLUB reusing the object after it's been freed.
> > > >
> > > > OK, I see what you mean now. Is there any way to special case the page
> > > > allocation for this feature? E.g. your implementation tries to make this
> > > > zeroying special but why cannot you simply do this
> > > >
> > > >
> > > > struct page *
> > > > ____alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order, int preferred_nid,
> > > > nodemask_t *nodemask)
> > > > {
> > > > //current implementation
> > > > }
> > > >
> > > > struct page *
> > > > __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order, int preferred_nid,
> > > > nodemask_t *nodemask)
> > > > {
> > > > if (your_feature_enabled)
> > > > gfp_mask |= __GFP_ZERO;
> > > > return ____alloc_pages_nodemask(gfp_mask, order, preferred_nid,
> > > > nodemask);
> > > > }
> > > >
> > > > and use ____alloc_pages_nodemask from the slab or other internal
> > > > allocators?
> Given that calling alloc_pages() with __GFP_NO_AUTOINIT doesn't
> visibly improve the chosen benchmarks,
> and the next patch in the series ("net: apply __GFP_NO_AUTOINIT to
> AF_UNIX sk_buff allocations") only improves hackbench,
> shall we maybe drop both patches altogether?
Ohh, by all means. I was suggesting the same few emails ago. The above
is just a hint on how to implement the feature on the page allocator
level rather than hooking into the prep_new_page and add another branch
to zero memory.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2 3/4] gfp: mm: introduce __GFP_NO_AUTOINIT
From: Alexander Potapenko @ 2019-05-21 14:18 UTC (permalink / raw)
To: Michal Hocko, Kees Cook
Cc: Andrew Morton, Christoph Lameter, Kernel Hardening,
Masahiro Yamada, James Morris, Serge E. Hallyn, Nick Desaulniers,
Kostya Serebryany, Dmitry Vyukov, Sandeep Patil, Laura Abbott,
Randy Dunlap, Jann Horn, Mark Rutland, Souptick Joarder,
Matthew Wilcox, Linux Memory Management List,
linux-security-module
In-Reply-To: <20190517171105.GT6836@dhcp22.suse.cz>
On Fri, May 17, 2019 at 7:11 PM Michal Hocko <mhocko@kernel.org> wrote:
>
> On Fri 17-05-19 09:27:54, Kees Cook wrote:
> > On Fri, May 17, 2019 at 04:01:08PM +0200, Michal Hocko wrote:
> > > On Fri 17-05-19 15:37:14, Alexander Potapenko wrote:
> > > > > > > Freeing a memory is an opt-in feature and the slab allocator can already
> > > > > > > tell many (with constructor or GFP_ZERO) do not need it.
> > > > > > Sorry, I didn't understand this piece. Could you please elaborate?
> > > > >
> > > > > The allocator can assume that caches with a constructor will initialize
> > > > > the object so additional zeroying is not needed. GFP_ZERO should be self
> > > > > explanatory.
> > > > Ah, I see. We already do that, see the want_init_on_alloc()
> > > > implementation here: https://patchwork.kernel.org/patch/10943087/
> > > > > > > So can we go without this gfp thing and see whether somebody actually
> > > > > > > finds a performance problem with the feature enabled and think about
> > > > > > > what can we do about it rather than add this maint. nightmare from the
> > > > > > > very beginning?
> > > > > >
> > > > > > There were two reasons to introduce this flag initially.
> > > > > > The first was double initialization of pages allocated for SLUB.
> > > > >
> > > > > Could you elaborate please?
> > > > When the kernel allocates an object from SLUB, and SLUB happens to be
> > > > short on free pages, it requests some from the page allocator.
> > > > Those pages are initialized by the page allocator
> > >
> > > ... when the feature is enabled ...
> > >
> > > > and split into objects. Finally SLUB initializes one of the available
> > > > objects and returns it back to the kernel.
> > > > Therefore the object is initialized twice for the first time (when it
> > > > comes directly from the page allocator).
> > > > This cost is however amortized by SLUB reusing the object after it's been freed.
> > >
> > > OK, I see what you mean now. Is there any way to special case the page
> > > allocation for this feature? E.g. your implementation tries to make this
> > > zeroying special but why cannot you simply do this
> > >
> > >
> > > struct page *
> > > ____alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order, int preferred_nid,
> > > nodemask_t *nodemask)
> > > {
> > > //current implementation
> > > }
> > >
> > > struct page *
> > > __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int order, int preferred_nid,
> > > nodemask_t *nodemask)
> > > {
> > > if (your_feature_enabled)
> > > gfp_mask |= __GFP_ZERO;
> > > return ____alloc_pages_nodemask(gfp_mask, order, preferred_nid,
> > > nodemask);
> > > }
> > >
> > > and use ____alloc_pages_nodemask from the slab or other internal
> > > allocators?
Given that calling alloc_pages() with __GFP_NO_AUTOINIT doesn't
visibly improve the chosen benchmarks,
and the next patch in the series ("net: apply __GFP_NO_AUTOINIT to
AF_UNIX sk_buff allocations") only improves hackbench,
shall we maybe drop both patches altogether?
> > If an additional allocator function is preferred over a new GFP flag, then
> > I don't see any reason not to do this. (Though adding more "__"s seems
> > a bit unfriendly to code-documentation.) What might be better naming?
>
> The naminig is the last thing I would be worried about. Let's focus on
> the most simplistic implementation first. And means, can we really make
> it as simple as above? At least on the page allocator level.
>
> > This would mean that the skb changes later in the series would use the
> > "no auto init" version of the allocator too, then.
>
> No, this would be an internal function to MM. I would really like to
> optimize once there are numbers from _real_ workloads to base those
> optimizations.
> --
> Michal Hocko
> SUSE Labs
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
^ permalink raw reply
* Re: [PATCH 3/4] ima: don't ignore INTEGRITY_UNKNOWN EVM status
From: Mimi Zohar @ 2019-05-21 11:48 UTC (permalink / raw)
To: Roberto Sassu, dmitry.kasatkin, mjg59
Cc: linux-integrity, linux-doc, linux-security-module, linux-kernel,
silviu.vlasceanu, stable
In-Reply-To: <e81b761c-9133-a432-4d06-3cfe57e29e4b@huawei.com>
On Tue, 2019-05-21 at 09:26 +0200, Roberto Sassu wrote:
> On 5/20/2019 11:20 PM, Mimi Zohar wrote:
> > On Thu, 2019-05-16 at 18:12 +0200, Roberto Sassu wrote:
> >> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> >> index 52e6fbb042cc..80e1c233656b 100644
> >> --- a/Documentation/admin-guide/kernel-parameters.txt
> >> +++ b/Documentation/admin-guide/kernel-parameters.txt
> >> @@ -1588,6 +1588,9 @@
> >> Format: { "off" | "enforce" | "fix" | "log" }
> >> default: "enforce"
> >>
> >> + ima_appraise_req_evm
> >> + [IMA] require EVM for appraisal with file digests.
> >
> > As much as possible we want to limit the number of new boot command
> > line options as possible. Is there a reason for not extending
> > "ima_appraise=" with "require-evm" or "enforce-evm"?
>
> ima-appraise= can be disabled with CONFIG_IMA_APPRAISE_BOOTPARAM, which
> probably is done when the system is in production.
>
> Should I allow to use ima-appraise=require-evm even if
> CONFIG_IMA_APPRAISE_BOOTPARAM=n?
Yes, that should be fine. It's making "ima_appraise" stricter.
Mimi
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox