* Re: [PATCH] mm: security: introduce CONFIG_INIT_HEAP_ALL
From: Alexander Potapenko @ 2019-04-16 16:01 UTC (permalink / raw)
To: Christopher Lameter
Cc: Andrew Morton, linux-security-module,
Linux Memory Management List, Nick Desaulniers, Kostya Serebryany,
Dmitriy Vyukov, Kees Cook, Sandeep Patil, Laura Abbott,
Kernel Hardening
In-Reply-To: <0100016a26c711be-b99971ca-49f5-482c-9028-962ee471f733-000000@email.amazonses.com>
On Tue, Apr 16, 2019 at 5:32 PM Christopher Lameter <cl@linux.com> wrote:
>
> On Fri, 12 Apr 2019, Alexander Potapenko wrote:
>
> > diff --git a/mm/slab.h b/mm/slab.h
> > index 43ac818b8592..4bb10af0031b 100644
> > --- a/mm/slab.h
> > +++ b/mm/slab.h
> > @@ -167,6 +167,16 @@ static inline slab_flags_t kmem_cache_flags(unsigned int object_size,
> > SLAB_TEMPORARY | \
> > SLAB_ACCOUNT)
> >
> > +/*
> > + * Do we need to initialize this allocation?
> > + * Always true for __GFP_ZERO, CONFIG_INIT_HEAP_ALL enforces initialization
> > + * of caches without constructors and RCU.
> > + */
> > +#define SLAB_WANT_INIT(cache, gfp_flags) \
> > + ((GFP_INIT_ALWAYS_ON && !(cache)->ctor && \
> > + !((cache)->flags & SLAB_TYPESAFE_BY_RCU)) || \
> > + (gfp_flags & __GFP_ZERO))
>
> This is another complex thing to maintain when adding flags to the slab
> allocator.
>
> > +config INIT_HEAP_ALL
> > + bool "Initialize kernel heap allocations"
>
> "Zero pages and objects allocated in the kernel"
>
> > + default n
> > + help
> > + Enforce initialization of pages allocated from page allocator
> > + and objects returned by kmalloc and friends.
> > + Allocated memory is initialized with zeroes, preventing possible
> > + information leaks and making the control-flow bugs that depend
> > + on uninitialized values more deterministic.
>
> Hmmm... But we already have debugging options that poison objects and
> pages?
Laura Abbott mentioned in one of the previous threads
(https://marc.info/?l=kernel-hardening&m=155474181528491&w=2) that:
"""
I've looked at doing something similar in the past (failing to find
the thread this morning...) and while this will work, it has pretty
serious performance issues. It's not actually the poisoning which
is expensive but that turning on debugging removes the cpu slab
which has significant performance penalties.
I'd rather go back to the proposal of just poisoning the slab
at alloc/free without using SLAB_POISON.
"""
, so slab poisoning is probably off the table.
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
^ permalink raw reply
* Re: fanotify and LSM path hooks
From: Jan Kara @ 2019-04-16 15:45 UTC (permalink / raw)
To: Amir Goldstein
Cc: Jan Kara, linux-fsdevel, LSM List, Serge E. Hallyn, James Morris,
Al Viro, Miklos Szeredi, Matthew Bobrowski, Kentaro Takeda,
Tetsuo Handa, John Johansen
In-Reply-To: <CAOQ4uxgn=YNj8cJuccx2KqxEVGZy1z3DBVYXrD=Mc7Dc=Je+-w@mail.gmail.com>
Hi Amir!
On Sun 14-04-19 19:04:14, Amir Goldstein wrote:
> I started to look at directory pre-modification "permission" hooks
> that were discussed on last year's LSFMM:
> https://lwn.net/Articles/755277/
>
> The two existing fanotify_perm() hooks are called
> from security_file_permission() and security_file_open()
> and depend on build time CONFIG_SECURITY.
> If you look at how the fsnotify_perm() hooks are planted inside the
> generic security hooks, one might wonder, why are fanotify permission
> hooks getting a special treatment and are not registering as LSM hooks?
>
> One benefit from an fanotify LSM, besides more generic code, would be
> that fanotify permission hooks could be disabled with boot parameters.
>
> I only bring this up because security hooks seems like the most natural
> place to add pre-modify fanotify events for the purpose of maintaining
> a filesystem change journal. It would be ugly to spray more fsnotify hooks
> inside security hooks instead of registering an fanotify LSM, but maybe
> there are downsides of registering fanotify as LSM that I am not aware of?
I kind of like the idea of generating fanotify permission events from
special LSM hooks.
I'm not so sure about directory pre-modification hooks. Given the amount of
problems we face with applications using fanotify permission events and
deadlocking the system, I'm not very fond of expanding that API... AFAIU
you want to use such hooks for recording (and persisting) that some change
is going to happen and provide crash-consistency guarantees for such
journal?
> Another observation relates to the security_path_ hooks.
> Let's take rename as an example.
> LSM could implement security_path_rename() and/or security_inode_rename()
> hooks and rename syscalls will end up calling both hooks.
> The security_path_ hooks are more attractive for fanotify, because the path
> information could be used to setup pre-modification permission mask on
> mount marks and not only on filesystem/inode marks.
>
> One problem with security_path_ hooks is that they require an extra
> build time CONFIG_SECURITY_PATH.
> Another problem is that they seem to be bypassed by several subsystems.
> cachefiles, ecryptfs, overlayfs and nfsd all call the vfs_rename() helper, but
> only cachefiles bothers to call the security_path_rename() hook.
> This is of course true for all other security_path_ hooks.
> I think that is something that requires fixing regardless of the fanotify pre
> modification hooks. I wonder if tomoyo and apparmor developers
> (LSM that implement security_path_ hooks) are aware of those missing
> hooks?
>
> Would love to get feedback about whether or not fanotify LSM sounds
> like a good or bad idea and about the security_path_ hooks questions.
I don't have strong opinion on using security_path_ hooks. I guess if
they're not used everywhere then it's just easier to avoid them.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* Re: [RFC PATCH v1 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
From: Steve Grubb @ 2019-04-16 15:34 UTC (permalink / raw)
To: Florian Weimer
Cc: Jan Kara, Mickaël Salaün, linux-kernel, Al Viro,
James Morris, Jonathan Corbet, Kees Cook, Matthew Garrett,
Michael Kerrisk, Mickaël Salaün, Mimi Zohar,
Philippe Trébuchet, Shuah Khan, Thibaut Sautereau,
Vincent Strubel, Yves-Alexis Perez, kernel-hardening, linux-api,
linux-security-module, linux-fsdevel, Matthew Bobrowski
In-Reply-To: <87wojuxj8s.fsf@oldenburg2.str.redhat.com>
On Tuesday, April 16, 2019 7:49:39 AM EDT Florian Weimer wrote:
> * Steve Grubb:
> > This flag that is being proposed means that you would have to patch all
> > interpreters to use it. If you are sure that upstreams will accept that,
> > why not just change the policy to interpreters shouldn't execute
> > anything unless the execute bit is set? That is simpler and doesn't need
> > a kernel change. And setting the execute bit is an auditable event.
>
> I think we need something like O_MAYEXEC so that security policies can
> be enforced and noexec mounts can be detected.
Application whitelisting can already today stop unknown software without
needing O_MAYEXEC.
> I don't think it's a good idea to do this in userspace, especially the
> latter.
The problem is that passing O_MAYEXEC is opt-in. You can use ptrace/seccomp/
bpf/LD_PRELOAD/LD_AUDIT to remove that bit from an otherwise normal program.
This does not require privs to do so.
But let's consider that this comes to pass and every interpreter is updated
and IMA can see the O_MAYEXEC flag. Attackers now simply pivot to running
programs via stdin. It never touches disk and therefore nothing enforces
security policy. This already is among the most common ways that malware runs
today to evade detection.
-Steve
^ permalink raw reply
* Re: [PATCH] mm: security: introduce CONFIG_INIT_HEAP_ALL
From: Christopher Lameter @ 2019-04-16 15:32 UTC (permalink / raw)
To: Alexander Potapenko
Cc: akpm, linux-security-module, linux-mm, ndesaulniers, kcc, dvyukov,
Kees Cook, sspatil, labbott, kernel-hardening
In-Reply-To: <20190412124501.132678-1-glider@google.com>
On Fri, 12 Apr 2019, Alexander Potapenko wrote:
> diff --git a/mm/slab.h b/mm/slab.h
> index 43ac818b8592..4bb10af0031b 100644
> --- a/mm/slab.h
> +++ b/mm/slab.h
> @@ -167,6 +167,16 @@ static inline slab_flags_t kmem_cache_flags(unsigned int object_size,
> SLAB_TEMPORARY | \
> SLAB_ACCOUNT)
>
> +/*
> + * Do we need to initialize this allocation?
> + * Always true for __GFP_ZERO, CONFIG_INIT_HEAP_ALL enforces initialization
> + * of caches without constructors and RCU.
> + */
> +#define SLAB_WANT_INIT(cache, gfp_flags) \
> + ((GFP_INIT_ALWAYS_ON && !(cache)->ctor && \
> + !((cache)->flags & SLAB_TYPESAFE_BY_RCU)) || \
> + (gfp_flags & __GFP_ZERO))
This is another complex thing to maintain when adding flags to the slab
allocator.
> +config INIT_HEAP_ALL
> + bool "Initialize kernel heap allocations"
"Zero pages and objects allocated in the kernel"
> + default n
> + help
> + Enforce initialization of pages allocated from page allocator
> + and objects returned by kmalloc and friends.
> + Allocated memory is initialized with zeroes, preventing possible
> + information leaks and making the control-flow bugs that depend
> + on uninitialized values more deterministic.
Hmmm... But we already have debugging options that poison objects and
pages?
^ permalink raw reply
* Re: kernel BUG at kernel/cred.c:434!
From: chengjian (D) @ 2019-04-16 14:46 UTC (permalink / raw)
To: Kees Cook, Paul Moore
Cc: Oleg Nesterov, Casey Schaufler, NeilBrown, Anna Schumaker,
linux-kernel@vger.kernel.org, Al Viro, Xiexiuqi (Xie XiuQi),
Li Bin, Jason Yan, Peter Zijlstra, Ingo Molnar,
Linux Security Module list, SELinux, Yang Yingliang
In-Reply-To: <CAGXu5jKYmoaR6bxW82ogN4iOeKi8AtEwkvVvCXd_gn3CCwFU2Q@mail.gmail.com>
On 2019/4/16 11:40, Kees Cook wrote:
> On Mon, Apr 15, 2019 at 11:20 AM Paul Moore <paul@paul-moore.com> wrote:
>> On Mon, Apr 15, 2019 at 11:05 AM Oleg Nesterov <oleg@redhat.com> wrote:
>>> On 04/15, Paul Moore wrote:
>>>> On Mon, Apr 15, 2019 at 9:43 AM Oleg Nesterov <oleg@redhat.com> wrote:
>>>>> Well, acct("/proc/self/attr/current") doesn't look like a good idea, but I do
>>>>> not know where should we put the additional check... And probably
>>>>> "echo /proc/self/attr/current > /proc/sys/kernel/core_pattern" can hit the
>>>>> same problem, do_coredump() does override_creds() too.
>>>>>
>>>>> May be just add
>>>>>
>>>>> if (current->cred != current->real_cred)
>>>>> return -EACCES;
>>>>>
>>>>> into proc_pid_attr_write(), I dunno.
>>>> Is the problem that do_acct_process() is calling override_creds() and
>>>> the returned/old credentials are being freed before do_acct_process()
>>>> can reinstall the creds via revert_creds()? Presumably because the
>>>> process accounting is causing the credentials to be replaced?
>>> Afaics, the problem is that do_acct_process() does override_creds() and
>>> then __kernel_write(). Which calls proc_pid_attr_write(), which in turn calls
>>> selinux_setprocattr(), which does another prepare_creds() + commit_creds();
>>> and commit_creds() hits
>>>
>>> BUG_ON(task->cred != old);
>> Gotcha. In the process of looking at the backtrace I forgot about the
>> BUG_ON() at the top of the oops message.
>>
>> I wonder what terrible things would happen if we changed the BUG_ON()
>> in commit_creds to simple returning an error an error code to the
>> caller. There is a warning/requirement in commit_creds() function
>> header comment that it should always return 0.
> Would callers be expected to call abort_creds() on failure? There are
> a number of places where it'd need fixing up. And would likely be best
> with a __must_check marking.
>
> It seems like avoiding the pathological case might be simpler?
Yeah, Avoiding this pathological case is a better solution.
It seems like that we can't commit_creds() during
override_creds() and revert_creds().
So how about just put commit_creds outside !
just like:
override_creds() // cred -=> new
// may BUG_ON if commit_creds done.
revert_creds() // cred -=> old
<-----------|
commit_creds // cred = real_cred = new |
[revert_creds]--------------------------------------------------|
[1]--Before we call commit_creds in selinux_setprocattr(),
if we find that cred != real_cred, it may have been overridden
before, we should revert it.
[2]--The same to revert_creds, when we found someone have committed,
orig_cred != current->real_cred may hits, this means that
we have reverted before(see [1]).
[3]--Sometimes new and old are the same, then we need to consider this
situation specially.
The code just like:
From: Yang Yingliang <yangyingliang@huawei.com>
Date: Sat, 13 Apr 2019 21:56:01 +0800
Subject: [PATCH] fix cred bug_on
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
---
kernel/acct.c | 3 ++-
kernel/cred.c | 6 ++++++
security/selinux/hooks.c | 2 ++
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/kernel/acct.c b/kernel/acct.c
index addf7732fb56..f2065f899eee 100644
--- a/kernel/acct.c
+++ b/kernel/acct.c
@@ -522,7 +522,8 @@ static void do_acct_process(struct bsd_acct_struct
*acct)
}
out:
current->signal->rlim[RLIMIT_FSIZE].rlim_cur = flim;
- revert_creds(orig_cred);
+ if (orig_cred == current->real_cred) // [2]
+ revert_creds(orig_cred);
}
/**
diff --git a/kernel/cred.c b/kernel/cred.c
index ecf03657e71c..c4d5ba92fb9b 100644
--- a/kernel/cred.c
+++ b/kernel/cred.c
@@ -522,6 +522,9 @@ const struct cred *override_creds(const struct cred
*new)
{
const struct cred *old = current->cred;
+ if (old == new) // [3]
+ return old;
+
kdebug("override_creds(%p{%d,%d})", new,
atomic_read(&new->usage),
read_cred_subscribers(new));
@@ -551,6 +554,9 @@ void revert_creds(const struct cred *old)
{
const struct cred *override = current->cred;
+ if (override == old) // [3]
+ return;
+
kdebug("revert_creds(%p{%d,%d})", old,
atomic_read(&old->usage),
read_cred_subscribers(old));
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index b5017beb4ef7..bc8108e4e90f 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -6590,6 +6590,8 @@ static int selinux_setprocattr(const char *name,
void *value, size_t size)
goto abort_change;
}
+ if (current->cred != current->real_cred) // [1]
+ revert_creds(current->real_cred);
commit_creds(new);
return size;
--
2.17.1
We have tested this patch for 3 days and it works well.
Are there any cases that are not covered here ?
Thanks.
Cheng Jian
^ permalink raw reply related
* [PATCH] apparmor: fix spelling mistake "immutible" -> "immutable"
From: Colin King @ 2019-04-16 14:42 UTC (permalink / raw)
To: John Johansen, James Morris, Serge E . Hallyn,
linux-security-module
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
There is a spelling mistake in an information message string, fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
security/apparmor/policy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/security/apparmor/policy.c b/security/apparmor/policy.c
index 71a3e6291478..04f2480e8374 100644
--- a/security/apparmor/policy.c
+++ b/security/apparmor/policy.c
@@ -587,7 +587,7 @@ static int replacement_allowed(struct aa_profile *profile, int noreplace,
{
if (profile) {
if (profile->label.flags & FLAG_IMMUTIBLE) {
- *info = "cannot replace immutible profile";
+ *info = "cannot replace immutable profile";
return -EPERM;
} else if (noreplace) {
*info = "profile already exists";
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2 1/3] security: Create "kernel hardening" config area
From: Kees Cook @ 2019-04-16 13:56 UTC (permalink / raw)
To: Alexander Popov
Cc: Masahiro Yamada, Alexander Potapenko, James Morris,
Nick Desaulniers, Kostya Serebryany, Dmitry Vyukov, Sandeep Patil,
Laura Abbott, Randy Dunlap, Michal Marek, Emese Revfy,
Serge E. Hallyn, Kernel Hardening, linux-security-module,
linux-kbuild, LKML
In-Reply-To: <450e21b0-606a-f19a-a4fe-f7508d6a215c@linux.com>
On Tue, Apr 16, 2019 at 8:55 AM Alexander Popov <alex.popov@linux.com> wrote:
>
> On 16.04.2019 7:02, Kees Cook wrote:
> > On Mon, Apr 15, 2019 at 11:44 AM Alexander Popov <alex.popov@linux.com> wrote:
> >>
> >> What do you think about some separator between memory initialization options and
> >> CONFIG_CRYPTO?
> >
> > This was true before too
>
> Hm, yes, it's a generic behavior - there is no any separator at 'endmenu' and
> config options stick together.
>
> I've created a patch to fix that. What do you think about it?
> I can send it to LKML separately.
>
>
> From 50bf59d30fafcdebb3393fb742e1bd51e7d2f2da Mon Sep 17 00:00:00 2001
> From: Alexander Popov <alex.popov@linux.com>
> Date: Tue, 16 Apr 2019 16:09:40 +0300
> Subject: [PATCH 1/1] kconfig: Terminate menu blocks with a newline in the
> generated config
>
> Currently menu blocks start with a pretty header but end with nothing in
> the generated config. So next config options stick together with the
> options from the menu block.
>
> Let's terminate menu blocks with a newline in the generated config.
>
> Signed-off-by: Alexander Popov <alex.popov@linux.com>
> ---
> scripts/kconfig/confdata.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
> index 08ba146..1459153 100644
> --- a/scripts/kconfig/confdata.c
> +++ b/scripts/kconfig/confdata.c
> @@ -888,6 +888,8 @@ int conf_write(const char *name)
> if (menu->next)
> menu = menu->next;
> else while ((menu = menu->parent)) {
> + if (!menu->sym && menu_is_visible(menu))
> + fprintf(out, "\n");
> if (menu->next) {
> menu = menu->next;
> break;
Seems fine to me. I defer to Masahiro, though. :)
--
Kees Cook
^ permalink raw reply
* Re: [PATCH v2 1/3] security: Create "kernel hardening" config area
From: Alexander Popov @ 2019-04-16 13:55 UTC (permalink / raw)
To: Kees Cook, Masahiro Yamada
Cc: Alexander Potapenko, James Morris, Nick Desaulniers,
Kostya Serebryany, Dmitry Vyukov, Sandeep Patil, Laura Abbott,
Randy Dunlap, Michal Marek, Emese Revfy, Serge E. Hallyn,
Kernel Hardening, linux-security-module, linux-kbuild, LKML
In-Reply-To: <CAGXu5jJTM=pdAjsC63Z6T=HaztTqSqUQQ8=GN=tqv2n6CKc3nw@mail.gmail.com>
On 16.04.2019 7:02, Kees Cook wrote:
> On Mon, Apr 15, 2019 at 11:44 AM Alexander Popov <alex.popov@linux.com> wrote:
>>
>> What do you think about some separator between memory initialization options and
>> CONFIG_CRYPTO?
>
> This was true before too
Hm, yes, it's a generic behavior - there is no any separator at 'endmenu' and
config options stick together.
I've created a patch to fix that. What do you think about it?
I can send it to LKML separately.
From 50bf59d30fafcdebb3393fb742e1bd51e7d2f2da Mon Sep 17 00:00:00 2001
From: Alexander Popov <alex.popov@linux.com>
Date: Tue, 16 Apr 2019 16:09:40 +0300
Subject: [PATCH 1/1] kconfig: Terminate menu blocks with a newline in the
generated config
Currently menu blocks start with a pretty header but end with nothing in
the generated config. So next config options stick together with the
options from the menu block.
Let's terminate menu blocks with a newline in the generated config.
Signed-off-by: Alexander Popov <alex.popov@linux.com>
---
scripts/kconfig/confdata.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
index 08ba146..1459153 100644
--- a/scripts/kconfig/confdata.c
+++ b/scripts/kconfig/confdata.c
@@ -888,6 +888,8 @@ int conf_write(const char *name)
if (menu->next)
menu = menu->next;
else while ((menu = menu->parent)) {
+ if (!menu->sym && menu_is_visible(menu))
+ fprintf(out, "\n");
if (menu->next) {
menu = menu->next;
break;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] mm: security: introduce CONFIG_INIT_HEAP_ALL
From: Alexander Potapenko @ 2019-04-16 12:21 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-security-module, Linux Memory Management List,
Nick Desaulniers, Kostya Serebryany, Dmitriy Vyukov, Kees Cook,
Sandeep Patil, Laura Abbott, Kernel Hardening
In-Reply-To: <20190415190213.5831bbc17e5073690713b001@linux-foundation.org>
On Tue, Apr 16, 2019 at 4:02 AM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Fri, 12 Apr 2019 14:45:01 +0200 Alexander Potapenko <glider@google.com> wrote:
>
> > This config option adds the possibility to initialize newly allocated
> > pages and heap objects with zeroes.
>
> At what cost? Some performance test results would help this along.
I'll make more measurements for the new implementation, but the
preliminary results are:
~0.17% sys time slowdown (~0% wall time slowdown) on hackbench (1 CPU);
1.3% sys time slowdown (0.2% wall time slowdown) when building Linux with -j12;
4% sys time slowdown (2.6% wall time slowdown) on af_inet_loopback benchmark;
up to 100% slowdown on netperf (caused by sk buffers being initialized
multiple times; also netperf is too fast to perform any precise
measurements)
Are there any benchmarks you can recommend?
> > This is needed to prevent possible
> > information leaks and make the control-flow bugs that depend on
> > uninitialized values more deterministic.
> >
> > Initialization is done at allocation time at the places where checks for
> > __GFP_ZERO are performed. We don't initialize slab caches with
> > constructors or SLAB_TYPESAFE_BY_RCU to preserve their semantics.
> >
> > For kernel testing purposes filling allocations with a nonzero pattern
> > would be more suitable, but may require platform-specific code. To have
> > a simple baseline we've decided to start with zero-initialization.
> >
> > No performance optimizations are done at the moment to reduce double
> > initialization of memory regions.
>
> Requiring a kernel rebuild is rather user-hostile.
This is intended to be used together with other hardening measures,
like CONFIG_INIT_STACK_ALL (see a patchset by Kees).
All of those require a kernel rebuild, but we assume users don't push
and pull that lever back and forth often.
> A boot option
> (early_param()) would be much more useful and I expect that the loss in
> coverage would be small and acceptable? Could possibly use the
> static_branch infrastructure.
I'll try that out and see if there's a notable performance difference.
> > --- a/mm/slab.h
> > +++ b/mm/slab.h
> > @@ -167,6 +167,16 @@ static inline slab_flags_t kmem_cache_flags(unsigned int object_size,
> > SLAB_TEMPORARY | \
> > SLAB_ACCOUNT)
> >
> > +/*
> > + * Do we need to initialize this allocation?
> > + * Always true for __GFP_ZERO, CONFIG_INIT_HEAP_ALL enforces initialization
> > + * of caches without constructors and RCU.
> > + */
> > +#define SLAB_WANT_INIT(cache, gfp_flags) \
> > + ((GFP_INIT_ALWAYS_ON && !(cache)->ctor && \
> > + !((cache)->flags & SLAB_TYPESAFE_BY_RCU)) || \
> > + (gfp_flags & __GFP_ZERO))
>
> Is there any reason why this *must* be implemented as a macro? If not,
> it should be written in C please.
Agreed. Even in the case we want GFP_INIT_ALWAYS_ON to be known at
compile time there's no reason for this to be a macro.
>
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
^ permalink raw reply
* Re: [PATCH] mm: security: introduce CONFIG_INIT_HEAP_ALL
From: Alexander Potapenko @ 2019-04-16 12:04 UTC (permalink / raw)
To: Vlastimil Babka
Cc: Andrew Morton, linux-security-module,
Linux Memory Management List, Nick Desaulniers, Kostya Serebryany,
Dmitriy Vyukov, Kees Cook, Sandeep Patil, Laura Abbott,
Kernel Hardening
In-Reply-To: <35935775-1c0d-6016-5bb3-0abee65a7492@suse.cz>
On Tue, Apr 16, 2019 at 10:33 AM Vlastimil Babka <vbabka@suse.cz> wrote:
>
> On 4/12/19 2:45 PM, Alexander Potapenko wrote:
> > +config INIT_HEAP_ALL
> > + bool "Initialize kernel heap allocations"
>
> Calling slab and page allocations together as "heap" is rather uncommon
> in the kernel I think. But I don't have a better word right now.
We can provide two separate flags for slab and page allocator to avoid this.
I cannot think of a situation where this level of control is necessary
though (apart from benchmarking).
> > + default n
> > + help
> > + Enforce initialization of pages allocated from page allocator
> > + and objects returned by kmalloc and friends.
> > + Allocated memory is initialized with zeroes, preventing possible
> > + information leaks and making the control-flow bugs that depend
> > + on uninitialized values more deterministic.
> > +
> > config GCC_PLUGIN_STRUCTLEAK_VERBOSE
> > bool "Report forcefully initialized variables"
> > depends on GCC_PLUGIN_STRUCTLEAK
> >
>
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
^ permalink raw reply
* Re: [RFC PATCH v1 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
From: Florian Weimer @ 2019-04-16 11:49 UTC (permalink / raw)
To: Steve Grubb
Cc: Jan Kara, Mickaël Salaün, linux-kernel, Al Viro,
James Morris, Jonathan Corbet, Kees Cook, Matthew Garrett,
Michael Kerrisk, Mickaël Salaün, Mimi Zohar,
Philippe Trébuchet, Shuah Khan, Thibaut Sautereau,
Vincent Strubel, Yves-Alexis Perez, kernel-hardening, linux-api,
linux-security-module, linux-fsdevel, Matthew Bobrowski
In-Reply-To: <3452959.b6JmBh7Lnt@x2>
* Steve Grubb:
> This flag that is being proposed means that you would have to patch all
> interpreters to use it. If you are sure that upstreams will accept that, why
> not just change the policy to interpreters shouldn't execute anything unless
> the execute bit is set? That is simpler and doesn't need a kernel change. And
> setting the execute bit is an auditable event.
I think we need something like O_MAYEXEC so that security policies can
be enforced and noexec mounts can be detected. I don't think it's a
good idea to do this in userspace, especially the latter.
Thanks,
Florian
^ permalink raw reply
* Re: [PATCH V32 01/27] Add the ability to lock down access to the running kernel image
From: Andrew Donnellan @ 2019-04-16 8:40 UTC (permalink / raw)
To: Matthew Garrett, jmorris
Cc: linux-security-module, linux-kernel, dhowells, linux-api, luto,
linuxppc-dev, Michael Ellerman, Daniel Axtens, cmr
In-Reply-To: <20190404003249.14356-2-matthewgarrett@google.com>
On 4/4/19 11:32 am, Matthew Garrett wrote:
> diff --git a/Documentation/ABI/testing/lockdown b/Documentation/ABI/testing/lockdown
> new file mode 100644
> index 000000000000..5bd51e20917a
> --- /dev/null
> +++ b/Documentation/ABI/testing/lockdown
> @@ -0,0 +1,19 @@
> +What: security/lockdown
> +Date: March 2019
> +Contact: Matthew Garrett <mjg59@google.com>
> +Description:
> + If CONFIG_LOCK_DOWN_KERNEL is enabled, the kernel can be
> + moved to a more locked down state at runtime by writing to
> + this attribute. Valid values are:
> +
> + integrity:
> + The kernel will disable functionality that allows
> + userland to modify the running kernel image, other
> + than through the loading or execution of appropriately
> + signed objects.
> +
> + confidentiality:
> + The kernel will disable all functionality disabled by
> + the integrity mode, but additionally will disable
> + features that potentially permit userland to obtain
> + confidential information stored within the kernel.
[+ linuxppc, mpe, dja, cmr]
I'm thinking about whether we should lock down the powerpc xmon debug
monitor - intuitively, I think the answer is yes if for no other reason
than Least Astonishment, when lockdown is enabled you probably don't
expect xmon to keep letting you access kernel memory.
Semantically though, xmon is not a userspace process - it's in kernel
and reads debug commands/outputs debug data directly from/to the
console. Is that a threat vector that this series cares about?
--
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com IBM Australia Limited
^ permalink raw reply
* Re: [PATCH] mm: security: introduce CONFIG_INIT_HEAP_ALL
From: Vlastimil Babka @ 2019-04-16 8:33 UTC (permalink / raw)
To: Andrew Morton, Alexander Potapenko
Cc: linux-security-module, linux-mm, ndesaulniers, kcc, dvyukov,
keescook, sspatil, labbott, kernel-hardening
In-Reply-To: <20190415190213.5831bbc17e5073690713b001@linux-foundation.org>
On 4/16/19 4:02 AM, Andrew Morton wrote:
> Requiring a kernel rebuild is rather user-hostile. A boot option
> (early_param()) would be much more useful and I expect that the loss in
> coverage would be small and acceptable? Could possibly use the
> static_branch infrastructure.
Agreed. There could be a config option to make it default on if no param
given. Then a config option to (not) compile this in at all would be
probably superfluous, although small systems/architectures without
effective static keys might care.
^ permalink raw reply
* Re: [PATCH] mm: security: introduce CONFIG_INIT_HEAP_ALL
From: Vlastimil Babka @ 2019-04-16 8:30 UTC (permalink / raw)
To: Alexander Potapenko, akpm
Cc: linux-security-module, linux-mm, ndesaulniers, kcc, dvyukov,
keescook, sspatil, labbott, kernel-hardening
In-Reply-To: <20190412124501.132678-1-glider@google.com>
On 4/12/19 2:45 PM, Alexander Potapenko wrote:
> +config INIT_HEAP_ALL
> + bool "Initialize kernel heap allocations"
Calling slab and page allocations together as "heap" is rather uncommon
in the kernel I think. But I don't have a better word right now.
> + default n
> + help
> + Enforce initialization of pages allocated from page allocator
> + and objects returned by kmalloc and friends.
> + Allocated memory is initialized with zeroes, preventing possible
> + information leaks and making the control-flow bugs that depend
> + on uninitialized values more deterministic.
> +
> config GCC_PLUGIN_STRUCTLEAK_VERBOSE
> bool "Report forcefully initialized variables"
> depends on GCC_PLUGIN_STRUCTLEAK
>
^ permalink raw reply
* Re: [PATCH v2 1/3] security: Create "kernel hardening" config area
From: Kees Cook @ 2019-04-16 4:02 UTC (permalink / raw)
To: Alexander Popov
Cc: Alexander Potapenko, Masahiro Yamada, James Morris,
Nick Desaulniers, Kostya Serebryany, Dmitry Vyukov, Sandeep Patil,
Laura Abbott, Randy Dunlap, Michal Marek, Emese Revfy,
Serge E. Hallyn, Kernel Hardening, linux-security-module,
linux-kbuild, LKML
In-Reply-To: <947dbe9a-3444-6fe4-9f79-f8f210da8960@linux.com>
On Mon, Apr 15, 2019 at 11:44 AM Alexander Popov <alex.popov@linux.com> wrote:
>
> On 11.04.2019 21:01, Kees Cook wrote:
> > Right now kernel hardening options are scattered around various Kconfig
> > files. This can be a central place to collect these kinds of options
> > going forward. This is initially populated with the memory initialization
> > options from the gcc-plugins.
> >
> > Signed-off-by: Kees Cook <keescook@chromium.org>
>
> Hello Kees, hello everyone!
>
> After applying this series the kernel config looks like that:
>
> ...
> ...
> CONFIG_LSM="yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor"
>
> #
> # Kernel hardening options
> #
>
> #
> # Memory initialization
> #
> CONFIG_INIT_STACK_NONE=y
> # CONFIG_GCC_PLUGIN_STRUCTLEAK_USER is not set
> # CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF is not set
> # CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL is not set
> # CONFIG_GCC_PLUGIN_STACKLEAK is not set
> CONFIG_CRYPTO=y
>
> #
> # Crypto core or helper
> #
> CONFIG_CRYPTO_ALGAPI=y
> ...
> ...
>
> What do you think about some separator between memory initialization options and
> CONFIG_CRYPTO?
This was true before too:
...
# CONFIG_DEFAULT_SECURITY_DAC is not set
CONFIG_LSM="yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor"
CONFIG_XOR_BLOCKS=y
CONFIG_ASYNC_CORE=y
CONFIG_ASYNC_MEMCPY=y
CONFIG_ASYNC_XOR=y
CONFIG_ASYNC_PQ=y
CONFIG_ASYNC_RAID6_RECOV=y
CONFIG_CRYPTO=y
...
Perhaps crypto/Kconfig's comment line could move to the top of the file?
comment "Crypto core or helper"
is what generates the separator...
--
Kees Cook
^ permalink raw reply
* Re: kernel BUG at kernel/cred.c:434!
From: Kees Cook @ 2019-04-16 3:40 UTC (permalink / raw)
To: Paul Moore
Cc: Oleg Nesterov, Casey Schaufler, chengjian (D), NeilBrown,
Anna Schumaker, Kees Cook, linux-kernel@vger.kernel.org, Al Viro,
Xiexiuqi (Xie XiuQi), Li Bin, Jason Yan, Peter Zijlstra,
Ingo Molnar, Linux Security Module list, SELinux
In-Reply-To: <CAHC9VhSk1_fWooexHK0+5cKum55qTvj3uv5sRE=aJ4mv2GHJZg@mail.gmail.com>
On Mon, Apr 15, 2019 at 11:20 AM Paul Moore <paul@paul-moore.com> wrote:
>
> On Mon, Apr 15, 2019 at 11:05 AM Oleg Nesterov <oleg@redhat.com> wrote:
> > On 04/15, Paul Moore wrote:
> > >
> > > On Mon, Apr 15, 2019 at 9:43 AM Oleg Nesterov <oleg@redhat.com> wrote:
> > > > Well, acct("/proc/self/attr/current") doesn't look like a good idea, but I do
> > > > not know where should we put the additional check... And probably
> > > > "echo /proc/self/attr/current > /proc/sys/kernel/core_pattern" can hit the
> > > > same problem, do_coredump() does override_creds() too.
> > > >
> > > > May be just add
> > > >
> > > > if (current->cred != current->real_cred)
> > > > return -EACCES;
> > > >
> > > > into proc_pid_attr_write(), I dunno.
> > >
> > > Is the problem that do_acct_process() is calling override_creds() and
> > > the returned/old credentials are being freed before do_acct_process()
> > > can reinstall the creds via revert_creds()? Presumably because the
> > > process accounting is causing the credentials to be replaced?
> >
> > Afaics, the problem is that do_acct_process() does override_creds() and
> > then __kernel_write(). Which calls proc_pid_attr_write(), which in turn calls
> > selinux_setprocattr(), which does another prepare_creds() + commit_creds();
> > and commit_creds() hits
> >
> > BUG_ON(task->cred != old);
>
> Gotcha. In the process of looking at the backtrace I forgot about the
> BUG_ON() at the top of the oops message.
>
> I wonder what terrible things would happen if we changed the BUG_ON()
> in commit_creds to simple returning an error an error code to the
> caller. There is a warning/requirement in commit_creds() function
> header comment that it should always return 0.
Would callers be expected to call abort_creds() on failure? There are
a number of places where it'd need fixing up. And would likely be best
with a __must_check marking.
It seems like avoiding the pathological case might be simpler?
--
Kees Cook
^ permalink raw reply
* Re: [PATCH] crypto: testmgr - allocate buffers with __GFP_COMP
From: Kees Cook @ 2019-04-16 3:14 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Herbert Xu, Kees Cook, Eric Biggers, Rik van Riel, linux-crypto,
Dmitry Vyukov, Geert Uytterhoeven, linux-security-module,
Linux ARM, Linux Kernel Mailing List, Laura Abbott, Linux-MM
In-Reply-To: <20190416021852.GA18616@bombadil.infradead.org>
On Mon, Apr 15, 2019 at 9:18 PM Matthew Wilcox <willy@infradead.org> wrote:
> I agree; if the crypto code is never going to try to go from the address of
> a byte in the allocation back to the head page, then there's no need to
> specify GFP_COMP.
>
> But that leaves us in the awkward situation where
> HARDENED_USERCOPY_PAGESPAN does need to be able to figure out whether
> 'ptr + n - 1' lies within the same allocation as ptr. Without using
> a compound page, there's no indication in the VM structures that these
> two pages were allocated as part of the same allocation.
>
> We could force all multi-page allocations to be compound pages if
> HARDENED_USERCOPY_PAGESPAN is enabled, but I worry that could break
> something. We could make it catch fewer problems by succeeding if the
> page is not compound. I don't know, these all seem like bad choices
> to me.
If GFP_COMP is _not_ the correct signal about adjacent pages being
part of the same allocation, then I agree: we need to drop this check
entirely from PAGESPAN. Is there anything else that indicates this
property? (Or where might we be able to store that info?)
There are other pagespan checks, though, so those could stay. But I'd
really love to gain page allocator allocation size checking ...
--
Kees Cook
^ permalink raw reply
* [PATCH 00/57] Convert files to ReST
From: Mauro Carvalho Chehab @ 2019-04-16 2:55 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, linux-riscv, linux-fbdev, linux-s390,
Greg Kroah-Hartman, linux-watchdog, xdp-newbies,
linux-samsung-soc, linux-acpi, linux-stm32, bpf, linux-ide,
linux-pm, dri-devel, linux-scsi, linux-gpio, linuxppc-dev, x86,
dm-devel, target-devel, netdev, kexec, linux-fpga, linux-rdma,
linux-kbuild, Thomas Gleixner, linux-security-module, linux-usb,
linux-arm-kernel
This series convert lots of files to be properly parsed by Sphinx
as ReST files.
As it touches on lot of stuff, the series is based on linux-next.
I have a separate patch series with do the actual rename and
adjustment of references. I opted to submit this first, as it
sounds easier to merge this way, as each subsystem maintainer
can apply the conversion directly on their trees (or at docs
tree), avoiding merge conflects.
Both this series and the next steps are on my devel git tree,
at:
https://git.linuxtv.org/mchehab/experimental.git/log/?h=all_with_indexes-v3
The final output in html can be seen at:
https://www.infradead.org/~mchehab/rst_conversion/
Mauro Carvalho Chehab (57):
docs: trace: fix some Sphinx warnings
docs: acpi: convert text files to ReST
docs: aoe: convert text files to ReST
docs: arm64: convert documentation to ReST format
docs: cdrom/cdrom-standard.tex: convert from LaTeX to ReST
docs: cdrom: convert remaining files to ReST
docs: cgroup-v1: convert to ReST file format
docs: cgroup-v1/blkio-controller.rst: add a note about CFQ scheduler
docs: cpu-freq: convert files to ReST
docs: device-mapper: convert it to ReST format
docs: extcon: move it to acpi dir and convert it to ReST
docs: fault-injection: convert it to ReST format
docs: fb: convert documentation to ReST format
docs: fpga: convert it to ReST
docs: gpio: convert it to ReST
docs: ide: convert it to ReST format
docs: infiniband: convert it to ReST format
docs: kbuild: convert it to ReST output
docs: kdump: convert it to ReST
docs: livepatch: convert it to ReST format
docs: locking: convert docs to ReST format
docs: mic: convert it to ReST format
docs: netlabel: convert it to ReST
docs: pcmcia: convert it to ReST format
docs: power: convert docs to ReST
docs: powerpc: convert docs to ReST
docs: pps/pps.txt convert it to ReST and move to API book
docs: ptp.txt: convert to ReST and move to driver-api
docs: riscv: convert it to ReST format
docs: s390: Debugging390.txt: convert table to ascii artwork
docs: s390: convert text files to ReST format
s390: include/asm/debug.h add kerneldoc markups
docs: serial: convert it to ReST format
docs: target: convert it to ReST format
docs: timers: convert documentation to ReST
docs: usb: convert documents to ReST
docs: watchdog: convert documents to ReST format
docs: x86: convert text files to ReST
docs: xilinx: convert eemi.txt to ReST
docs: scheduler: convert files to ReST
docs: EDID/HOWTO.txt: convert to ReST and move to kernel-API
docs: connector.txt: convert to ReST
docs: lcd-panel-cgram.txt convert it to ReST and move to admin-guide
docs: lp855x-driver.txt: convert to ReST and move to kernel-api
docs: m68k: convert it to ReST file format and add to arch bookset
docs: cma/debugfs.txt: convert to ReST and move to admin-guide/mm
docs: console.txt: convert to ReST format
docs: pti_intel_mid.txt: convert to ReST
docs: early-userspace: convert docs to ReST
docs: driver-model: convert it to ReST format
docs: arm: convert text files to ReST format
docs: memory-devices: convert ti-emif.txt to ReST format
docs: xen-tpmfront.txt: convert the file to ReST format
docs: bus-devices: ti-gpmc.txt: convert it to ReST
docs: nvmem: convert file to ReST format
docs: phy: convert samsung-usb2.txt to ReST format
docs: Prepare files to be renamed to *.rst
Documentation/EDID/HOWTO.txt | 29 +-
Documentation/acpi/DSD-properties-rules.txt | 4 +-
Documentation/acpi/acpi-lid.txt | 37 +-
Documentation/acpi/aml-debugger.txt | 31 +-
Documentation/acpi/apei/einj.txt | 59 +-
Documentation/acpi/apei/output_format.txt | 247 +-
Documentation/acpi/cppc_sysfs.txt | 52 +-
Documentation/acpi/debug.txt | 20 +-
.../drivers/extcon-intel-int3496.txt} | 14 +-
.../acpi/dsd/data-node-references.txt | 11 +-
Documentation/acpi/dsd/graph.txt | 24 +-
Documentation/acpi/dsd/leds.txt | 18 +-
Documentation/acpi/dsdt-override.txt | 4 +-
Documentation/acpi/enumeration.txt | 42 +-
Documentation/acpi/gpio-properties.txt | 42 +-
Documentation/acpi/i2c-muxes.txt | 21 +-
Documentation/acpi/initrd_table_override.txt | 90 +-
Documentation/acpi/linuxized-acpica.txt | 58 +-
Documentation/acpi/lpit.txt | 8 +-
Documentation/acpi/method-customizing.txt | 48 +-
Documentation/acpi/method-tracing.txt | 132 +-
Documentation/acpi/namespace.txt | 323 +-
Documentation/acpi/osi.txt | 3 +-
Documentation/acpi/scan_handlers.txt | 9 +-
Documentation/acpi/ssdt-overlays.txt | 128 +-
Documentation/acpi/video_extension.txt | 16 +-
Documentation/aoe/aoe.txt | 63 +-
Documentation/aoe/todo.txt | 3 +
Documentation/aoe/udev.txt | 2 +-
Documentation/arm/Booting | 71 +-
Documentation/arm/IXP4xx | 61 +-
Documentation/arm/Interrupts | 86 +-
Documentation/arm/Marvell/README | 537 ++--
Documentation/arm/Microchip/README | 63 +-
Documentation/arm/Netwinder | 59 +-
Documentation/arm/OMAP/DSS | 112 +-
Documentation/arm/OMAP/README | 7 +
Documentation/arm/OMAP/omap_pm | 55 +-
Documentation/arm/Porting | 14 +-
Documentation/arm/README | 50 +-
Documentation/arm/SA1100/ADSBitsy | 14 +-
Documentation/arm/SA1100/Assabet | 185 +-
Documentation/arm/SA1100/Brutus | 45 +-
Documentation/arm/SA1100/CERF | 10 +-
Documentation/arm/SA1100/FreeBird | 26 +-
Documentation/arm/SA1100/GraphicsClient | 46 +-
Documentation/arm/SA1100/GraphicsMaster | 13 +-
Documentation/arm/SA1100/HUW_WEBPANEL | 8 +-
Documentation/arm/SA1100/Itsy | 14 +-
Documentation/arm/SA1100/LART | 3 +-
Documentation/arm/SA1100/PLEB | 6 +-
Documentation/arm/SA1100/Pangolin | 10 +-
Documentation/arm/SA1100/Tifon | 4 +-
Documentation/arm/SA1100/Yopy | 5 +-
Documentation/arm/SA1100/empeg | 2 -
Documentation/arm/SA1100/nanoEngine | 6 +-
Documentation/arm/SA1100/serial_UART | 60 +-
Documentation/arm/SPEAr/overview.txt | 20 +-
Documentation/arm/Samsung-S3C24XX/CPUfreq.txt | 5 +-
.../arm/Samsung-S3C24XX/EB2410ITX.txt | 5 +-
Documentation/arm/Samsung-S3C24XX/GPIO.txt | 21 +-
Documentation/arm/Samsung-S3C24XX/H1940.txt | 5 +-
Documentation/arm/Samsung-S3C24XX/NAND.txt | 6 +-
.../arm/Samsung-S3C24XX/Overview.txt | 15 +-
Documentation/arm/Samsung-S3C24XX/S3C2412.txt | 5 +-
Documentation/arm/Samsung-S3C24XX/S3C2413.txt | 7 +-
.../arm/Samsung-S3C24XX/SMDK2440.txt | 5 +-
Documentation/arm/Samsung-S3C24XX/Suspend.txt | 20 +-
.../arm/Samsung-S3C24XX/USB-Host.txt | 16 +-
.../arm/Samsung/Bootloader-interface.txt | 27 +-
Documentation/arm/Samsung/GPIO.txt | 5 +-
Documentation/arm/Samsung/Overview.txt | 11 +-
Documentation/arm/Setup | 49 +-
Documentation/arm/VFP/release-notes.txt | 4 +-
.../arm/cluster-pm-race-avoidance.txt | 177 +-
Documentation/arm/firmware.txt | 14 +-
Documentation/arm/kernel_mode_neon.txt | 3 +
Documentation/arm/kernel_user_helpers.txt | 79 +-
Documentation/arm/keystone/Overview.txt | 47 +-
Documentation/arm/keystone/knav-qmss.txt | 6 +-
Documentation/arm/mem_alignment | 11 +-
Documentation/arm/memory.txt | 9 +-
Documentation/arm/nwfpe/NOTES | 3 +
Documentation/arm/nwfpe/README | 10 +-
Documentation/arm/nwfpe/README.FPE | 24 +-
Documentation/arm/nwfpe/TODO | 47 +-
Documentation/arm/pxa/mfp.txt | 106 +-
Documentation/arm/sti/overview.txt | 21 +-
Documentation/arm/sti/stih407-overview.txt | 9 +-
Documentation/arm/sti/stih415-overview.txt | 8 +-
Documentation/arm/sti/stih416-overview.txt | 5 +-
Documentation/arm/sti/stih418-overview.txt | 9 +-
.../arm/stm32/stm32f429-overview.rst | 5 +-
.../arm/stm32/stm32f746-overview.rst | 5 +-
.../arm/stm32/stm32f769-overview.rst | 5 +-
.../arm/stm32/stm32h743-overview.rst | 5 +-
.../arm/stm32/stm32mp157-overview.rst | 1 +
Documentation/arm/sunxi/README | 98 +-
Documentation/arm/sunxi/clocks.txt | 7 +-
Documentation/arm/swp_emulation | 24 +-
Documentation/arm/tcm.txt | 54 +-
Documentation/arm/uefi.txt | 39 +-
Documentation/arm/vlocks.txt | 9 +-
Documentation/arm64/acpi_object_usage.txt | 288 +-
Documentation/arm64/arm-acpi.txt | 153 +-
Documentation/arm64/booting.txt | 91 +-
Documentation/arm64/cpu-feature-registers.txt | 190 +-
Documentation/arm64/elf_hwcaps.txt | 50 +-
Documentation/arm64/hugetlbpage.txt | 7 +-
Documentation/arm64/legacy_instructions.txt | 43 +-
Documentation/arm64/memory.txt | 91 +-
.../arm64/pointer-authentication.txt | 2 +
Documentation/arm64/silicon-errata.txt | 63 +-
Documentation/arm64/sve.txt | 10 +-
Documentation/arm64/tagged-pointers.txt | 6 +-
Documentation/auxdisplay/lcd-panel-cgram.txt | 7 +-
Documentation/backlight/lp855x-driver.txt | 65 +-
Documentation/bt8xxgpio.txt | 1 -
Documentation/bus-devices/ti-gpmc.txt | 157 +-
Documentation/bus-virt-phys-mapping.txt | 50 +-
Documentation/cdrom/Makefile | 21 -
Documentation/cdrom/cdrom-standard.tex | 1026 -------
Documentation/cdrom/cdrom-standard.txt | 1063 +++++++
Documentation/cdrom/ide-cd | 178 +-
Documentation/cdrom/packet-writing.txt | 27 +-
Documentation/cgroup-v1/blkio-controller.txt | 103 +-
Documentation/cgroup-v1/cgroups.txt | 180 +-
Documentation/cgroup-v1/cpuacct.txt | 15 +-
Documentation/cgroup-v1/cpusets.txt | 203 +-
Documentation/cgroup-v1/devices.txt | 40 +-
Documentation/cgroup-v1/freezer-subsystem.txt | 14 +-
Documentation/cgroup-v1/hugetlb.txt | 31 +-
Documentation/cgroup-v1/memcg_test.txt | 259 +-
Documentation/cgroup-v1/memory.txt | 449 +--
Documentation/cgroup-v1/net_cls.txt | 37 +-
Documentation/cgroup-v1/net_prio.txt | 24 +-
Documentation/cgroup-v1/pids.txt | 78 +-
Documentation/cgroup-v1/rdma.txt | 66 +-
Documentation/cma/debugfs.txt | 6 +-
Documentation/connector/connector.txt | 128 +-
Documentation/console/console.txt | 61 +-
Documentation/cpu-freq/amd-powernow.txt | 11 +-
Documentation/cpu-freq/core.txt | 66 +-
Documentation/cpu-freq/cpu-drivers.txt | 217 +-
Documentation/cpu-freq/cpufreq-nforce2.txt | 12 +-
Documentation/cpu-freq/cpufreq-stats.txt | 141 +-
Documentation/cpu-freq/pcc-cpufreq.txt | 102 +-
.../device-mapper/cache-policies.txt | 24 +-
Documentation/device-mapper/cache.txt | 206 +-
Documentation/device-mapper/delay.txt | 29 +-
Documentation/device-mapper/dm-crypt.txt | 57 +-
Documentation/device-mapper/dm-flakey.txt | 45 +-
Documentation/device-mapper/dm-init.txt | 75 +-
Documentation/device-mapper/dm-integrity.txt | 55 +-
Documentation/device-mapper/dm-io.txt | 14 +-
Documentation/device-mapper/dm-log.txt | 5 +-
.../device-mapper/dm-queue-length.txt | 25 +-
Documentation/device-mapper/dm-raid.txt | 225 +-
.../device-mapper/dm-service-time.txt | 68 +-
Documentation/device-mapper/dm-uevent.txt | 143 +-
Documentation/device-mapper/dm-zoned.txt | 10 +-
Documentation/device-mapper/era.txt | 36 +-
Documentation/device-mapper/kcopyd.txt | 10 +-
Documentation/device-mapper/linear.txt | 100 +-
Documentation/device-mapper/log-writes.txt | 91 +-
.../device-mapper/persistent-data.txt | 4 +
Documentation/device-mapper/snapshot.txt | 116 +-
Documentation/device-mapper/statistics.txt | 62 +-
Documentation/device-mapper/striped.txt | 68 +-
Documentation/device-mapper/switch.txt | 47 +-
.../device-mapper/thin-provisioning.txt | 68 +-
Documentation/device-mapper/unstriped.txt | 111 +-
Documentation/device-mapper/verity.txt | 20 +-
Documentation/device-mapper/writecache.txt | 13 +-
Documentation/device-mapper/zero.txt | 14 +-
Documentation/driver-model/binding.txt | 20 +-
Documentation/driver-model/bus.txt | 69 +-
Documentation/driver-model/class.txt | 74 +-
.../driver-model/design-patterns.txt | 106 +-
Documentation/driver-model/device.txt | 57 +-
Documentation/driver-model/devres.txt | 50 +-
Documentation/driver-model/driver.txt | 112 +-
Documentation/driver-model/overview.txt | 37 +-
Documentation/driver-model/platform.txt | 30 +-
Documentation/driver-model/porting.txt | 333 +--
Documentation/early-userspace/README | 3 +
.../early-userspace/buffer-format.txt | 19 +-
.../fault-injection/fault-injection.txt | 265 +-
.../fault-injection/notifier-error-inject.txt | 18 +-
.../fault-injection/nvme-fault-injection.txt | 174 +-
.../fault-injection/provoke-crashes.txt | 40 +-
Documentation/fb/api.txt | 29 +-
Documentation/fb/arkfb.txt | 8 +-
Documentation/fb/aty128fb.txt | 31 +-
Documentation/fb/cirrusfb.txt | 47 +-
Documentation/fb/cmap_xfbdev.txt | 57 +-
Documentation/fb/deferred_io.txt | 28 +-
Documentation/fb/efifb.txt | 18 +-
Documentation/fb/ep93xx-fb.txt | 25 +-
Documentation/fb/fbcon.txt | 177 +-
Documentation/fb/framebuffer.txt | 79 +-
Documentation/fb/gxfb.txt | 22 +-
Documentation/fb/intel810.txt | 77 +-
Documentation/fb/intelfb.txt | 62 +-
Documentation/fb/internals.txt | 24 +-
Documentation/fb/lxfb.txt | 23 +-
Documentation/fb/matroxfb.txt | 526 ++--
Documentation/fb/metronomefb.txt | 8 +-
Documentation/fb/modedb.txt | 44 +-
Documentation/fb/pvr2fb.txt | 55 +-
Documentation/fb/pxafb.txt | 81 +-
Documentation/fb/s3fb.txt | 8 +-
Documentation/fb/sa1100fb.txt | 23 +-
Documentation/fb/sh7760fb.txt | 153 +-
Documentation/fb/sisfb.txt | 40 +-
Documentation/fb/sm501.txt | 7 +-
Documentation/fb/sm712fb.txt | 18 +-
Documentation/fb/sstfb.txt | 231 +-
Documentation/fb/tgafb.txt | 30 +-
Documentation/fb/tridentfb.txt | 34 +-
Documentation/fb/udlfb.txt | 55 +-
Documentation/fb/uvesafb.txt | 128 +-
Documentation/fb/vesafb.txt | 121 +-
Documentation/fb/viafb.txt | 393 +--
Documentation/fb/vt8623fb.txt | 10 +-
Documentation/fpga/dfl.txt | 58 +-
Documentation/gpio/sysfs.txt | 39 +-
Documentation/highuid.txt | 2 +-
Documentation/ide/ide-tape.txt | 23 +-
Documentation/ide/ide.txt | 147 +-
Documentation/ide/warm-plug-howto.txt | 10 +-
Documentation/index.rst | 1 +
Documentation/infiniband/core_locking.txt | 64 +-
Documentation/infiniband/ipoib.txt | 24 +-
Documentation/infiniband/opa_vnic.txt | 108 +-
Documentation/infiniband/sysfs.txt | 4 +-
Documentation/infiniband/tag_matching.txt | 5 +
Documentation/infiniband/user_mad.txt | 33 +-
Documentation/infiniband/user_verbs.txt | 12 +-
Documentation/kbuild/headers_install.txt | 5 +-
Documentation/kbuild/kbuild.txt | 119 +-
Documentation/kbuild/kconfig-language.txt | 232 +-
.../kbuild/kconfig-macro-language.txt | 37 +-
Documentation/kbuild/kconfig.txt | 136 +-
Documentation/kbuild/makefiles.txt | 518 ++--
Documentation/kbuild/modules.txt | 166 +-
Documentation/kdump/kdump.txt | 131 +-
Documentation/kdump/vmcoreinfo.txt | 59 +-
Documentation/kobject.txt | 2 +-
Documentation/ldm.txt | 3 +-
Documentation/livepatch/callbacks.txt | 12 +-
.../livepatch/cumulative-patches.txt | 14 +-
Documentation/livepatch/livepatch.txt | 56 +-
Documentation/livepatch/module-elf-format.txt | 211 +-
Documentation/livepatch/shadow-vars.txt | 65 +-
Documentation/locking/lockdep-design.txt | 41 +-
Documentation/locking/lockstat.txt | 219 +-
Documentation/locking/locktorture.txt | 105 +-
Documentation/locking/mutex-design.txt | 26 +-
Documentation/locking/rt-mutex-design.txt | 135 +-
Documentation/locking/rt-mutex.txt | 30 +-
Documentation/locking/spinlocks.txt | 32 +-
Documentation/locking/ww-mutex-design.txt | 82 +-
Documentation/m68k/kernel-options.txt | 319 +-
Documentation/memory-barriers.txt | 2 +-
Documentation/memory-devices/ti-emif.txt | 25 +-
Documentation/mic/mic_overview.txt | 6 +-
Documentation/mic/scif_overview.txt | 58 +-
Documentation/netlabel/cipso_ipv4.txt | 19 +-
Documentation/netlabel/introduction.txt | 16 +-
Documentation/netlabel/lsm_interface.txt | 16 +-
Documentation/numastat.txt | 1 -
Documentation/nvmem/nvmem.txt | 110 +-
Documentation/pcmcia/devicetable.txt | 4 +
Documentation/pcmcia/driver-changes.txt | 35 +-
Documentation/pcmcia/driver.txt | 18 +-
Documentation/pcmcia/locking.txt | 39 +-
Documentation/phy/samsung-usb2.txt | 60 +-
Documentation/pnp.txt | 11 +-
Documentation/power/apm-acpi.txt | 10 +-
Documentation/power/basic-pm-debugging.txt | 77 +-
Documentation/power/charger-manager.txt | 101 +-
Documentation/power/drivers-testing.txt | 5 +
Documentation/power/energy-model.txt | 101 +-
Documentation/power/freezing-of-tasks.txt | 91 +-
Documentation/power/interface.txt | 20 +-
Documentation/power/opp.txt | 175 +-
Documentation/power/pci.txt | 77 +-
Documentation/power/pm_qos_interface.txt | 127 +-
Documentation/power/power_supply_class.txt | 269 +-
Documentation/power/powercap/powercap.txt | 297 +-
Documentation/power/regulator/consumer.txt | 141 +-
Documentation/power/regulator/design.txt | 9 +-
Documentation/power/regulator/machine.txt | 47 +-
Documentation/power/regulator/overview.txt | 51 +-
Documentation/power/regulator/regulator.txt | 18 +-
Documentation/power/runtime_pm.txt | 234 +-
Documentation/power/s2ram.txt | 20 +-
.../power/suspend-and-cpuhotplug.txt | 42 +-
.../power/suspend-and-interrupts.txt | 2 +
Documentation/power/swsusp-and-swap-files.txt | 15 +-
Documentation/power/swsusp-dmcrypt.txt | 118 +-
Documentation/power/swsusp.txt | 639 ++--
Documentation/power/tricks.txt | 6 +-
Documentation/power/userland-swsusp.txt | 53 +-
Documentation/power/video.txt | 156 +-
Documentation/powerpc/DAWR-POWER9.txt | 10 +-
Documentation/powerpc/bootwrapper.txt | 28 +-
Documentation/powerpc/cpu_families.txt | 23 +-
Documentation/powerpc/cpu_features.txt | 6 +-
Documentation/powerpc/cxl.txt | 46 +-
Documentation/powerpc/cxlflash.txt | 8 +-
Documentation/powerpc/dscr.txt | 18 +-
.../powerpc/eeh-pci-error-recovery.txt | 108 +-
.../powerpc/firmware-assisted-dump.txt | 117 +-
Documentation/powerpc/hvcs.txt | 108 +-
Documentation/powerpc/isa-versions.rst | 13 +-
Documentation/powerpc/mpc52xx.txt | 12 +-
.../powerpc/pci_iov_resource_on_powernv.txt | 15 +-
Documentation/powerpc/pmu-ebb.txt | 1 +
Documentation/powerpc/ptrace.txt | 169 +-
Documentation/powerpc/qe_firmware.txt | 37 +-
Documentation/powerpc/syscall64-abi.txt | 29 +-
.../powerpc/transactional_memory.txt | 45 +-
Documentation/pps/pps.txt | 67 +-
Documentation/preempt-locking.txt | 2 +-
Documentation/pti/pti_intel_mid.txt | 135 +-
Documentation/ptp/ptp.txt | 26 +-
Documentation/rbtree.txt | 52 +-
Documentation/riscv/pmu.txt | 98 +-
Documentation/rtc.txt | 6 +-
Documentation/s390/3270.txt | 85 +-
Documentation/s390/CommonIO | 47 +-
Documentation/s390/DASD | 33 +-
Documentation/s390/Debugging390.txt | 2599 ++++++++++-------
Documentation/s390/cds.txt | 354 ++-
Documentation/s390/driver-model.txt | 179 +-
Documentation/s390/monreader.txt | 85 +-
Documentation/s390/qeth.txt | 36 +-
Documentation/s390/s390dbf.txt | 639 ++--
Documentation/s390/vfio-ap.txt | 487 +--
Documentation/s390/vfio-ccw.txt | 88 +-
Documentation/s390/zfcpdump.txt | 2 +
Documentation/scheduler/completion.txt | 38 +-
Documentation/scheduler/sched-arch.txt | 18 +-
Documentation/scheduler/sched-bwc.txt | 28 +-
Documentation/scheduler/sched-deadline.txt | 293 +-
Documentation/scheduler/sched-design-CFS.txt | 15 +-
Documentation/scheduler/sched-domains.txt | 8 +-
Documentation/scheduler/sched-energy.txt | 47 +-
Documentation/scheduler/sched-nice-design.txt | 6 +-
Documentation/scheduler/sched-rt-group.txt | 28 +-
Documentation/scheduler/sched-stats.txt | 35 +-
Documentation/security/tpm/xen-tpmfront.txt | 101 +-
Documentation/serial/README.cycladesZ | 5 +-
Documentation/serial/driver | 113 +-
Documentation/serial/moxa-smartio | 750 ++---
Documentation/serial/n_gsm.txt | 81 +-
Documentation/serial/rocket.txt | 144 +-
Documentation/serial/serial-iso7816.txt | 21 +-
Documentation/serial/serial-rs485.txt | 22 +-
Documentation/serial/tty.txt | 111 +-
Documentation/target/tcm_mod_builder.txt | 200 +-
Documentation/target/tcmu-design.txt | 268 +-
Documentation/timers/NO_HZ.txt | 40 +-
Documentation/timers/highres.txt | 11 +-
Documentation/timers/hpet.txt | 4 +-
Documentation/timers/hrtimers.txt | 6 +-
Documentation/timers/timekeeping.txt | 3 +-
Documentation/timers/timers-howto.txt | 15 +-
Documentation/trace/ftrace.rst | 1 +
Documentation/trace/histogram.rst | 86 +-
Documentation/usb/WUSB-Design-overview.txt | 56 +-
Documentation/usb/acm.txt | 156 +-
Documentation/usb/authorization.txt | 75 +-
Documentation/usb/chipidea.txt | 101 +-
Documentation/usb/dwc3.txt | 12 +-
Documentation/usb/ehci.txt | 42 +-
Documentation/usb/functionfs.txt | 17 +-
Documentation/usb/gadget-testing.txt | 609 ++--
Documentation/usb/gadget_configfs.txt | 302 +-
Documentation/usb/gadget_hid.txt | 175 +-
Documentation/usb/gadget_multi.txt | 43 +-
Documentation/usb/gadget_printer.txt | 155 +-
Documentation/usb/gadget_serial.txt | 73 +-
Documentation/usb/iuu_phoenix.txt | 34 +-
Documentation/usb/mass-storage.txt | 19 +-
Documentation/usb/misc_usbsevseg.txt | 9 +-
Documentation/usb/mtouchusb.txt | 42 +-
Documentation/usb/ohci.txt | 5 +-
Documentation/usb/rio.txt | 83 +-
Documentation/usb/usb-help.txt | 21 +-
Documentation/usb/usb-serial.txt | 203 +-
Documentation/usb/usbip_protocol.txt | 552 ++--
Documentation/usb/usbmon.txt | 100 +-
.../convert_drivers_to_kernel_api.txt | 109 +-
Documentation/watchdog/hpwdt.txt | 23 +-
Documentation/watchdog/mlx-wdt.txt | 24 +-
Documentation/watchdog/pcwd-watchdog.txt | 13 +-
Documentation/watchdog/watchdog-api.txt | 76 +-
.../watchdog/watchdog-kernel-api.txt | 89 +-
.../watchdog/watchdog-parameters.txt | 672 +++--
Documentation/watchdog/watchdog-pm.txt | 3 +
Documentation/watchdog/wdt.txt | 31 +-
Documentation/x86/amd-memory-encryption.txt | 10 +-
Documentation/x86/boot.txt | 578 ++--
Documentation/x86/earlyprintk.txt | 69 +-
Documentation/x86/entry_64.txt | 11 +-
Documentation/x86/exception-tables.txt | 245 +-
Documentation/x86/i386/IO-APIC.txt | 23 +-
Documentation/x86/intel_mpx.txt | 55 +-
Documentation/x86/microcode.txt | 51 +-
Documentation/x86/mtrr.txt | 442 +--
Documentation/x86/orc-unwinder.txt | 1 +
Documentation/x86/pat.txt | 217 +-
Documentation/x86/protection-keys.txt | 33 +-
Documentation/x86/pti.txt | 8 +-
Documentation/x86/resctrl_ui.txt | 621 ++--
Documentation/x86/tlb.txt | 12 +-
Documentation/x86/topology.txt | 26 +-
Documentation/x86/usb-legacy-support.txt | 33 +-
Documentation/x86/x86_64/5level-paging.txt | 14 +-
Documentation/x86/x86_64/boot-options.txt | 98 +-
Documentation/x86/x86_64/mm.txt | 212 +-
Documentation/x86/x86_64/uefi.txt | 21 +-
Documentation/x86/zero-page.txt | 67 +-
Documentation/xilinx/eemi.txt | 8 +-
Documentation/zorro.txt | 5 +-
MAINTAINERS | 2 +-
arch/arm64/kernel/kexec_image.c | 2 +-
arch/s390/include/asm/debug.h | 231 ++
drivers/cdrom/cdrom.c | 2 +-
include/linux/connector.h | 63 +-
433 files changed, 21459 insertions(+), 16370 deletions(-)
rename Documentation/{extcon/intel-int3496.txt => acpi/drivers/extcon-intel-int3496.txt} (66%)
delete mode 100644 Documentation/arm/SA1100/empeg
delete mode 100644 Documentation/cdrom/Makefile
delete mode 100644 Documentation/cdrom/cdrom-standard.tex
create mode 100644 Documentation/cdrom/cdrom-standard.txt
--
2.20.1
^ permalink raw reply
* [PATCH 23/57] docs: netlabel: convert it to ReST
From: Mauro Carvalho Chehab @ 2019-04-16 2:55 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Paul Moore, netdev, linux-security-module
In-Reply-To: <cover.1555382110.git.mchehab+samsung@kernel.org>
Convert netlabel documentation to ReST.
This was trivial: just add proper title markups.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/netlabel/cipso_ipv4.txt | 19 +++++++++++++------
Documentation/netlabel/introduction.txt | 16 +++++++++++-----
Documentation/netlabel/lsm_interface.txt | 16 +++++++++++-----
3 files changed, 35 insertions(+), 16 deletions(-)
diff --git a/Documentation/netlabel/cipso_ipv4.txt b/Documentation/netlabel/cipso_ipv4.txt
index a6075481fd60..cbd3f3231221 100644
--- a/Documentation/netlabel/cipso_ipv4.txt
+++ b/Documentation/netlabel/cipso_ipv4.txt
@@ -1,10 +1,13 @@
+===================================
NetLabel CIPSO/IPv4 Protocol Engine
-==============================================================================
+===================================
+
Paul Moore, paul.moore@hp.com
May 17, 2006
- * Overview
+Overview
+========
The NetLabel CIPSO/IPv4 protocol engine is based on the IETF Commercial
IP Security Option (CIPSO) draft from July 16, 1992. A copy of this
@@ -13,7 +16,8 @@ draft can be found in this directory
it to an RFC standard it has become a de-facto standard for labeled
networking and is used in many trusted operating systems.
- * Outbound Packet Processing
+Outbound Packet Processing
+==========================
The CIPSO/IPv4 protocol engine applies the CIPSO IP option to packets by
adding the CIPSO label to the socket. This causes all packets leaving the
@@ -24,7 +28,8 @@ label by using the NetLabel security module API; if the NetLabel "domain" is
configured to use CIPSO for packet labeling then a CIPSO IP option will be
generated and attached to the socket.
- * Inbound Packet Processing
+Inbound Packet Processing
+=========================
The CIPSO/IPv4 protocol engine validates every CIPSO IP option it finds at the
IP layer without any special handling required by the LSM. However, in order
@@ -33,7 +38,8 @@ NetLabel security module API to extract the security attributes of the packet.
This is typically done at the socket layer using the 'socket_sock_rcv_skb()'
LSM hook.
- * Label Translation
+Label Translation
+=================
The CIPSO/IPv4 protocol engine contains a mechanism to translate CIPSO security
attributes such as sensitivity level and category to values which are
@@ -42,7 +48,8 @@ Domain Of Interpretation (DOI) definition and are configured through the
NetLabel user space communication layer. Each DOI definition can have a
different security attribute mapping table.
- * Label Translation Cache
+Label Translation Cache
+=======================
The NetLabel system provides a framework for caching security attribute
mappings from the network labels to the corresponding LSM identifiers. The
diff --git a/Documentation/netlabel/introduction.txt b/Documentation/netlabel/introduction.txt
index 3caf77bcff0f..9333bbb0adc1 100644
--- a/Documentation/netlabel/introduction.txt
+++ b/Documentation/netlabel/introduction.txt
@@ -1,10 +1,13 @@
+=====================
NetLabel Introduction
-==============================================================================
+=====================
+
Paul Moore, paul.moore@hp.com
August 2, 2006
- * Overview
+Overview
+========
NetLabel is a mechanism which can be used by kernel security modules to attach
security attributes to outgoing network packets generated from user space
@@ -12,7 +15,8 @@ applications and read security attributes from incoming network packets. It
is composed of three main components, the protocol engines, the communication
layer, and the kernel security module API.
- * Protocol Engines
+Protocol Engines
+================
The protocol engines are responsible for both applying and retrieving the
network packet's security attributes. If any translation between the network
@@ -24,7 +28,8 @@ the NetLabel kernel security module API described below.
Detailed information about each NetLabel protocol engine can be found in this
directory.
- * Communication Layer
+Communication Layer
+===================
The communication layer exists to allow NetLabel configuration and monitoring
from user space. The NetLabel communication layer uses a message based
@@ -33,7 +38,8 @@ formatting of these NetLabel messages as well as the Generic NETLINK family
names can be found in the 'net/netlabel/' directory as comments in the
header files as well as in 'include/net/netlabel.h'.
- * Security Module API
+Security Module API
+===================
The purpose of the NetLabel security module API is to provide a protocol
independent interface to the underlying NetLabel protocol engines. In addition
diff --git a/Documentation/netlabel/lsm_interface.txt b/Documentation/netlabel/lsm_interface.txt
index 638c74f7de7f..026fc267f798 100644
--- a/Documentation/netlabel/lsm_interface.txt
+++ b/Documentation/netlabel/lsm_interface.txt
@@ -1,10 +1,13 @@
+========================================
NetLabel Linux Security Module Interface
-==============================================================================
+========================================
+
Paul Moore, paul.moore@hp.com
May 17, 2006
- * Overview
+Overview
+========
NetLabel is a mechanism which can set and retrieve security attributes from
network packets. It is intended to be used by LSM developers who want to make
@@ -12,7 +15,8 @@ use of a common code base for several different packet labeling protocols.
The NetLabel security module API is defined in 'include/net/netlabel.h' but a
brief overview is given below.
- * NetLabel Security Attributes
+NetLabel Security Attributes
+============================
Since NetLabel supports multiple different packet labeling protocols and LSMs
it uses the concept of security attributes to refer to the packet's security
@@ -24,7 +28,8 @@ configuration. It is up to the LSM developer to translate the NetLabel
security attributes into whatever security identifiers are in use for their
particular LSM.
- * NetLabel LSM Protocol Operations
+NetLabel LSM Protocol Operations
+================================
These are the functions which allow the LSM developer to manipulate the labels
on outgoing packets as well as read the labels on incoming packets. Functions
@@ -32,7 +37,8 @@ exist to operate both on sockets as well as the sk_buffs directly. These high
level functions are translated into low level protocol operations based on how
the administrator has configured the NetLabel subsystem.
- * NetLabel Label Mapping Cache Operations
+NetLabel Label Mapping Cache Operations
+=======================================
Depending on the exact configuration, translation between the network packet
label and the internal LSM security identifier can be time consuming. The
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] crypto: testmgr - allocate buffers with __GFP_COMP
From: Matthew Wilcox @ 2019-04-16 2:18 UTC (permalink / raw)
To: Herbert Xu
Cc: Kees Cook, Eric Biggers, Rik van Riel, linux-crypto,
Dmitry Vyukov, Geert Uytterhoeven, linux-security-module,
Linux ARM, Linux Kernel Mailing List, Laura Abbott, linux-mm
In-Reply-To: <20190415024615.f765e7oagw26ezam@gondor.apana.org.au>
On Mon, Apr 15, 2019 at 10:46:15AM +0800, Herbert Xu wrote:
> On Sun, Apr 14, 2019 at 07:24:12PM -0700, Matthew Wilcox wrote:
> > On Thu, Apr 11, 2019 at 01:32:32PM -0700, Kees Cook wrote:
> > > > @@ -156,7 +156,8 @@ static int __testmgr_alloc_buf(char *buf[XBUFSIZE], int order)
> > > > int i;
> > > >
> > > > for (i = 0; i < XBUFSIZE; i++) {
> > > > - buf[i] = (char *)__get_free_pages(GFP_KERNEL, order);
> > > > + buf[i] = (char *)__get_free_pages(GFP_KERNEL | __GFP_COMP,
> > > > + order);
> > >
> > > Is there a reason __GFP_COMP isn't automatically included in all page
> > > allocations? (Or rather, it seems like the exception is when things
> > > should NOT be considered part of the same allocation, so something
> > > like __GFP_SINGLE should exist?.)
> >
> > The question is not whether or not things should be considered part of the
> > same allocation. The question is whether the allocation is of a compound
> > page or of N consecutive pages. Now you're asking what the difference is,
> > and it's whether you need to be able to be able to call compound_head(),
> > compound_order(), PageTail() or use a compound_dtor. If you don't, then
> > you can save some time at allocation & free by not specifying __GFP_COMP.
>
> Thanks for clarifying Matthew.
>
> Eric, this means that we should not use __GFP_COMP here just to
> silent what is clearly a broken warning.
I agree; if the crypto code is never going to try to go from the address of
a byte in the allocation back to the head page, then there's no need to
specify GFP_COMP.
But that leaves us in the awkward situation where
HARDENED_USERCOPY_PAGESPAN does need to be able to figure out whether
'ptr + n - 1' lies within the same allocation as ptr. Without using
a compound page, there's no indication in the VM structures that these
two pages were allocated as part of the same allocation.
We could force all multi-page allocations to be compound pages if
HARDENED_USERCOPY_PAGESPAN is enabled, but I worry that could break
something. We could make it catch fewer problems by succeeding if the
page is not compound. I don't know, these all seem like bad choices
to me.
^ permalink raw reply
* Re: [PATCH] mm: security: introduce CONFIG_INIT_HEAP_ALL
From: Andrew Morton @ 2019-04-16 2:02 UTC (permalink / raw)
To: Alexander Potapenko
Cc: linux-security-module, linux-mm, ndesaulniers, kcc, dvyukov,
keescook, sspatil, labbott, kernel-hardening
In-Reply-To: <20190412124501.132678-1-glider@google.com>
On Fri, 12 Apr 2019 14:45:01 +0200 Alexander Potapenko <glider@google.com> wrote:
> This config option adds the possibility to initialize newly allocated
> pages and heap objects with zeroes.
At what cost? Some performance test results would help this along.
> This is needed to prevent possible
> information leaks and make the control-flow bugs that depend on
> uninitialized values more deterministic.
>
> Initialization is done at allocation time at the places where checks for
> __GFP_ZERO are performed. We don't initialize slab caches with
> constructors or SLAB_TYPESAFE_BY_RCU to preserve their semantics.
>
> For kernel testing purposes filling allocations with a nonzero pattern
> would be more suitable, but may require platform-specific code. To have
> a simple baseline we've decided to start with zero-initialization.
>
> No performance optimizations are done at the moment to reduce double
> initialization of memory regions.
Requiring a kernel rebuild is rather user-hostile. A boot option
(early_param()) would be much more useful and I expect that the loss in
coverage would be small and acceptable? Could possibly use the
static_branch infrastructure.
> --- a/mm/slab.h
> +++ b/mm/slab.h
> @@ -167,6 +167,16 @@ static inline slab_flags_t kmem_cache_flags(unsigned int object_size,
> SLAB_TEMPORARY | \
> SLAB_ACCOUNT)
>
> +/*
> + * Do we need to initialize this allocation?
> + * Always true for __GFP_ZERO, CONFIG_INIT_HEAP_ALL enforces initialization
> + * of caches without constructors and RCU.
> + */
> +#define SLAB_WANT_INIT(cache, gfp_flags) \
> + ((GFP_INIT_ALWAYS_ON && !(cache)->ctor && \
> + !((cache)->flags & SLAB_TYPESAFE_BY_RCU)) || \
> + (gfp_flags & __GFP_ZERO))
Is there any reason why this *must* be implemented as a macro? If not,
it should be written in C please.
^ permalink raw reply
* Re: [PULL] Smack: Changes for 5.2
From: James Morris @ 2019-04-16 0:33 UTC (permalink / raw)
To: Casey Schaufler; +Cc: Linux Security Module list
In-Reply-To: <9a7f3da5-a80c-0fa6-c66d-70a1ef61af6f@schaufler-ca.com>
On Mon, 15 Apr 2019, Casey Schaufler wrote:
> James, please take these updates for 5.2. There's one bug fix for
> IPv6 handling and two memory use improvements.
>
> The following changes since commit 9d7b7bfbafba5e6cad609f1188243a7f0cd0d293:
>
> Merge tag 'v5.1-rc2' into next-general (2019-03-26 16:28:01 -0700)
>
> are available in the Git repository at:
>
> https://github.com/cschaufler/next-smack smack-for-5.2
>
> for you to fetch changes up to f7450bc6e76860564f3842a41892f9b74313cc23:
>
> Smack: Fix IPv6 handling of 0 secmark (2019-04-03 14:28:38 -0700)
Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-smack
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [RFC PATCH v1 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()
From: Steve Grubb @ 2019-04-15 18:47 UTC (permalink / raw)
To: Jan Kara
Cc: Mickaël Salaün, linux-kernel, Al Viro, James Morris,
Jonathan Corbet, Kees Cook, Matthew Garrett, Michael Kerrisk,
Mickaël Salaün, Mimi Zohar, Philippe Trébuchet,
Shuah Khan, Thibaut Sautereau, Vincent Strubel, Yves-Alexis Perez,
kernel-hardening, linux-api, linux-security-module, linux-fsdevel,
Matthew Bobrowski
In-Reply-To: <20181212144306.GA19945@quack2.suse.cz>
Hello,
On Wednesday, December 12, 2018 9:43:06 AM EDT Jan Kara wrote:
> On Wed 12-12-18 09:17:08, Mickaël Salaün wrote:
> > When the O_MAYEXEC flag is passed, sys_open() may be subject to
> > additional restrictions depending on a security policy implemented by an
> > LSM through the inode_permission hook.
> >
> > The underlying idea is to be able to restrict scripts interpretation
> > according to a policy defined by the system administrator. For this to
> > be possible, script interpreters must use the O_MAYEXEC flag
> > appropriately. To be fully effective, these interpreters also need to
> > handle the other ways to execute code (for which the kernel can't help):
> > command line parameters (e.g., option -e for Perl), module loading
> > (e.g., option -m for Python), stdin, file sourcing, environment
> > variables, configuration files... According to the threat model, it may
> > be acceptable to allow some script interpreters (e.g. Bash) to interpret
> > commands from stdin, may it be a TTY or a pipe, because it may not be
> > enough to (directly) perform syscalls.
> >
> > A simple security policy implementation is available in a following
> > patch for Yama.
> >
> > This is an updated subset of the patch initially written by Vincent
> > Strubel for CLIP OS:
> > https://github.com/clipos-archive/src_platform_clip-patches/blob/f5cb330d
> > 6b684752e403b4e41b39f7004d88e561/1901_open_mayexec.patch This patch has
> > been used for more than 10 years with customized script interpreters.
> > Some examples can be found here:
> > https://github.com/clipos-archive/clipos4_portage-overlay/search?q=O_MAYE
> > XEC
> >
> > Signed-off-by: Mickaël Salaün <mic@digikod.net>
> > Signed-off-by: Thibaut Sautereau <thibaut.sautereau@ssi.gouv.fr>
> > Signed-off-by: Vincent Strubel <vincent.strubel@ssi.gouv.fr>
> > Reviewed-by: Philippe Trébuchet <philippe.trebuchet@ssi.gouv.fr>
> > Cc: Al Viro <viro@zeniv.linux.org.uk>
> > Cc: Kees Cook <keescook@chromium.org>
> > Cc: Mickaël Salaün <mickael.salaun@ssi.gouv.fr>
>
> ...
>
> > diff --git a/fs/open.c b/fs/open.c
> > index 0285ce7dbd51..75479b79a58f 100644
> > --- a/fs/open.c
> > +++ b/fs/open.c
> > @@ -974,6 +974,10 @@ static inline int build_open_flags(int flags,
> > umode_t mode, struct open_flags *o>
> > if (flags & O_APPEND)
> >
> > acc_mode |= MAY_APPEND;
> >
> > + /* Check execution permissions on open. */
> > + if (flags & O_MAYEXEC)
> > + acc_mode |= MAY_OPENEXEC;
> > +
> >
> > op->acc_mode = acc_mode;
> >
> > op->intent = flags & O_PATH ? 0 : LOOKUP_OPEN;
>
> I don't feel experienced enough in security to tell whether we want this
> functionality or not. But if we do this, shouldn't we also set FMODE_EXEC
> on the resulting struct file? That way also security_file_open() can be
> used to arbitrate such executable opens and in particular
> fanotify permission event FAN_OPEN_EXEC will get properly generated which I
> guess is desirable (support for it is sitting in my tree waiting for the
> merge window) - adding some audit people involved in FAN_OPEN_EXEC to CC.
> Just an idea...
Late in replying. But I think it's important to have a deep look into the
issue.
TL;DR - This is a gentle man's handshake. It won't _really_ solve the
problem.
This flag that is being proposed means that you would have to patch all
interpreters to use it. If you are sure that upstreams will accept that, why
not just change the policy to interpreters shouldn't execute anything unless
the execute bit is set? That is simpler and doesn't need a kernel change. And
setting the execute bit is an auditable event.
The bottom line is that any interpreter has to become a security policy
enforcement point whether by indicating it wants to execute by setting a flag
or by refusing to use a file without execute bit set. But this just moves the
problem to one that is harder to fix. Why in the world does any programming
language allow programs to be loaded via stdin?
It is possible to wget a program and pipe it into python which subsequently
pulls down an ELF shared object and runs it all without touching disk via
memfd_create (e.g. SnakeEater). This is all direct to memory execution. And
direct to memory bypasses anti-virus, selinux, IMA, application whitelisting,
and other integrity schemes.
So, to fix this problem, you really need to not allow any programs to load via
stdin so that everything that executes has to touch disk. This way you can
get a fanotify event and see the application and vote yes/no on allowing it.
And this will be particularly harder with the memfd_create fix for the runc
container breakout. Prior to that, there were very few uses of that system
call. Now it may be very common which means finding malicious use just got
harder to spot.
But assuming these problems got fixed, then we have yet another place to look.
Many interpreters allow you to specify a command to run via arguments. Some
have a small buffer and some allow lengthy programs to be entered as an
argument. One strategy might be that an attacker can bootstrap a lengthier
program across the network. Python for example allows loading modules across
a network. All you need to put in the commandline is the override for the
module loader and a couple modules to import. It then loads the modules
remotely. Getting rid of this hole will likely lead to some unhappy people -
meaning it can't be fixed.
And even if we get that fixed, we have one last hole to plug. Shells. One can
simply start a shell and paste their program into the shell and then execute
it. You can easily do this with bash or python or any language that has a
REPL (read–eval–print loop). To fix this means divorcing the notion of a
language from a REPL. Production systems really do not need a Python shell,
they need the interpreter. I doubt that this would be popular. But fixing each
of these issues is what it would take to prevent unknown software from
running. Not going this far leaves holes.
Best Regards,
-Steve
^ permalink raw reply
* Re: [PATCH 1/3] selinux: Check address length before reading address family
From: Paul Moore @ 2019-04-15 16:46 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: linux-security-module, selinux
In-Reply-To: <1555066776-9758-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp>
On Fri, Apr 12, 2019 at 7:00 AM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> KMSAN will complain if valid address length passed to bind()/connect() is
> shorter than sizeof("struct sockaddr"->sa_family) bytes.
>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> ---
> security/selinux/hooks.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
A reminder to please CC the SELinux mailing list on patches such as these.
This looks good to me, and since it's specific to SELinux, I've gone
ahead and merged it into the selinux/next branch. Thanks for your
help on this.
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index d5fdcb0d26fe..c61787b15f27 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -4512,7 +4512,7 @@ static int selinux_socket_bind(struct socket *sock, struct sockaddr *address, in
> struct lsm_network_audit net = {0,};
> struct sockaddr_in *addr4 = NULL;
> struct sockaddr_in6 *addr6 = NULL;
> - u16 family_sa = address->sa_family;
> + u16 family_sa;
> unsigned short snum;
> u32 sid, node_perm;
>
> @@ -4522,6 +4522,9 @@ static int selinux_socket_bind(struct socket *sock, struct sockaddr *address, in
> * need to check address->sa_family as it is possible to have
> * sk->sk_family = PF_INET6 with addr->sa_family = AF_INET.
> */
> + if (addrlen < offsetofend(struct sockaddr, sa_family))
> + return -EINVAL;
> + family_sa = address->sa_family;
> switch (family_sa) {
> case AF_UNSPEC:
> case AF_INET:
> @@ -4654,6 +4657,8 @@ static int selinux_socket_connect_helper(struct socket *sock,
> * need to check address->sa_family as it is possible to have
> * sk->sk_family = PF_INET6 with addr->sa_family = AF_INET.
> */
> + if (addrlen < offsetofend(struct sockaddr, sa_family))
> + return -EINVAL;
> switch (address->sa_family) {
> case AF_INET:
> addr4 = (struct sockaddr_in *)address;
> --
> 2.16.5
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH v2 1/3] security: Create "kernel hardening" config area
From: Alexander Popov @ 2019-04-15 16:44 UTC (permalink / raw)
To: Kees Cook, Alexander Potapenko, Masahiro Yamada, James Morris
Cc: Nick Desaulniers, Kostya Serebryany, Dmitry Vyukov, Sandeep Patil,
Laura Abbott, Randy Dunlap, Michal Marek, Emese Revfy,
Serge E. Hallyn, kernel-hardening, linux-security-module,
linux-kbuild, linux-kernel
In-Reply-To: <20190411180117.27704-2-keescook@chromium.org>
On 11.04.2019 21:01, Kees Cook wrote:
> Right now kernel hardening options are scattered around various Kconfig
> files. This can be a central place to collect these kinds of options
> going forward. This is initially populated with the memory initialization
> options from the gcc-plugins.
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
Hello Kees, hello everyone!
After applying this series the kernel config looks like that:
...
...
CONFIG_LSM="yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor"
#
# Kernel hardening options
#
#
# Memory initialization
#
CONFIG_INIT_STACK_NONE=y
# CONFIG_GCC_PLUGIN_STRUCTLEAK_USER is not set
# CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF is not set
# CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL is not set
# CONFIG_GCC_PLUGIN_STACKLEAK is not set
CONFIG_CRYPTO=y
#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
...
...
What do you think about some separator between memory initialization options and
CONFIG_CRYPTO?
Best regards,
Alexander
^ 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