* [PATCH 09/10] KEYS: reuse keyring_index_key::desc_len in lookup_user_key() [ver #2]
From: David Howells @ 2019-05-30 17:26 UTC (permalink / raw)
To: keyrings
Cc: Eric Biggers, James Morris, dhowells, linux-security-module,
linux-kernel, ebiggers
In-Reply-To: <155923711088.949.14909672457214372214.stgit@warthog.procyon.org.uk>
From: Eric Biggers <ebiggers@google.com>
When lookup_user_key() checks whether the key is possessed, it should
use the key's existing index_key including the 'desc_len' field, rather
than recomputing the 'desc_len'. This doesn't change the behavior; this
way is just simpler and faster.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jamorris@linux.microsoft.com>
---
security/keys/process_keys.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/security/keys/process_keys.c b/security/keys/process_keys.c
index ba5d3172cafe..39aaa21462bf 100644
--- a/security/keys/process_keys.c
+++ b/security/keys/process_keys.c
@@ -688,9 +688,7 @@ key_ref_t lookup_user_key(key_serial_t id, unsigned long lflags,
key_ref = make_key_ref(key, 0);
/* check to see if we possess the key */
- ctx.index_key.type = key->type;
- ctx.index_key.description = key->description;
- ctx.index_key.desc_len = strlen(key->description);
+ ctx.index_key = key->index_key;
ctx.match_data.raw_data = key;
kdebug("check possessed");
skey_ref = search_process_keyrings(&ctx);
^ permalink raw reply related
* [PATCH 10/10] keys: Add capability-checking keyctl function [ver #2]
From: David Howells @ 2019-05-30 17:26 UTC (permalink / raw)
To: keyrings; +Cc: dhowells, linux-security-module, linux-kernel, ebiggers
In-Reply-To: <155923711088.949.14909672457214372214.stgit@warthog.procyon.org.uk>
Add a keyctl function that requests a set of capability bits to find out
what features are supported.
Signed-off-by: David Howells <dhowells@redhat.com>
---
include/uapi/linux/keyctl.h | 14 ++++++++++++++
security/keys/compat.c | 3 +++
security/keys/internal.h | 2 ++
security/keys/keyctl.c | 37 +++++++++++++++++++++++++++++++++++++
4 files changed, 56 insertions(+)
diff --git a/include/uapi/linux/keyctl.h b/include/uapi/linux/keyctl.h
index fd9fb11b312b..aa4972163442 100644
--- a/include/uapi/linux/keyctl.h
+++ b/include/uapi/linux/keyctl.h
@@ -68,6 +68,7 @@
#define KEYCTL_PKEY_VERIFY 28 /* Verify a public key signature */
#define KEYCTL_RESTRICT_KEYRING 29 /* Restrict keys allowed to link to a keyring */
#define KEYCTL_MOVE 30 /* Move keys between keyrings */
+#define KEYCTL_CAPABILITIES 31 /* Find capabilities of keyrings subsystem */
/* keyctl structures */
struct keyctl_dh_params {
@@ -115,4 +116,17 @@ struct keyctl_pkey_params {
#define KEYCTL_MOVE_EXCL 0x00000001 /* Do not displace from the to-keyring */
+/*
+ * Capabilities flags. The capabilities list is an array of 32-bit integers;
+ * each integer can carry up to 32 flags.
+ */
+#define KEYCTL_CAPS0_CAPABILITIES 0x00000001 /* KEYCTL_CAPABILITIES supported */
+#define KEYCTL_CAPS0_PERSISTENT_KEYRINGS 0x00000002 /* Persistent keyrings enabled */
+#define KEYCTL_CAPS0_DIFFIE_HELLMAN 0x00000004 /* Diffie-Hellman computation enabled */
+#define KEYCTL_CAPS0_PUBLIC_KEY 0x00000008 /* Public key ops enabled */
+#define KEYCTL_CAPS0_BIG_KEY 0x00000010 /* big_key-type enabled */
+#define KEYCTL_CAPS0_INVALIDATE 0x00000020 /* KEYCTL_INVALIDATE supported */
+#define KEYCTL_CAPS0_RESTRICT_KEYRING 0x00000040 /* KEYCTL_RESTRICT_KEYRING supported */
+#define KEYCTL_CAPS0_MOVE 0x00000080 /* KEYCTL_MOVE supported */
+
#endif /* _LINUX_KEYCTL_H */
diff --git a/security/keys/compat.c b/security/keys/compat.c
index b326bc4f84d7..a53e30da20c5 100644
--- a/security/keys/compat.c
+++ b/security/keys/compat.c
@@ -162,6 +162,9 @@ COMPAT_SYSCALL_DEFINE5(keyctl, u32, option,
case KEYCTL_MOVE:
return keyctl_keyring_move(arg2, arg3, arg4, arg5);
+ case KEYCTL_CAPABILITIES:
+ return keyctl_capabilities(compat_ptr(arg2), arg3);
+
default:
return -EOPNOTSUPP;
}
diff --git a/security/keys/internal.h b/security/keys/internal.h
index b54a58c025ae..884fd796f668 100644
--- a/security/keys/internal.h
+++ b/security/keys/internal.h
@@ -329,6 +329,8 @@ static inline long keyctl_pkey_e_d_s(int op,
}
#endif
+extern long keyctl_capabilities(unsigned int __user *_buffer, size_t buflen);
+
/*
* Debugging key validation
*/
diff --git a/security/keys/keyctl.c b/security/keys/keyctl.c
index bbfe7d92d41c..b3db363e0b25 100644
--- a/security/keys/keyctl.c
+++ b/security/keys/keyctl.c
@@ -30,6 +30,18 @@
#define KEY_MAX_DESC_SIZE 4096
+static const u32 keyrings_capabilities[1] = {
+ [0] = (KEYCTL_CAPS0_CAPABILITIES |
+ (IS_ENABLED(CONFIG_PERSISTENT_KEYRINGS) ? KEYCTL_CAPS0_PERSISTENT_KEYRINGS : 0) |
+ (IS_ENABLED(CONFIG_KEY_DH_OPERATIONS) ? KEYCTL_CAPS0_DIFFIE_HELLMAN : 0) |
+ (IS_ENABLED(CONFIG_ASYMMETRIC_KEY_TYPE) ? KEYCTL_CAPS0_PUBLIC_KEY : 0) |
+ (IS_ENABLED(CONFIG_BIG_KEYS) ? KEYCTL_CAPS0_BIG_KEY : 0) |
+ KEYCTL_CAPS0_INVALIDATE |
+ KEYCTL_CAPS0_RESTRICT_KEYRING |
+ KEYCTL_CAPS0_MOVE
+ ),
+};
+
static int key_get_type_from_user(char *type,
const char __user *_type,
unsigned len)
@@ -1678,6 +1690,28 @@ long keyctl_restrict_keyring(key_serial_t id, const char __user *_type,
return ret;
}
+/*
+ * Get keyrings subsystem capabilities.
+ */
+long keyctl_capabilities(unsigned int __user *_buffer, size_t buflen)
+{
+ size_t size = buflen;
+
+ if (size == 0)
+ return sizeof(keyrings_capabilities);
+ if (size & 3)
+ return -EINVAL;
+ if (size > sizeof(keyrings_capabilities))
+ size = sizeof(keyrings_capabilities);
+ if (copy_to_user(_buffer, keyrings_capabilities, size) != 0)
+ return -EFAULT;
+ if (size < buflen &&
+ clear_user(_buffer + size, buflen - size) != 0)
+ return -EFAULT;
+
+ return sizeof(keyrings_capabilities);
+}
+
/*
* The key control system call
*/
@@ -1824,6 +1858,9 @@ SYSCALL_DEFINE5(keyctl, int, option, unsigned long, arg2, unsigned long, arg3,
(key_serial_t)arg4,
(unsigned int)arg5);
+ case KEYCTL_CAPABILITIES:
+ return keyctl_capabilities((unsigned int __user *)arg2, (size_t)arg3);
+
default:
return -EOPNOTSUPP;
}
^ permalink raw reply related
* Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)
From: Sean Christopherson @ 2019-05-30 18:01 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Stephen Smalley, Xing, Cedric, William Roberts, Jarkko Sakkinen,
James Morris, Serge E. Hallyn, LSM List, Paul Moore, Eric Paris,
selinux@vger.kernel.org, Jethro Beekman, 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: <CALCETrWsEXzUC33eJpGCpdMCBO4aYVviZLRD-CLMNaG5Jv-TCA@mail.gmail.com>
On Thu, May 30, 2019 at 09:14:10AM -0700, Andy Lutomirski wrote:
> On Thu, May 30, 2019 at 8:04 AM Stephen Smalley <sds@tycho.nsa.gov> wrote:
> >
> > On 5/30/19 10:31 AM, Andy Lutomirski wrote:
> > > Hi all-
> > >
> > > After an offline discussion with Sean yesterday, here are some updates
> > > to the user API parts of my proposal.
> > >
> > > Unfortunately, Sean convinced me that MAXPERM doesn't work the way I
> > > described it because, for SGX2, the enclave loader won't know at load
> > > time whether a given EAUG-ed page will ever be executed. So here's an
> > > update.
> > >
> > > First, here are the requrements as I see them, where EXECUTE, EXECMOD,
> > > and EXECMEM could be substituted with other rules at the LSM's
> > > discretion:
> > >
> > > - You can create a WX or RWX mapping if and only if you have EXECMEM.
> > >
> > > - To create an X mapping of an enclave page that has ever been W, you
> > > need EXECMOD.
> >
> > EXECMOD to what file? The enclave file from which the page's content
> > originated, the sigstruct file, or /dev/sgx/enclave?
>
> I leave that decision to you :) The user should need permission to do
> an execmod thing on an enclave, however that wants to be encoded.
But that decision dictates how the SGX API handles sigstruct. If LSMs
want to associate EXECMOD with sigstruct, then SGX needs to take sigstruct
early and hold a reference to the file for the lifetime of the enclave.
And if we're going to do that, the whole approach of inheriting
permissions from source VMAs becomes unnecessary complexity.
> >
> > > - To create an X mapping of an enclave page that came from EADD, you
> > > need EXECUTE on the source file. Optionally, we could also permit
> > > this if you have EXECMOD.
> >
> > What is the "source file" i.e. the target of the check? Enclave file,
> > sigstruct file, or /dev/sgx/enclave?
>
> Enclave file -- that is, the file backing the vma from which the data is loaded.
It wasn't explicitly called out in Andy's proposal(s), but the idea is
that the SGX driver would effectively inherit permissions from the source
VMA (EADD needs a source for the initial value of the encave page).
I have two gripes with that approach:
- Requires enclave builder to mark enclave pages executable in the
non-enclave VMAs, which may unnecessarily require EXECMOD on the
source file, or even worse, EXECMEM, and potentially increases the
attack surface since the file must be executable.
- Is completely unnecessary if the enclave holds a reference to the
sigstruct file, as LSMs can easily apply labels to the sigstruct,
e.g. EXECUTE on the sigstruct instead of EXECUTE on the source file.
After the bajillion mails we've generated, AIUI we've come up with two
concepts that are viable: inheriting permissions from the source VMA
vs. using sigstruct as a proxy for the enclave. Andy's proposals rely on
the inheritance concept. The proposal below is based on the sigstruct
proxy concept.
For those not familiar with SGX details, sigstruct can be used as a proxy
because hardware enforces that the measurement stored in the sigstruct
exactly matches the measurement generated by the enclave build process,
e.g. adding a page as RX instead of R will change the measurement.
Core Concepts:
- FILE_{READ,WRITE,EXEC} on /dev/sgx/enclave effectively gates access to
EPC. All real world enclaves will need all three permissions.
- sigstruct is the proxy for enclave from an LSM perspective, e.g.
SELinux can define ENCLAVE__EXECUTE and ENCLAVE__EXECMOD and apply
them to the sigstruct file.
- Take sigstruct at ECREATE so that ADD_REGION immediately followed by
mprotect() works as expected (because SGX.mprotect() needs sigstruct
to pass to security_enclave_mprotect(), see below).
- SGX driver takes a reference to the backing sigstruct file if it
exists so that the file can be provided to LSMs during mprotect().
- Optional: SGX driver *requires* sigstruct to be backed by file, purely
to enforce userspace infrastructure is in place for LSM support.
W^X handling:
- mmap() to /dev/sgx/enclave only allowed with PROT_NONE, i.e. force
userspace through mprotect() to simplify the kernel implementation.
- Add vm_ops mprotect() ops hook (I'll refer to SGX's implementation
as SGX.mprotect())
- Take explicit ALLOW_WRITE at ADD_REGION, a.k.a. EADD
- ADD_REGION also used to describe EAUG region (tentatively for SGX2).
- Track "can be written at some point in time (past or future)" as
ALLOW_WRITE (to avoid confusiong with MAY_WRITE). A priori knowledge
of writability avoids having to track/coordinate PROT_WRITE across
VMAs and MMs.
- SGX.mprotect() returns -EPERM if PROT_WRITE && !ALLOW_WRITE.
- Add security_enclave_mprotect() LSM hook, called by SGX.mprotect(),
e.g. int security_enclave_mprotect(struct file *sigstruct,
unsigned long prot,
bool allow_write)
- Intention is that EXECMOD is required if PROT_EXEC and ALLOW_WRITE.
Enclave {white,black}listing:
- Optional/Future: add security_enclave_create(), invoked during
SGX ECREATE ioctl(), e.g.
int security_enclave_create(struct vm_area_struct *sigstruct)
- If this LSM hook is implemented, having sigstruct at ECREATE
allows LSMs to determine whether or not the enclave is allowed to
execute before allocating EPC for the enclave, e.g. unwanted enclaves
can't DoS wanted enclaves.
LSM implementation possibilities:
- Define ENCLAVE__EXECUTE and ENCLAVE__EXECMOD, require them on the
process. Does not require sigstruct to be backed by file, but cannot
achieve per-enclave granularity.
- Define ENCLAVE__EXECUTE and ENCLAVE__EXECMOD, require them on the
sigstruct, i.e. force sigstruct to reside in filesystem. Allows
per-enclave granularity.
- Reuse FILE__EXECUTE and FILE__EXECMOD on sigstruct. Likely has
implications that may or may not be concerning, e.g. the sigstruct
file itself is weirdly executable.
- Adding ENCLAVE__EXECUTE and ENCLAVE__EXECMOD means the sigstruct,
which may be emdedded in the same file as the enclave, does *not*
require FILE__EXECUTE or FILE__EXECMOD, e.g. can be read-only.
- LSMs can (will?) require ENCLAVE__EXECUTE and ENCLAVE__EXECMOD to
effectively map an enclave, even if the process acquired the enclave
via SCM_RIGHTS (enclaves are tracked by fds). This is good or bad
depending on your perspective.
Userspace changes:
- EADD ioctl adds flags param to take ALLOW_WRITE
- ECREATE ioctl takes sigstruct instead of EINIT
- Initial mmap() must be PROT_NONE.
- sigstruct likely needs to reside in a file (this may not affect
some userspace implementations).
^ permalink raw reply
* Re: [PATCH 00/10] keys: Miscellany [ver #2]
From: Eric Biggers @ 2019-05-30 18:12 UTC (permalink / raw)
To: David Howells
Cc: keyrings, Mat Martineau, James Morris, linux-security-module,
linux-kernel
In-Reply-To: <155923711088.949.14909672457214372214.stgit@warthog.procyon.org.uk>
On Thu, May 30, 2019 at 06:25:11PM +0100, David Howells wrote:
>
> Here are some miscellaneous keyrings fixes and improvements intended for
> the next merge window:
>
> (1) Fix a bunch of warnings from sparse, including missing RCU bits and
> kdoc-function argument mismatches
>
> (2) Implement a keyctl to allow a key to be moved from one keyring to
> another, with the option of prohibiting key replacement in the
> destination keyring.
>
> (3) Grant Link permission to possessors of request_key_auth tokens so that
> upcall servicing daemons can more easily arrange things such that only
> the necessary auth key is passed to the actual service program, and
> not all the auth keys a daemon might possesss.
>
> (4) Improvement in lookup_user_key().
>
> (5) Implement a keyctl to allow keyrings subsystem capabilities to be
> queried.
>
> The patches can be found on the following branch:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-misc
>
syzkaller still manages to crash something in the keys subsystem really quickly
when I run it on that branch (commit 35036b7e765b6):
RAX: ffffffffffffffda RBX: 000000000071bf00 RCX: 0000000000458a09
RDX: 0000000020001800 RSI: 00000000200017c0 RDI: 0000000020001780
RBP: 00007f784d775ca0 R08: fffffffffffffffd R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000246 R12: 00007f784d7766d4
R13: 00000000004a63d9 R14: 00000000006e33f8 R15: 0000000000000003
BUG: unable to handle page fault for address: ffffeba31fffffd0
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] SMP KASAN
CPU: 5 PID: 10320 Comm: syz-executor.3 Not tainted 5.2.0-rc1-00010-g35036b7e765b6 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
RIP: 0010:__read_once_size include/linux/compiler.h:194 [inline]
RIP: 0010:compound_head include/linux/page-flags.h:172 [inline]
RIP: 0010:virt_to_head_page include/linux/mm.h:720 [inline]
RIP: 0010:virt_to_cache mm/slab.c:376 [inline]
RIP: 0010:kfree+0x7f/0x1d0 mm/slab.c:3751
Code: 7f 77 00 00 48 01 d0 48 89 df 48 c1 e8 0c 48 8d 14 c5 00 00 00 00 48 29 c2 48 89 d0 48 ba 00 00 00 00 00 ea ff ff 48 8d 04 c2 <48> 8b 50 08 48 8d 4a ff 83 e2 01 48 0f 45 c1 4c 8b 68 18 49 63 75
RSP: 0018:ffff88800a7f7bf0 EFLAGS: 00010016
RAX: ffffeba31fffffc8 RBX: 0000003ffffffffc RCX: 0000000000000000
RDX: ffffea0000000000 RSI: 0000000000000000 RDI: 0000003ffffffffc
RBP: ffff88800a7f7c10 R08: ffffffff83bf24c0 R09: ffffed100da2e448
R10: 0000000000000001 R11: ffffed100da2e447 R12: 0000000000000202
R13: ffffffff824c2d76 R14: dffffc0000000000 R15: ffff88800f1cf000
FS: 00007f784d776700(0000) GS:ffff88806d140000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffeba31fffffd0 CR3: 000000006932d004 CR4: 0000000000760ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
assoc_array_cancel_edit+0x56/0xa0 lib/assoc_array.c:1428
__key_link_end+0x7e/0x170 security/keys/keyring.c:1360
key_create_or_update+0x868/0xbb0 security/keys/key.c:943
__do_sys_add_key security/keys/keyctl.c:134 [inline]
__se_sys_add_key+0x134/0x380 security/keys/keyctl.c:74
__x64_sys_add_key+0xbe/0x150 security/keys/keyctl.c:74
do_syscall_64+0x9e/0x4e0 arch/x86/entry/common.c:301
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x458a09
Code: dd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 ab b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f784d775c88 EFLAGS: 00000246 ORIG_RAX: 00000000000000f8
RAX: ffffffffffffffda RBX: 000000000071bf00 RCX: 0000000000458a09
RDX: 0000000020001800 RSI: 00000000200017c0 RDI: 0000000020001780
RBP: 00007f784d775ca0 R08: fffffffffffffffd R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000246 R12: 00007f784d7766d4
R13: 00000000004a63d9 R14: 00000000006e33f8 R15: 0000000000000003
Modules linked in:
Dumping ftrace buffer:
(ftrace buffer empty)
CR2: ffffeba31fffffd0
---[ end trace 01d64df35f47d1f5 ]---
RIP: 0010:__read_once_size include/linux/compiler.h:194 [inline]
RIP: 0010:compound_head include/linux/page-flags.h:172 [inline]
RIP: 0010:virt_to_head_page include/linux/mm.h:720 [inline]
RIP: 0010:virt_to_cache mm/slab.c:376 [inline]
RIP: 0010:kfree+0x7f/0x1d0 mm/slab.c:3751
Code: 7f 77 00 00 48 01 d0 48 89 df 48 c1 e8 0c 48 8d 14 c5 00 00 00 00 48 29 c2 48 89 d0 48 ba 00 00 00 00 00 ea ff ff 48 8d 04 c2 <48> 8b 50 08 48 8d 4a ff 83 e2 01 48 0f 45 c1 4c 8b 68 18 49 63 75
RSP: 0018:ffff88800a7f7bf0 EFLAGS: 00010016
RAX: ffffeba31fffffc8 RBX: 0000003ffffffffc RCX: 0000000000000000
RDX: ffffea0000000000 RSI: 0000000000000000 RDI: 0000003ffffffffc
RBP: ffff88800a7f7c10 R08: ffffffff83bf24c0 R09: ffffed100da2e448
R10: 0000000000000001 R11: ffffed100da2e447 R12: 0000000000000202
R13: ffffffff824c2d76 R14: dffffc0000000000 R15: ffff88800f1cf000
FS: 00007f784d776700(0000) GS:ffff88806d140000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffeba31fffffd0 CR3: 000000006932d004 CR4: 0000000000760ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
^ permalink raw reply
* Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)
From: Andy Lutomirski @ 2019-05-30 19:20 UTC (permalink / raw)
To: Sean Christopherson
Cc: Andy Lutomirski, Stephen Smalley, Xing, Cedric, William Roberts,
Jarkko Sakkinen, James Morris, Serge E. Hallyn, LSM List,
Paul Moore, Eric Paris, selinux@vger.kernel.org, Jethro Beekman,
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: <20190530180110.GB23930@linux.intel.com>
On Thu, May 30, 2019 at 11:01 AM Sean Christopherson
<sean.j.christopherson@intel.com> wrote:
>
> On Thu, May 30, 2019 at 09:14:10AM -0700, Andy Lutomirski wrote:
> > On Thu, May 30, 2019 at 8:04 AM Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > >
> > > On 5/30/19 10:31 AM, Andy Lutomirski wrote:
> > > > Hi all-
> > > >
> > > > After an offline discussion with Sean yesterday, here are some updates
> > > > to the user API parts of my proposal.
> > > >
> > > > Unfortunately, Sean convinced me that MAXPERM doesn't work the way I
> > > > described it because, for SGX2, the enclave loader won't know at load
> > > > time whether a given EAUG-ed page will ever be executed. So here's an
> > > > update.
> > > >
> > > > First, here are the requrements as I see them, where EXECUTE, EXECMOD,
> > > > and EXECMEM could be substituted with other rules at the LSM's
> > > > discretion:
> > > >
> > > > - You can create a WX or RWX mapping if and only if you have EXECMEM.
> > > >
> > > > - To create an X mapping of an enclave page that has ever been W, you
> > > > need EXECMOD.
> > >
> > > EXECMOD to what file? The enclave file from which the page's content
> > > originated, the sigstruct file, or /dev/sgx/enclave?
> >
> > I leave that decision to you :) The user should need permission to do
> > an execmod thing on an enclave, however that wants to be encoded.
>
> But that decision dictates how the SGX API handles sigstruct. If LSMs
> want to associate EXECMOD with sigstruct, then SGX needs to take sigstruct
> early and hold a reference to the file for the lifetime of the enclave.
> And if we're going to do that, the whole approach of inheriting
> permissions from source VMAs becomes unnecessary complexity.
>
> > >
> > > > - To create an X mapping of an enclave page that came from EADD, you
> > > > need EXECUTE on the source file. Optionally, we could also permit
> > > > this if you have EXECMOD.
> > >
> > > What is the "source file" i.e. the target of the check? Enclave file,
> > > sigstruct file, or /dev/sgx/enclave?
> >
> > Enclave file -- that is, the file backing the vma from which the data is loaded.
>
> It wasn't explicitly called out in Andy's proposal(s), but the idea is
> that the SGX driver would effectively inherit permissions from the source
> VMA (EADD needs a source for the initial value of the encave page).
I actually meant for it to *not* work like this. I don't want the
source VMA to have to be VM_EXEC. I think the LSM should just check
permissions on ->vm_file.
^ permalink raw reply
* [PATCH v2] Allow to exclude specific file types in LoadPin
From: Ke Wu @ 2019-05-30 19:22 UTC (permalink / raw)
To: Kees Cook, Jonathan Corbet, James Morris, Serge E. Hallyn
Cc: linux-doc, linux-kernel, linux-security-module, Ke Wu
In-Reply-To: <20190529224350.6460-1-mikewu@google.com>
Linux kernel already provide MODULE_SIG and KEXEC_VERIFY_SIG to
make sure loaded kernel module and kernel image are trusted. This
patch adds a kernel command line option "loadpin.exclude" which
allows to exclude specific file types from LoadPin. This is useful
when people want to use different mechanisms to verify module and
kernel image while still use LoadPin to protect the integrity of
other files kernel loads.
Signed-off-by: Ke Wu <mikewu@google.com>
---
Changelog since v1:
- Mark ignore_read_file_id with __ro_after_init.
- Mark parse_exclude() with __init.
- Use ARRAY_SIZE(ignore_read_file_id) instead of READING_MAX_ID.
Documentation/admin-guide/LSM/LoadPin.rst | 10 ++++++
security/loadpin/loadpin.c | 38 +++++++++++++++++++++++
2 files changed, 48 insertions(+)
diff --git a/Documentation/admin-guide/LSM/LoadPin.rst b/Documentation/admin-guide/LSM/LoadPin.rst
index 32070762d24c..716ad9b23c9a 100644
--- a/Documentation/admin-guide/LSM/LoadPin.rst
+++ b/Documentation/admin-guide/LSM/LoadPin.rst
@@ -19,3 +19,13 @@ block device backing the filesystem is not read-only, a sysctl is
created to toggle pinning: ``/proc/sys/kernel/loadpin/enabled``. (Having
a mutable filesystem means pinning is mutable too, but having the
sysctl allows for easy testing on systems with a mutable filesystem.)
+
+It's also possible to exclude specific file types from LoadPin using kernel
+command line option "``loadpin.exclude``". By default, all files are
+included, but they can be excluded using kernel command line option such
+as "``loadpin.exclude=kernel-module,kexec-image``". This allows to use
+different mechanisms such as ``CONFIG_MODULE_SIG`` and
+``CONFIG_KEXEC_VERIFY_SIG`` to verify kernel module and kernel image while
+still use LoadPin to protect the integrity of other files kernel loads. The
+full list of valid file types can be found in ``kernel_read_file_str``
+defined in ``include/linux/fs.h``.
diff --git a/security/loadpin/loadpin.c b/security/loadpin/loadpin.c
index 055fb0a64169..d5f064644c54 100644
--- a/security/loadpin/loadpin.c
+++ b/security/loadpin/loadpin.c
@@ -45,6 +45,8 @@ static void report_load(const char *origin, struct file *file, char *operation)
}
static int enforce = IS_ENABLED(CONFIG_SECURITY_LOADPIN_ENFORCE);
+static char *exclude_read_files[READING_MAX_ID];
+static int ignore_read_file_id[READING_MAX_ID] __ro_after_init;
static struct super_block *pinned_root;
static DEFINE_SPINLOCK(pinned_root_spinlock);
@@ -129,6 +131,13 @@ static int loadpin_read_file(struct file *file, enum kernel_read_file_id id)
struct super_block *load_root;
const char *origin = kernel_read_file_id_str(id);
+ /* If the file id is excluded, ignore the pinning. */
+ if ((unsigned int)id < ARRAY_SIZE(ignore_read_file_id) &&
+ ignore_read_file_id[id]) {
+ report_load(origin, file, "pinning-excluded");
+ return 0;
+ }
+
/* This handles the older init_module API that has a NULL file. */
if (!file) {
if (!enforce) {
@@ -187,10 +196,37 @@ static struct security_hook_list loadpin_hooks[] __lsm_ro_after_init = {
LSM_HOOK_INIT(kernel_load_data, loadpin_load_data),
};
+static void __init parse_exclude(void)
+{
+ int i, j;
+ char *cur;
+
+ for (i = 0; i < ARRAY_SIZE(exclude_read_files); i++) {
+ cur = exclude_read_files[i];
+ if (!cur)
+ break;
+ if (*cur == '\0')
+ continue;
+
+ for (j = 0; j < ARRAY_SIZE(kernel_read_file_str); j++) {
+ if (strcmp(cur, kernel_read_file_str[j]) == 0) {
+ pr_info("excluding: %s\n",
+ kernel_read_file_str[j]);
+ ignore_read_file_id[j] = 1;
+ /*
+ * Can not break, because one read_file_str
+ * may map to more than on read_file_id.
+ */
+ }
+ }
+ }
+}
+
static int __init loadpin_init(void)
{
pr_info("ready to pin (currently %senforcing)\n",
enforce ? "" : "not ");
+ parse_exclude();
security_add_hooks(loadpin_hooks, ARRAY_SIZE(loadpin_hooks), "loadpin");
return 0;
}
@@ -203,3 +239,5 @@ DEFINE_LSM(loadpin) = {
/* Should not be mutable after boot, so not listed in sysfs (perm == 0). */
module_param(enforce, int, 0);
MODULE_PARM_DESC(enforce, "Enforce module/firmware pinning");
+module_param_array_named(exclude, exclude_read_files, charp, NULL, 0);
+MODULE_PARM_DESC(exclude, "Exclude pinning specific read file types");
--
2.22.0.rc1.257.g3120a18244-goog
^ permalink raw reply related
* Re: [PATCH v2] Allow to exclude specific file types in LoadPin
From: James Morris @ 2019-05-30 20:11 UTC (permalink / raw)
To: Ke Wu
Cc: Kees Cook, Jonathan Corbet, Serge E. Hallyn, linux-doc,
linux-kernel, linux-security-module
In-Reply-To: <20190530192208.99773-1-mikewu@google.com>
On Thu, 30 May 2019, Ke Wu wrote:
> Linux kernel already provide MODULE_SIG and KEXEC_VERIFY_SIG to
> make sure loaded kernel module and kernel image are trusted. This
> patch adds a kernel command line option "loadpin.exclude" which
> allows to exclude specific file types from LoadPin. This is useful
> when people want to use different mechanisms to verify module and
> kernel image while still use LoadPin to protect the integrity of
> other files kernel loads.
>
> Signed-off-by: Ke Wu <mikewu@google.com>
> ---
> Changelog since v1:
> - Mark ignore_read_file_id with __ro_after_init.
> - Mark parse_exclude() with __init.
> - Use ARRAY_SIZE(ignore_read_file_id) instead of READING_MAX_ID.
Looks good!
Reviewed-by: James Morris <jamorris@linux.microsoft.com>
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH 00/10] keys: Miscellany [ver #2]
From: David Howells @ 2019-05-30 21:11 UTC (permalink / raw)
To: Eric Biggers
Cc: dhowells, keyrings, Mat Martineau, James Morris,
linux-security-module, linux-kernel
In-Reply-To: <20190530181248.GC70051@gmail.com>
Eric Biggers <ebiggers@kernel.org> wrote:
> key_create_or_update+0x868/0xbb0 security/keys/key.c:943
I forgot to init edit:
struct assoc_array_edit *edit;
to NULL.
David
^ permalink raw reply
* Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)
From: Sean Christopherson @ 2019-05-30 21:16 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Stephen Smalley, Xing, Cedric, William Roberts, Jarkko Sakkinen,
James Morris, Serge E. Hallyn, LSM List, Paul Moore, Eric Paris,
selinux@vger.kernel.org, Jethro Beekman, 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: <CALCETrX2PgUc_jetXHqp85aaS0a0jHB8E7=T1rsW+5vyRgwnUA@mail.gmail.com>
On Thu, May 30, 2019 at 12:20:45PM -0700, Andy Lutomirski wrote:
> On Thu, May 30, 2019 at 11:01 AM Sean Christopherson
> <sean.j.christopherson@intel.com> wrote:
> >
> > On Thu, May 30, 2019 at 09:14:10AM -0700, Andy Lutomirski wrote:
> > > Enclave file -- that is, the file backing the vma from which the data is loaded.
> >
> > It wasn't explicitly called out in Andy's proposal(s), but the idea is
> > that the SGX driver would effectively inherit permissions from the source
> > VMA (EADD needs a source for the initial value of the encave page).
>
> I actually meant for it to *not* work like this. I don't want the
> source VMA to have to be VM_EXEC. I think the LSM should just check
> permissions on ->vm_file.
But if ->vm_file is NULL, i.e. the enclave is not backed by a file,
then PROCESS__EXECMEM is required (or more likely, ENCLAVE__EXECMEM).
In practice, it's the same net effect of using sigstruct as a proxy,
i.e. *something* has to get to the file system to avoid EXECMEM. But
putting the entire enclave to the filesystem seems like a heaver lift
than dumping the sigstruct.
And if sigstruct needs to be in the file system for
security_enclave_create/init()...
^ permalink raw reply
* RE: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)
From: Xing, Cedric @ 2019-05-30 21:48 UTC (permalink / raw)
To: Andy Lutomirski, Christopherson, Sean J
Cc: Stephen Smalley, William Roberts, Jarkko Sakkinen, James Morris,
Serge E. Hallyn, LSM List, Paul Moore, Eric Paris,
selinux@vger.kernel.org, Jethro Beekman, 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: <CALCETrX2PgUc_jetXHqp85aaS0a0jHB8E7=T1rsW+5vyRgwnUA@mail.gmail.com>
Hi Andy,
I'm just curious how Sean convinced you that "MAXPERM doesn't work". More specifically, I'm objecting to the statement of "the enclave loader won't know at load time whether a given EAUG-ed page will ever be executed".
I'm still new to LSM so my understanding may not be correct. But I think LSM policy defines a boundary that "loosely" restricts what a process can do. By "loosely", I mean it is usually more permissive than a process needs. For example, FILE__EXECMOD basically says there are self-modifying code in a file, but it isn't specific on which pages contain self-modifying code, hence *all* pages are allowed mprotect(RW->RX) even though only a (small) subset actually need it. LSM policies are static too, as FILE__EXECMOD is given by a system admin to be associated with the disk file, instead of being requested/programmed by any processes loading/mapping that file.
So I think the same rationale applies to enclaves. Your original idea of MAXPERM is the policy set forth by system admin and shall *never* change at runtime. If an enclave is dynamically linked and needs to bring in code pages at runtime, the admin needs to enable it by setting, say ENCLAVE__EXECMOD, in the sigstruct file. Then all EAUG'ed pages will receive RWX as MAXPERM. The process would then mprotect() selective pages to be RX but which exact set of pages doesn't concern LSM usually.
> From: Andy Lutomirski [mailto:luto@kernel.org]
> Sent: Thursday, May 30, 2019 12:21 PM
>
> On Thu, May 30, 2019 at 11:01 AM Sean Christopherson <sean.j.christopherson@intel.com>
> wrote:
> >
> > On Thu, May 30, 2019 at 09:14:10AM -0700, Andy Lutomirski wrote:
> > > On Thu, May 30, 2019 at 8:04 AM Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > > >
> > > > On 5/30/19 10:31 AM, Andy Lutomirski wrote:
> > > > > Hi all-
> > > > >
> > > > > After an offline discussion with Sean yesterday, here are some
> > > > > updates to the user API parts of my proposal.
> > > > >
> > > > > Unfortunately, Sean convinced me that MAXPERM doesn't work the
> > > > > way I described it because, for SGX2, the enclave loader won't
> > > > > know at load time whether a given EAUG-ed page will ever be
> > > > > executed. So here's an update.
> > > > >
> > > > > First, here are the requrements as I see them, where EXECUTE,
> > > > > EXECMOD, and EXECMEM could be substituted with other rules at
> > > > > the LSM's
> > > > > discretion:
> > > > >
> > > > > - You can create a WX or RWX mapping if and only if you have EXECMEM.
> > > > >
> > > > > - To create an X mapping of an enclave page that has ever been
> > > > > W, you need EXECMOD.
> > > >
> > > > EXECMOD to what file? The enclave file from which the page's
> > > > content originated, the sigstruct file, or /dev/sgx/enclave?
> > >
> > > I leave that decision to you :) The user should need permission to
> > > do an execmod thing on an enclave, however that wants to be encoded.
> >
> > But that decision dictates how the SGX API handles sigstruct. If LSMs
> > want to associate EXECMOD with sigstruct, then SGX needs to take
> > sigstruct early and hold a reference to the file for the lifetime of the enclave.
> > And if we're going to do that, the whole approach of inheriting
> > permissions from source VMAs becomes unnecessary complexity.
> >
> > > >
> > > > > - To create an X mapping of an enclave page that came from
> > > > > EADD, you need EXECUTE on the source file. Optionally, we could
> > > > > also permit this if you have EXECMOD.
> > > >
> > > > What is the "source file" i.e. the target of the check? Enclave
> > > > file, sigstruct file, or /dev/sgx/enclave?
> > >
> > > Enclave file -- that is, the file backing the vma from which the data is loaded.
> >
> > It wasn't explicitly called out in Andy's proposal(s), but the idea is
> > that the SGX driver would effectively inherit permissions from the
> > source VMA (EADD needs a source for the initial value of the encave page).
>
> I actually meant for it to *not* work like this. I don't want the source VMA to have to
> be VM_EXEC. I think the LSM should just check permissions on ->vm_file.
-Cedric
^ permalink raw reply
* Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)
From: Sean Christopherson @ 2019-05-30 21:36 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Stephen Smalley, Xing, Cedric, William Roberts, Jarkko Sakkinen,
James Morris, Serge E. Hallyn, LSM List, Paul Moore, Eric Paris,
selinux@vger.kernel.org, Jethro Beekman, 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: <CALCETrVAoDppmdJzkpwagt3q64M-QpNajXbKGR1yQdqyofeANQ@mail.gmail.com>
On Thu, May 30, 2019 at 02:23:07PM -0700, Andy Lutomirski wrote:
> On Thu, May 30, 2019 at 2:16 PM Sean Christopherson
> <sean.j.christopherson@intel.com> wrote:
> >
> > On Thu, May 30, 2019 at 12:20:45PM -0700, Andy Lutomirski wrote:
> > > On Thu, May 30, 2019 at 11:01 AM Sean Christopherson
> > > <sean.j.christopherson@intel.com> wrote:
> > > >
> > > > On Thu, May 30, 2019 at 09:14:10AM -0700, Andy Lutomirski wrote:
> > > > > Enclave file -- that is, the file backing the vma from which the data is loaded.
> > > >
> > > > It wasn't explicitly called out in Andy's proposal(s), but the idea is
> > > > that the SGX driver would effectively inherit permissions from the source
> > > > VMA (EADD needs a source for the initial value of the encave page).
> > >
> > > I actually meant for it to *not* work like this. I don't want the
> > > source VMA to have to be VM_EXEC. I think the LSM should just check
> > > permissions on ->vm_file.
> >
> > But if ->vm_file is NULL, i.e. the enclave is not backed by a file,
> > then PROCESS__EXECMEM is required (or more likely, ENCLAVE__EXECMEM).
> >
>
> If ->vm_file is NULL, then I think some privilege is needed. I
> suppose the policy could have a new lesser permission EXECUNTRUSTED
> which is like EXECMOD but you can't modify it. I'm not convinced this
> is particular important.
Assuming MRENCLAVE generated by Graphene or any other hosting scheme are
stable[1], then avoiding EXEC<whatever> means the user can effectively
whitelist what enclaves are runnable by Graphene, even if the kernel
doesn't implement security_enclave_create/init().
I agree that it probably isn't all that important, it's more of a "why
not" argument, i.e. what is gained by not using sigstruct as a proxy?
[1] What in the world is being attested if MRENCLAVE isn't stable?
^ permalink raw reply
* Re: [PATCH 00/10] keys: Miscellany [ver #2]
From: David Howells @ 2019-05-30 22:03 UTC (permalink / raw)
To: Eric Biggers
Cc: dhowells, keyrings, Mat Martineau, James Morris,
linux-security-module, linux-kernel
In-Reply-To: <20190530181248.GC70051@gmail.com>
Eric Biggers <ebiggers@kernel.org> wrote:
> syzkaller still manages to crash something in the keys subsystem really
> quickly when I run it on that branch (commit 35036b7e765b6):
I've pushed a new version that should fix that, thanks.
David
^ permalink raw reply
* Re: [PATCH v2] Allow to exclude specific file types in LoadPin
From: Kees Cook @ 2019-05-30 21:42 UTC (permalink / raw)
To: Ke Wu, James Morris
Cc: Jonathan Corbet, Serge E. Hallyn, linux-doc, linux-kernel,
linux-security-module
In-Reply-To: <20190530192208.99773-1-mikewu@google.com>
On Thu, May 30, 2019 at 12:22:08PM -0700, Ke Wu wrote:
> Linux kernel already provide MODULE_SIG and KEXEC_VERIFY_SIG to
> make sure loaded kernel module and kernel image are trusted. This
> patch adds a kernel command line option "loadpin.exclude" which
> allows to exclude specific file types from LoadPin. This is useful
> when people want to use different mechanisms to verify module and
> kernel image while still use LoadPin to protect the integrity of
> other files kernel loads.
>
> Signed-off-by: Ke Wu <mikewu@google.com>
Thanks for the updates!
Acked-by: Kees Cook <keescook@chromium.org>
James, I don't have anything else planned for loadpin this cycle. Do you
want me to push this to Linus in the next cycle, or do you want to take
it into one of your trees?
Thanks!
-Kees
> ---
> Changelog since v1:
> - Mark ignore_read_file_id with __ro_after_init.
> - Mark parse_exclude() with __init.
> - Use ARRAY_SIZE(ignore_read_file_id) instead of READING_MAX_ID.
>
>
> Documentation/admin-guide/LSM/LoadPin.rst | 10 ++++++
> security/loadpin/loadpin.c | 38 +++++++++++++++++++++++
> 2 files changed, 48 insertions(+)
>
> diff --git a/Documentation/admin-guide/LSM/LoadPin.rst b/Documentation/admin-guide/LSM/LoadPin.rst
> index 32070762d24c..716ad9b23c9a 100644
> --- a/Documentation/admin-guide/LSM/LoadPin.rst
> +++ b/Documentation/admin-guide/LSM/LoadPin.rst
> @@ -19,3 +19,13 @@ block device backing the filesystem is not read-only, a sysctl is
> created to toggle pinning: ``/proc/sys/kernel/loadpin/enabled``. (Having
> a mutable filesystem means pinning is mutable too, but having the
> sysctl allows for easy testing on systems with a mutable filesystem.)
> +
> +It's also possible to exclude specific file types from LoadPin using kernel
> +command line option "``loadpin.exclude``". By default, all files are
> +included, but they can be excluded using kernel command line option such
> +as "``loadpin.exclude=kernel-module,kexec-image``". This allows to use
> +different mechanisms such as ``CONFIG_MODULE_SIG`` and
> +``CONFIG_KEXEC_VERIFY_SIG`` to verify kernel module and kernel image while
> +still use LoadPin to protect the integrity of other files kernel loads. The
> +full list of valid file types can be found in ``kernel_read_file_str``
> +defined in ``include/linux/fs.h``.
> diff --git a/security/loadpin/loadpin.c b/security/loadpin/loadpin.c
> index 055fb0a64169..d5f064644c54 100644
> --- a/security/loadpin/loadpin.c
> +++ b/security/loadpin/loadpin.c
> @@ -45,6 +45,8 @@ static void report_load(const char *origin, struct file *file, char *operation)
> }
>
> static int enforce = IS_ENABLED(CONFIG_SECURITY_LOADPIN_ENFORCE);
> +static char *exclude_read_files[READING_MAX_ID];
> +static int ignore_read_file_id[READING_MAX_ID] __ro_after_init;
> static struct super_block *pinned_root;
> static DEFINE_SPINLOCK(pinned_root_spinlock);
>
> @@ -129,6 +131,13 @@ static int loadpin_read_file(struct file *file, enum kernel_read_file_id id)
> struct super_block *load_root;
> const char *origin = kernel_read_file_id_str(id);
>
> + /* If the file id is excluded, ignore the pinning. */
> + if ((unsigned int)id < ARRAY_SIZE(ignore_read_file_id) &&
> + ignore_read_file_id[id]) {
> + report_load(origin, file, "pinning-excluded");
> + return 0;
> + }
> +
> /* This handles the older init_module API that has a NULL file. */
> if (!file) {
> if (!enforce) {
> @@ -187,10 +196,37 @@ static struct security_hook_list loadpin_hooks[] __lsm_ro_after_init = {
> LSM_HOOK_INIT(kernel_load_data, loadpin_load_data),
> };
>
> +static void __init parse_exclude(void)
> +{
> + int i, j;
> + char *cur;
> +
> + for (i = 0; i < ARRAY_SIZE(exclude_read_files); i++) {
> + cur = exclude_read_files[i];
> + if (!cur)
> + break;
> + if (*cur == '\0')
> + continue;
> +
> + for (j = 0; j < ARRAY_SIZE(kernel_read_file_str); j++) {
> + if (strcmp(cur, kernel_read_file_str[j]) == 0) {
> + pr_info("excluding: %s\n",
> + kernel_read_file_str[j]);
> + ignore_read_file_id[j] = 1;
> + /*
> + * Can not break, because one read_file_str
> + * may map to more than on read_file_id.
> + */
> + }
> + }
> + }
> +}
> +
> static int __init loadpin_init(void)
> {
> pr_info("ready to pin (currently %senforcing)\n",
> enforce ? "" : "not ");
> + parse_exclude();
> security_add_hooks(loadpin_hooks, ARRAY_SIZE(loadpin_hooks), "loadpin");
> return 0;
> }
> @@ -203,3 +239,5 @@ DEFINE_LSM(loadpin) = {
> /* Should not be mutable after boot, so not listed in sysfs (perm == 0). */
> module_param(enforce, int, 0);
> MODULE_PARM_DESC(enforce, "Enforce module/firmware pinning");
> +module_param_array_named(exclude, exclude_read_files, charp, NULL, 0);
> +MODULE_PARM_DESC(exclude, "Exclude pinning specific read file types");
> --
> 2.22.0.rc1.257.g3120a18244-goog
>
--
Kees Cook
^ permalink raw reply
* Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)
From: Andy Lutomirski @ 2019-05-30 21:23 UTC (permalink / raw)
To: Sean Christopherson
Cc: Andy Lutomirski, Stephen Smalley, Xing, Cedric, William Roberts,
Jarkko Sakkinen, James Morris, Serge E. Hallyn, LSM List,
Paul Moore, Eric Paris, selinux@vger.kernel.org, Jethro Beekman,
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: <20190530211645.GB27551@linux.intel.com>
On Thu, May 30, 2019 at 2:16 PM Sean Christopherson
<sean.j.christopherson@intel.com> wrote:
>
> On Thu, May 30, 2019 at 12:20:45PM -0700, Andy Lutomirski wrote:
> > On Thu, May 30, 2019 at 11:01 AM Sean Christopherson
> > <sean.j.christopherson@intel.com> wrote:
> > >
> > > On Thu, May 30, 2019 at 09:14:10AM -0700, Andy Lutomirski wrote:
> > > > Enclave file -- that is, the file backing the vma from which the data is loaded.
> > >
> > > It wasn't explicitly called out in Andy's proposal(s), but the idea is
> > > that the SGX driver would effectively inherit permissions from the source
> > > VMA (EADD needs a source for the initial value of the encave page).
> >
> > I actually meant for it to *not* work like this. I don't want the
> > source VMA to have to be VM_EXEC. I think the LSM should just check
> > permissions on ->vm_file.
>
> But if ->vm_file is NULL, i.e. the enclave is not backed by a file,
> then PROCESS__EXECMEM is required (or more likely, ENCLAVE__EXECMEM).
>
If ->vm_file is NULL, then I think some privilege is needed. I
suppose the policy could have a new lesser permission EXECUNTRUSTED
which is like EXECMOD but you can't modify it. I'm not convinced this
is particular important.
^ permalink raw reply
* Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)
From: Sean Christopherson @ 2019-05-30 22:24 UTC (permalink / raw)
To: Xing, Cedric
Cc: Andy Lutomirski, Stephen Smalley, William Roberts,
Jarkko Sakkinen, James Morris, Serge E. Hallyn, LSM List,
Paul Moore, Eric Paris, selinux@vger.kernel.org, Jethro Beekman,
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: <960B34DE67B9E140824F1DCDEC400C0F654EB8BA@ORSMSX116.amr.corp.intel.com>
On Thu, May 30, 2019 at 02:48:43PM -0700, Xing, Cedric wrote:
> So I think the same rationale applies to enclaves. Your original idea of
> MAXPERM is the policy set forth by system admin and shall *never* change at
> runtime. If an enclave is dynamically linked and needs to bring in code pages
> at runtime, the admin needs to enable it by setting, say ENCLAVE__EXECMOD, in
> the sigstruct file. Then all EAUG'ed pages will receive RWX as MAXPERM. The
> process would then mprotect() selective pages to be RX but which exact set of
> pages doesn't concern LSM usually.
Because passing RWX means the enclave "requires" EXECMOD even if it never
actually does a RW->RX transition. It's not broken per se, but at the
very least it's decidedly odd.
Dynamically detecting the EXECMOD case is not difficult and has the
advantage of simplifying userspace loaders, e.g. all EAUG pages are tagged
ALLOW_WRITE and the kernel takes care of the rest.
I *think* auditing/learning is also messed up with a MAXPERMS approach, as
mprotect() would fail (due to MAXPERMS clearing MAY_{READ,WRITE,EXEC})
before it calls security_file_mprotect(). Hooking mprotect() is the
obvious workaround, but then it's looking a lot like the new proposals.
In other words, the new proposals are rooted in the MAXPERMS concept, e.g.
MAXPERM is effectively "I want EXECMOD", which gets distilled down to
ALLOW_WRITE (or ALLOW_EXEC in Andy's proposal).
^ permalink raw reply
* Re: [PATCH 22/22] docs: fix broken documentation links
From: Michael S. Tsirkin @ 2019-05-30 22:49 UTC (permalink / raw)
To: Federico Vaga
Cc: Linux Doc Mailing List, linux-kernel, 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: <1574052.9PXfBvmXpz@harkonnen>
On Thu, May 30, 2019 at 10:17:32PM +0200, Federico Vaga wrote:
> On Thursday, May 30, 2019 1:23:53 AM CEST Mauro Carvalho Chehab wrote:
> > Mostly due to x86 and acpi conversion, several documentation
> > links are still pointing to the old file. Fix them.
>
> For the Italian documentation I just send I patch to fix them in a dedicated
> patch
Acked-by: Michael S. Tsirkin <mst@redhat.com>
for the vhost change.
> >
> > 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/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 +-
> > 48 files changed, 77 insertions(+), 78 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..4a02d1346635 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/virtual/kvm/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
> > 850be9696931..1252617b520f 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/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>`
> >
> > 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
> >
> > @@ -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:
> >
> > 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 5cfbea4ce575..a38d7273705a 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
* Re: [PATCH v2] Allow to exclude specific file types in LoadPin
From: James Morris @ 2019-05-31 0:59 UTC (permalink / raw)
To: Kees Cook
Cc: Ke Wu, Jonathan Corbet, Serge E. Hallyn, linux-doc, linux-kernel,
linux-security-module
In-Reply-To: <201905301440.1DC01275@keescook>
On Thu, 30 May 2019, Kees Cook wrote:
> On Thu, May 30, 2019 at 12:22:08PM -0700, Ke Wu wrote:
> > Linux kernel already provide MODULE_SIG and KEXEC_VERIFY_SIG to
> > make sure loaded kernel module and kernel image are trusted. This
> > patch adds a kernel command line option "loadpin.exclude" which
> > allows to exclude specific file types from LoadPin. This is useful
> > when people want to use different mechanisms to verify module and
> > kernel image while still use LoadPin to protect the integrity of
> > other files kernel loads.
> >
> > Signed-off-by: Ke Wu <mikewu@google.com>
>
> Thanks for the updates!
>
> Acked-by: Kees Cook <keescook@chromium.org>
>
> James, I don't have anything else planned for loadpin this cycle. Do you
> want me to push this to Linus in the next cycle, or do you want to take
> it into one of your trees?
You should push it directly to Linus.
>
> Thanks!
>
> -Kees
>
> > ---
> > Changelog since v1:
> > - Mark ignore_read_file_id with __ro_after_init.
> > - Mark parse_exclude() with __init.
> > - Use ARRAY_SIZE(ignore_read_file_id) instead of READING_MAX_ID.
> >
> >
> > Documentation/admin-guide/LSM/LoadPin.rst | 10 ++++++
> > security/loadpin/loadpin.c | 38 +++++++++++++++++++++++
> > 2 files changed, 48 insertions(+)
> >
> > diff --git a/Documentation/admin-guide/LSM/LoadPin.rst b/Documentation/admin-guide/LSM/LoadPin.rst
> > index 32070762d24c..716ad9b23c9a 100644
> > --- a/Documentation/admin-guide/LSM/LoadPin.rst
> > +++ b/Documentation/admin-guide/LSM/LoadPin.rst
> > @@ -19,3 +19,13 @@ block device backing the filesystem is not read-only, a sysctl is
> > created to toggle pinning: ``/proc/sys/kernel/loadpin/enabled``. (Having
> > a mutable filesystem means pinning is mutable too, but having the
> > sysctl allows for easy testing on systems with a mutable filesystem.)
> > +
> > +It's also possible to exclude specific file types from LoadPin using kernel
> > +command line option "``loadpin.exclude``". By default, all files are
> > +included, but they can be excluded using kernel command line option such
> > +as "``loadpin.exclude=kernel-module,kexec-image``". This allows to use
> > +different mechanisms such as ``CONFIG_MODULE_SIG`` and
> > +``CONFIG_KEXEC_VERIFY_SIG`` to verify kernel module and kernel image while
> > +still use LoadPin to protect the integrity of other files kernel loads. The
> > +full list of valid file types can be found in ``kernel_read_file_str``
> > +defined in ``include/linux/fs.h``.
> > diff --git a/security/loadpin/loadpin.c b/security/loadpin/loadpin.c
> > index 055fb0a64169..d5f064644c54 100644
> > --- a/security/loadpin/loadpin.c
> > +++ b/security/loadpin/loadpin.c
> > @@ -45,6 +45,8 @@ static void report_load(const char *origin, struct file *file, char *operation)
> > }
> >
> > static int enforce = IS_ENABLED(CONFIG_SECURITY_LOADPIN_ENFORCE);
> > +static char *exclude_read_files[READING_MAX_ID];
> > +static int ignore_read_file_id[READING_MAX_ID] __ro_after_init;
> > static struct super_block *pinned_root;
> > static DEFINE_SPINLOCK(pinned_root_spinlock);
> >
> > @@ -129,6 +131,13 @@ static int loadpin_read_file(struct file *file, enum kernel_read_file_id id)
> > struct super_block *load_root;
> > const char *origin = kernel_read_file_id_str(id);
> >
> > + /* If the file id is excluded, ignore the pinning. */
> > + if ((unsigned int)id < ARRAY_SIZE(ignore_read_file_id) &&
> > + ignore_read_file_id[id]) {
> > + report_load(origin, file, "pinning-excluded");
> > + return 0;
> > + }
> > +
> > /* This handles the older init_module API that has a NULL file. */
> > if (!file) {
> > if (!enforce) {
> > @@ -187,10 +196,37 @@ static struct security_hook_list loadpin_hooks[] __lsm_ro_after_init = {
> > LSM_HOOK_INIT(kernel_load_data, loadpin_load_data),
> > };
> >
> > +static void __init parse_exclude(void)
> > +{
> > + int i, j;
> > + char *cur;
> > +
> > + for (i = 0; i < ARRAY_SIZE(exclude_read_files); i++) {
> > + cur = exclude_read_files[i];
> > + if (!cur)
> > + break;
> > + if (*cur == '\0')
> > + continue;
> > +
> > + for (j = 0; j < ARRAY_SIZE(kernel_read_file_str); j++) {
> > + if (strcmp(cur, kernel_read_file_str[j]) == 0) {
> > + pr_info("excluding: %s\n",
> > + kernel_read_file_str[j]);
> > + ignore_read_file_id[j] = 1;
> > + /*
> > + * Can not break, because one read_file_str
> > + * may map to more than on read_file_id.
> > + */
> > + }
> > + }
> > + }
> > +}
> > +
> > static int __init loadpin_init(void)
> > {
> > pr_info("ready to pin (currently %senforcing)\n",
> > enforce ? "" : "not ");
> > + parse_exclude();
> > security_add_hooks(loadpin_hooks, ARRAY_SIZE(loadpin_hooks), "loadpin");
> > return 0;
> > }
> > @@ -203,3 +239,5 @@ DEFINE_LSM(loadpin) = {
> > /* Should not be mutable after boot, so not listed in sysfs (perm == 0). */
> > module_param(enforce, int, 0);
> > MODULE_PARM_DESC(enforce, "Enforce module/firmware pinning");
> > +module_param_array_named(exclude, exclude_read_files, charp, NULL, 0);
> > +MODULE_PARM_DESC(exclude, "Exclude pinning specific read file types");
> > --
> > 2.22.0.rc1.257.g3120a18244-goog
> >
>
>
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH v2] Allow to exclude specific file types in LoadPin
From: Kees Cook @ 2019-05-31 2:23 UTC (permalink / raw)
To: Ke Wu
Cc: James Morris, Jonathan Corbet, Serge E. Hallyn, linux-doc,
linux-kernel, linux-security-module
In-Reply-To: <alpine.LRH.2.21.1905310611190.26428@namei.org>
On Fri, May 31, 2019 at 06:11:44AM +1000, James Morris wrote:
> On Thu, 30 May 2019, Ke Wu wrote:
>
> > Linux kernel already provide MODULE_SIG and KEXEC_VERIFY_SIG to
> > make sure loaded kernel module and kernel image are trusted. This
> > patch adds a kernel command line option "loadpin.exclude" which
> > allows to exclude specific file types from LoadPin. This is useful
> > when people want to use different mechanisms to verify module and
> > kernel image while still use LoadPin to protect the integrity of
> > other files kernel loads.
> >
> > Signed-off-by: Ke Wu <mikewu@google.com>
> > ---
> > Changelog since v1:
> > - Mark ignore_read_file_id with __ro_after_init.
> > - Mark parse_exclude() with __init.
> > - Use ARRAY_SIZE(ignore_read_file_id) instead of READING_MAX_ID.
>
> Looks good!
>
> Reviewed-by: James Morris <jamorris@linux.microsoft.com>
Thanks! Applied to my for-next/loadpin branch at
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git
and should be visible in linux-next in a few days.
--
Kees Cook
^ permalink raw reply
* Re: [PATCH v2] Allow to exclude specific file types in LoadPin
From: Ke Wu @ 2019-05-31 5:54 UTC (permalink / raw)
To: Kees Cook
Cc: James Morris, Jonathan Corbet, Serge E. Hallyn, linux-doc,
linux-kernel, linux-security-module
In-Reply-To: <201905301921.AE6D8D1@keescook>
Thanks for pushing the patch!
On Thu, May 30, 2019 at 7:23 PM Kees Cook <keescook@chromium.org> wrote:
>
> On Fri, May 31, 2019 at 06:11:44AM +1000, James Morris wrote:
> > On Thu, 30 May 2019, Ke Wu wrote:
> >
> > > Linux kernel already provide MODULE_SIG and KEXEC_VERIFY_SIG to
> > > make sure loaded kernel module and kernel image are trusted. This
> > > patch adds a kernel command line option "loadpin.exclude" which
> > > allows to exclude specific file types from LoadPin. This is useful
> > > when people want to use different mechanisms to verify module and
> > > kernel image while still use LoadPin to protect the integrity of
> > > other files kernel loads.
> > >
> > > Signed-off-by: Ke Wu <mikewu@google.com>
> > > ---
> > > Changelog since v1:
> > > - Mark ignore_read_file_id with __ro_after_init.
> > > - Mark parse_exclude() with __init.
> > > - Use ARRAY_SIZE(ignore_read_file_id) instead of READING_MAX_ID.
> >
> > Looks good!
> >
> > Reviewed-by: James Morris <jamorris@linux.microsoft.com>
>
> Thanks! Applied to my for-next/loadpin branch at
> git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git
> and should be visible in linux-next in a few days.
>
> --
> Kees Cook
--
Ke Wu | Software Engineer | mikewu@google.com | Google Inc.
^ permalink raw reply
* Re: [PATCH V7 2/4] tpm: Reserve the TPM final events table
From: Joe Richey @ 2019-05-31 8:24 UTC (permalink / raw)
To: Matthew Garrett
Cc: linux-integrity, peterhuewe, jarkko.sakkinen, jgg, roberto.sassu,
linux-efi, linux-security-module, linux-kernel,
Thiébaud Weksteen, bsz, Matthew Garrett
In-Reply-To: <20190520205501.177637-3-matthewgarrett@google.com>
[-- Attachment #1: Type: text/plain, Size: 14300 bytes --]
On Mon, May 20, 2019 at 1:55 PM Matthew Garrett
<matthewgarrett@google.com> wrote:
>
> From: Matthew Garrett <mjg59@google.com>
>
> UEFI systems provide a boot services protocol for obtaining the TPM
> event log, but this is unusable after ExitBootServices() is called.
> Unfortunately ExitBootServices() itself triggers additional TPM events
> that then can't be obtained using this protocol. The platform provides a
> mechanism for the OS to obtain these events by recording them to a
> separate UEFI configuration table which the OS can then map.
>
> Unfortunately this table isn't self describing in terms of providing its
> length, so we need to parse the events inside it to figure out how long
> it is. Since the table isn't mapped at this point, we need to extend the
> length calculation function to be able to map the event as it goes
> along.
>
> (Fixes by Bartosz Szczepanek <bsz@semihalf.com>)
>
> Signed-off-by: Matthew Garrett <mjg59@google.com>
> ---
> drivers/char/tpm/eventlog/tpm2.c | 2 +-
> drivers/firmware/efi/efi.c | 2 +
> drivers/firmware/efi/tpm.c | 62 ++++++++++++++++++-
> include/linux/efi.h | 9 +++
> include/linux/tpm_eventlog.h | 102 ++++++++++++++++++++++++++++---
> 5 files changed, 164 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/char/tpm/eventlog/tpm2.c b/drivers/char/tpm/eventlog/tpm2.c
> index 1a977bdd3bd2..de1d9f7e5a92 100644
> --- a/drivers/char/tpm/eventlog/tpm2.c
> +++ b/drivers/char/tpm/eventlog/tpm2.c
> @@ -40,7 +40,7 @@
> static size_t calc_tpm2_event_size(struct tcg_pcr_event2_head *event,
> struct tcg_pcr_event *event_header)
> {
> - return __calc_tpm2_event_size(event, event_header);
> + return __calc_tpm2_event_size(event, event_header, false);
> }
>
> static void *tpm2_bios_measurements_start(struct seq_file *m, loff_t *pos)
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index 55b77c576c42..6b11c41e0575 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -53,6 +53,7 @@ struct efi __read_mostly efi = {
> .mem_attr_table = EFI_INVALID_TABLE_ADDR,
> .rng_seed = EFI_INVALID_TABLE_ADDR,
> .tpm_log = EFI_INVALID_TABLE_ADDR,
> + .tpm_final_log = EFI_INVALID_TABLE_ADDR,
> .mem_reserve = EFI_INVALID_TABLE_ADDR,
> };
> EXPORT_SYMBOL(efi);
> @@ -485,6 +486,7 @@ static __initdata efi_config_table_type_t common_tables[] = {
> {EFI_MEMORY_ATTRIBUTES_TABLE_GUID, "MEMATTR", &efi.mem_attr_table},
> {LINUX_EFI_RANDOM_SEED_TABLE_GUID, "RNG", &efi.rng_seed},
> {LINUX_EFI_TPM_EVENT_LOG_GUID, "TPMEventLog", &efi.tpm_log},
> + {LINUX_EFI_TPM_FINAL_LOG_GUID, "TPMFinalLog", &efi.tpm_final_log},
> {LINUX_EFI_MEMRESERVE_TABLE_GUID, "MEMRESERVE", &efi.mem_reserve},
> {NULL_GUID, NULL, NULL},
> };
> diff --git a/drivers/firmware/efi/tpm.c b/drivers/firmware/efi/tpm.c
> index 3a689b40ccc0..2c912ea08166 100644
> --- a/drivers/firmware/efi/tpm.c
> +++ b/drivers/firmware/efi/tpm.c
> @@ -4,34 +4,90 @@
> * Thiebaud Weksteen <tweek@google.com>
> */
>
> +#define TPM_MEMREMAP(start, size) early_memremap(start, size)
> +#define TPM_MEMUNMAP(start, size) early_memunmap(start, size)
> +
> #include <linux/efi.h>
> #include <linux/init.h>
> #include <linux/memblock.h>
> +#include <linux/tpm_eventlog.h>
>
> #include <asm/early_ioremap.h>
>
> +int efi_tpm_final_log_size;
> +EXPORT_SYMBOL(efi_tpm_final_log_size);
> +
> +static int tpm2_calc_event_log_size(void *data, int count, void *size_info)
> +{
> + struct tcg_pcr_event2_head *header;
> + int event_size, size = 0;
> +
> + while (count > 0) {
> + header = data + size;
> + event_size = __calc_tpm2_event_size(header, size_info, true);
> + if (event_size == 0)
> + return -1;
> + size += event_size;
> + count--;
> + }
> +
> + return size;
> +}
> +
> /*
> * Reserve the memory associated with the TPM Event Log configuration table.
> */
> int __init efi_tpm_eventlog_init(void)
> {
> struct linux_efi_tpm_eventlog *log_tbl;
> + struct efi_tcg2_final_events_table *final_tbl;
> unsigned int tbl_size;
> + int ret = 0;
>
> - if (efi.tpm_log == EFI_INVALID_TABLE_ADDR)
> + if (efi.tpm_log == EFI_INVALID_TABLE_ADDR) {
> + /*
> + * We can't calculate the size of the final events without the
> + * first entry in the TPM log, so bail here.
> + */
> return 0;
> + }
>
> log_tbl = early_memremap(efi.tpm_log, sizeof(*log_tbl));
> if (!log_tbl) {
> pr_err("Failed to map TPM Event Log table @ 0x%lx\n",
> - efi.tpm_log);
> + efi.tpm_log);
> efi.tpm_log = EFI_INVALID_TABLE_ADDR;
> return -ENOMEM;
> }
>
> tbl_size = sizeof(*log_tbl) + log_tbl->size;
> memblock_reserve(efi.tpm_log, tbl_size);
> +
> + if (efi.tpm_final_log == EFI_INVALID_TABLE_ADDR)
> + goto out;
> +
> + final_tbl = early_memremap(efi.tpm_final_log, sizeof(*final_tbl));
> +
> + if (!final_tbl) {
> + pr_err("Failed to map TPM Final Event Log table @ 0x%lx\n",
> + efi.tpm_final_log);
> + efi.tpm_final_log = EFI_INVALID_TABLE_ADDR;
> + ret = -ENOMEM;
> + goto out;
> + }
> +
> + tbl_size = tpm2_calc_event_log_size(efi.tpm_final_log
> + + sizeof(final_tbl->version)
> + + sizeof(final_tbl->nr_events),
This line causes:
warning: passing argument 1 of ‘tpm2_calc_event_log_size’ makes
pointer from integer without a cast
> + final_tbl->nr_events,
> + log_tbl->log);
> + memblock_reserve((unsigned long)final_tbl,
> + tbl_size + sizeof(*final_tbl));
> + early_memunmap(final_tbl, sizeof(*final_tbl));
> + efi_tpm_final_log_size = tbl_size;
> +
> +out:
> early_memunmap(log_tbl, sizeof(*log_tbl));
> - return 0;
> + return ret;
> }
>
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index 54357a258b35..e33c70a52a9d 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -689,6 +689,7 @@ void efi_native_runtime_setup(void);
> #define LINUX_EFI_LOADER_ENTRY_GUID EFI_GUID(0x4a67b082, 0x0a4c, 0x41cf, 0xb6, 0xc7, 0x44, 0x0b, 0x29, 0xbb, 0x8c, 0x4f)
> #define LINUX_EFI_RANDOM_SEED_TABLE_GUID EFI_GUID(0x1ce1e5bc, 0x7ceb, 0x42f2, 0x81, 0xe5, 0x8a, 0xad, 0xf1, 0x80, 0xf5, 0x7b)
> #define LINUX_EFI_TPM_EVENT_LOG_GUID EFI_GUID(0xb7799cb0, 0xeca2, 0x4943, 0x96, 0x67, 0x1f, 0xae, 0x07, 0xb7, 0x47, 0xfa)
> +#define LINUX_EFI_TPM_FINAL_LOG_GUID EFI_GUID(0x1e2ed096, 0x30e2, 0x4254, 0xbd, 0x89, 0x86, 0x3b, 0xbe, 0xf8, 0x23, 0x25)
> #define LINUX_EFI_MEMRESERVE_TABLE_GUID EFI_GUID(0x888eb0c6, 0x8ede, 0x4ff5, 0xa8, 0xf0, 0x9a, 0xee, 0x5c, 0xb9, 0x77, 0xc2)
>
> typedef struct {
> @@ -996,6 +997,7 @@ extern struct efi {
> unsigned long mem_attr_table; /* memory attributes table */
> unsigned long rng_seed; /* UEFI firmware random seed */
> unsigned long tpm_log; /* TPM2 Event Log table */
> + unsigned long tpm_final_log; /* TPM2 Final Events Log table */
> unsigned long mem_reserve; /* Linux EFI memreserve table */
> efi_get_time_t *get_time;
> efi_set_time_t *set_time;
> @@ -1707,6 +1709,13 @@ struct linux_efi_tpm_eventlog {
>
> extern int efi_tpm_eventlog_init(void);
>
> +struct efi_tcg2_final_events_table {
> + u64 version;
> + u64 nr_events;
> + u8 events[];
> +};
> +extern int efi_tpm_final_log_size;
> +
> /*
> * efi_runtime_service() function identifiers.
> * "NONE" is used by efi_recover_from_page_fault() to check if the page
> diff --git a/include/linux/tpm_eventlog.h b/include/linux/tpm_eventlog.h
> index 6a86144e13f1..63238c84dc0b 100644
> --- a/include/linux/tpm_eventlog.h
> +++ b/include/linux/tpm_eventlog.h
> @@ -112,10 +112,35 @@ struct tcg_pcr_event2_head {
> struct tpm_digest digests[];
> } __packed;
>
> +struct tcg_algorithm_size {
> + u16 algorithm_id;
> + u16 algorithm_size;
> +};
> +
> +struct tcg_algorithm_info {
> + u8 signature[16];
> + u32 platform_class;
> + u8 spec_version_minor;
> + u8 spec_version_major;
> + u8 spec_errata;
> + u8 uintn_size;
> + u32 number_of_algorithms;
> + struct tcg_algorithm_size digest_sizes[];
> +};
> +
> +#ifndef TPM_MEMREMAP
> +#define TPM_MEMREMAP(start, size) NULL
> +#endif
> +
> +#ifndef TPM_MEMUNMAP
> +#define TPM_MEMUNMAP(start, size) do{} while(0)
> +#endif
> +
> /**
> * __calc_tpm2_event_size - calculate the size of a TPM2 event log entry
> * @event: Pointer to the event whose size should be calculated
> * @event_header: Pointer to the initial event containing the digest lengths
> + * @do_mapping: Whether or not the event needs to be mapped
> *
> * The TPM2 event log format can contain multiple digests corresponding to
> * separate PCR banks, and also contains a variable length of the data that
> @@ -131,10 +156,13 @@ struct tcg_pcr_event2_head {
> */
>
> static inline int __calc_tpm2_event_size(struct tcg_pcr_event2_head *event,
> - struct tcg_pcr_event *event_header)
> + struct tcg_pcr_event *event_header,
> + bool do_mapping)
> {
> struct tcg_efi_specid_event_head *efispecid;
> struct tcg_event_field *event_field;
> + void *mapping = NULL;
> + int mapping_size;
> void *marker;
> void *marker_start;
> u32 halg_size;
> @@ -148,16 +176,49 @@ static inline int __calc_tpm2_event_size(struct tcg_pcr_event2_head *event,
> marker = marker + sizeof(event->pcr_idx) + sizeof(event->event_type)
> + sizeof(event->count);
>
> + /* Map the event header */
> + if (do_mapping) {
> + mapping_size = marker - marker_start;
> + mapping = TPM_MEMREMAP((unsigned long)marker_start,
> + mapping_size);
> + if (!mapping) {
> + size = 0;
> + goto out;
> + }
> + } else {
> + mapping = marker_start;
> + }
> +
> + event = (struct tcg_pcr_event2_head *)mapping;
> +
> efispecid = (struct tcg_efi_specid_event_head *)event_header->event;
>
> /* Check if event is malformed. */
> - if (event->count > efispecid->num_algs)
> - return 0;
> + if (event->count > efispecid->num_algs) {
> + size = 0;
> + goto out;
> + }
>
> for (i = 0; i < event->count; i++) {
> halg_size = sizeof(event->digests[i].alg_id);
> - memcpy(&halg, marker, halg_size);
> +
> + /* Map the digest's algorithm identifier */
> + if (do_mapping) {
> + TPM_MEMUNMAP(mapping, mapping_size);
> + mapping_size = halg_size;
> + mapping = TPM_MEMREMAP((unsigned long)marker,
> + mapping_size);
> + if (!mapping) {
> + size = 0;
> + goto out;
> + }
> + } else {
> + mapping = marker;
> + }
> +
> + memcpy(&halg, mapping, halg_size);
> marker = marker + halg_size;
> +
> for (j = 0; j < efispecid->num_algs; j++) {
> if (halg == efispecid->digest_sizes[j].alg_id) {
> marker +=
> @@ -166,18 +227,41 @@ static inline int __calc_tpm2_event_size(struct tcg_pcr_event2_head *event,
> }
> }
> /* Algorithm without known length. Such event is unparseable. */
> - if (j == efispecid->num_algs)
> - return 0;
> + if (j == efispecid->num_algs) {
> + size = 0;
> + goto out;
> + }
> + }
> +
> + /*
> + * Map the event size - we don't read from the event itself, so
> + * we don't need to map it
> + */
> + if (do_mapping) {
> + TPM_MEMUNMAP(mapping, mapping_size);
> + mapping_size += sizeof(event_field->event_size);
> + mapping = TPM_MEMREMAP((unsigned long)marker,
> + mapping_size);
> + if (!mapping) {
> + size = 0;
> + goto out;
> + }
> + } else {
> + mapping = marker;
> }
>
> - event_field = (struct tcg_event_field *)marker;
> + event_field = (struct tcg_event_field *)mapping;
> +
> marker = marker + sizeof(event_field->event_size)
> + event_field->event_size;
> size = marker - marker_start;
>
> if ((event->event_type == 0) && (event_field->event_size == 0))
> - return 0;
> -
> + size = 0;
> +out:
> + if (do_mapping)
> + TPM_MEMUNMAP(mapping, mapping_size);
> return size;
> }
> +
> #endif
> --
> 2.21.0.1020.gf2820cf01a-goog
>
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4849 bytes --]
^ permalink raw reply
* Re: [PATCH 1/7] General notification queue with user mmap()'able ring buffer
From: Peter Zijlstra @ 2019-05-31 8:35 UTC (permalink / raw)
To: Andrea Parri
Cc: Greg KH, David Howells, viro, raven, linux-fsdevel, linux-api,
linux-block, keyrings, linux-security-module, linux-kernel,
Will Deacon, Paul E. McKenney, Mark Rutland
In-Reply-To: <20190530095039.GA5137@andrea>
On Thu, May 30, 2019 at 11:50:39AM +0200, Andrea Parri wrote:
> > > Looking at the perf ring buffer, there appears to be a missing barrier in
> > > perf_aux_output_end():
> > >
> > > rb->user_page->aux_head = rb->aux_head;
> > >
> > > should be:
> > >
> > > smp_store_release(&rb->user_page->aux_head, rb->aux_head);
> > >
> > > It should also be using smp_load_acquire(). See
> > > Documentation/core-api/circular-buffers.rst
> > >
> > > And a (partial) patch has been proposed: https://lkml.org/lkml/2018/5/10/249
> >
> > So, if that's all that needs to be fixed, can you use the same
> > buffer/code if that patch is merged?
>
> That's about one year old...: let me add the usual suspects in Cc: ;-)
> since I'm not sure what the plan was (or if I'm missing something) ...
The AUX crud is 'special' and smp_store_release() doesn't really help in
many cases. Notable, AUX is typically used in combination with a
hardware writer. The driver is in charge of odering here, the generic
code doesn't know what the appropriate barrier (if any) is and would
have to resort to the most expensive/heavy one available.
Also see the comment right above this function:
"It is the
pmu driver's responsibility to observe ordering rules of the hardware,
so that all the data is externally visible before this is called."
^ permalink raw reply
* Re: [PATCH 1/7] General notification queue with user mmap()'able ring buffer
From: Peter Zijlstra @ 2019-05-31 8:47 UTC (permalink / raw)
To: David Howells
Cc: Greg KH, viro, raven, linux-fsdevel, linux-api, linux-block,
keyrings, linux-security-module, linux-kernel
In-Reply-To: <31936.1559146000@warthog.procyon.org.uk>
On Wed, May 29, 2019 at 05:06:40PM +0100, David Howells wrote:
> Looking at the perf ring buffer, there appears to be a missing barrier in
> perf_aux_output_end():
>
> rb->user_page->aux_head = rb->aux_head;
>
> should be:
>
> smp_store_release(&rb->user_page->aux_head, rb->aux_head);
I've answered that in another email; the aux bit is 'magic'.
> It should also be using smp_load_acquire(). See
> Documentation/core-api/circular-buffers.rst
We use the control dependency instead, as described in the comment of
perf_output_put_handle():
* kernel user
*
* if (LOAD ->data_tail) { LOAD ->data_head
* (A) smp_rmb() (C)
* STORE $data LOAD $data
* smp_wmb() (B) smp_mb() (D)
* STORE ->data_head STORE ->data_tail
* }
*
* Where A pairs with D, and B pairs with C.
*
* In our case (A) is a control dependency that separates the load of
* the ->data_tail and the stores of $data. In case ->data_tail
* indicates there is no room in the buffer to store $data we do not.
*
* D needs to be a full barrier since it separates the data READ
* from the tail WRITE.
*
* For B a WMB is sufficient since it separates two WRITEs, and for C
* an RMB is sufficient since it separates two READs.
Userspace can choose to use smp_load_acquire() over the first smp_rmb()
if that is efficient for the architecture (for w ahole bunch of archs
load-acquire would end up using mb() while rmb() is adequate and
cheaper).
^ permalink raw reply
* re: security/loadpin: Allow to exclude specific file types
From: Colin Ian King @ 2019-05-31 10:46 UTC (permalink / raw)
To: Ke Wu, James Morris, Kees Cook, Serge E. Hallyn,
linux-security-module
Cc: linux-kernel@vger.kernel.org
Hi,
Static analysis with Coverity on linux-next has found a potential issue
with the following commit:
commit 1633a4f04cc171fc638deb5c95af96032d3c591b
Author: Ke Wu <mikewu@google.com>
Date: Thu May 30 12:22:08 2019 -0700
security/loadpin: Allow to exclude specific file types
209 for (j = 0; j < ARRAY_SIZE(kernel_read_file_str); j++) {
210 if (strcmp(cur, kernel_read_file_str[j]) == 0) {
211 pr_info("excluding: %s\n",
212 kernel_read_file_str[j]);
CID 81977 (#1 of 1): Out-of-bounds write
overrun-local: Overrunning array ignore_read_file_id of 8 4-byte
elements at element index 8 (byte offset 35) using index j (which
evaluates to 8).
213 ignore_read_file_id[j] = 1;
According to Coverity ignore_read_file_id is an array of 8 integers.
However, ARRAY_SIZE(kernel_read_file_str) is 9, so we have an out of
bounds write on ignore_read_file[j] when j is 8.
Colin
^ permalink raw reply
* [PATCH] Smack: Restore the smackfsdef mount option and add missing prefixes
From: David Howells @ 2019-05-31 10:53 UTC (permalink / raw)
To: viro
Cc: stable, Jose Bollo, Casey Schaufler, Casey Schaufler, jmorris,
dhowells, torvalds, linux-security-module, linux-kernel
From: Casey Schaufler <casey@schaufler-ca.com>
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.
Also fix the smack_param_specs[] to have "smack" prefixes on all the names.
This isn't visible to a user unless they either:
(a) Try to mount a filesystem that's converted to the internal mount API
and that implements the ->parse_monolithic() context operation - and
only then if they call security_fs_context_parse_param() rather than
security_sb_eat_lsm_opts().
There are no examples of this upstream yet, but nfs will probably want
to do this for nfs2 or nfs3.
(b) Use fsconfig() to configure the filesystem - in which case
security_fs_context_parse_param() will be called.
This issue is that smack_sb_eat_lsm_opts() checks for the "smack" prefix on
the options, but smack_fs_context_parse_param() does not.
Fixes: c3300aaf95fb ("smack: get rid of match_token()")
Fixes: 2febd254adc4 ("smack: Implement filesystem context security hooks")
Cc: stable@vger.kernel.org
Reported-by: Jose Bollo <jose.bollo@iot.bzh>
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Casey Schaufler <casey@schaufler-ca.com>
---
security/smack/smack_lsm.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 0de725f88bed..d99450b4f511 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,11 +683,12 @@ static int smack_fs_context_dup(struct fs_context *fc,
}
static const struct fs_parameter_spec smack_param_specs[] = {
- fsparam_string("fsdefault", Opt_fsdefault),
- fsparam_string("fsfloor", Opt_fsfloor),
- fsparam_string("fshat", Opt_fshat),
- fsparam_string("fsroot", Opt_fsroot),
- fsparam_string("fstransmute", Opt_fstransmute),
+ fsparam_string("smackfsdef", Opt_fsdefault),
+ fsparam_string("smackfsdefault", Opt_fsdefault),
+ fsparam_string("smackfsfloor", Opt_fsfloor),
+ fsparam_string("smackfshat", Opt_fshat),
+ fsparam_string("smackfsroot", Opt_fsroot),
+ fsparam_string("smackfstransmute", Opt_fstransmute),
{}
};
^ permalink raw reply related
* Re: [PATCH] Smack: Restore the smackfsdef mount option and add missing prefixes
From: David Howells @ 2019-05-31 10:56 UTC (permalink / raw)
To: viro
Cc: dhowells, stable, Jose Bollo, Casey Schaufler, jmorris, torvalds,
linux-security-module, linux-kernel
In-Reply-To: <155930001303.17253.2447519598157285098.stgit@warthog.procyon.org.uk>
Should this go via Al's tree, James's tree, Casey's tree or directly to Linus?
David
^ 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