* [PATCH v2 2/2] capabilities: Add a securebit to disable PR_CAP_AMBIENT_RAISE
From: Andy Lutomirski @ 2015-05-15 6:39 UTC (permalink / raw)
To: Serge Hallyn, Andrew Morton
Cc: Jarkko Sakkinen, Andrew Lutomirski, Ted Ts'o,
Andrew G. Morgan, Linux API, Mimi Zohar, Michael Kerrisk,
Austin S Hemmelgarn, linux-security-module, Aaron Jones,
Serge Hallyn, LKML, Markku Savela, Kees Cook, Jonathan Corbet,
Christoph Lameter, Andy Lutomirski
In-Reply-To: <cover.1431671529.git.luto@kernel.org>
Per Andrew Morgan's request, add a securebit to allow admins to
disable PR_CAP_AMBIENT_RAISE. This securebit will prevent processes
from adding capabilities to their ambient set.
For simplicity, this disables PR_CAP_AMBIENT_RAISE entirely rather
than just disabling setting previously cleared bits.
Requested-by: Andrew G. Morgan <morgan@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Christoph Lameter <cl@linux.com>
Cc: Serge Hallyn <serge.hallyn@canonical.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Aaron Jones <aaronmdjones@gmail.com>
CC: Ted Ts'o <tytso@mit.edu>
Cc: linux-security-module@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-api@vger.kernel.org
Cc: akpm@linuxfoundation.org
Cc: Andrew G. Morgan <morgan@kernel.org>
Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: Austin S Hemmelgarn <ahferroin7@gmail.com>
Cc: Markku Savela <msa@moth.iki.fi>
Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
---
include/uapi/linux/securebits.h | 11 ++++++++++-
security/commoncap.c | 3 ++-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/securebits.h b/include/uapi/linux/securebits.h
index 985aac9e6bf8..35ac35cef217 100644
--- a/include/uapi/linux/securebits.h
+++ b/include/uapi/linux/securebits.h
@@ -43,9 +43,18 @@
#define SECBIT_KEEP_CAPS (issecure_mask(SECURE_KEEP_CAPS))
#define SECBIT_KEEP_CAPS_LOCKED (issecure_mask(SECURE_KEEP_CAPS_LOCKED))
+/* When set, a process cannot add new capabilities to its ambient set. */
+#define SECURE_NO_CAP_AMBIENT_RAISE 6
+#define SECURE_NO_CAP_AMBIENT_RAISE_LOCKED 7 /* make bit-6 immutable */
+
+#define SECBIT_NO_CAP_AMBIENT_RAISE (issecure_mask(SECURE_NO_CAP_AMBIENT_RAISE))
+#define SECBIT_NO_CAP_AMBIENT_RAISE_LOCKED \
+ (issecure_mask(SECURE_NO_CAP_AMBIENT_RAISE_LOCKED))
+
#define SECURE_ALL_BITS (issecure_mask(SECURE_NOROOT) | \
issecure_mask(SECURE_NO_SETUID_FIXUP) | \
- issecure_mask(SECURE_KEEP_CAPS))
+ issecure_mask(SECURE_KEEP_CAPS) | \
+ issecure_mask(SECURE_NO_CAP_AMBIENT_RAISE))
#define SECURE_ALL_LOCKS (SECURE_ALL_BITS << 1)
#endif /* _UAPI_LINUX_SECUREBITS_H */
diff --git a/security/commoncap.c b/security/commoncap.c
index 09541a6a85a0..98aa1b129c12 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -983,7 +983,8 @@ int cap_task_prctl(int option, unsigned long arg2, unsigned long arg3,
if (arg2 == PR_CAP_AMBIENT_RAISE &&
(!cap_raised(current_cred()->cap_permitted, arg3) ||
!cap_raised(current_cred()->cap_inheritable,
- arg3)))
+ arg3) ||
+ issecure(SECURE_NO_CAP_AMBIENT_RAISE)))
return -EPERM;
new = prepare_creds();
--
2.1.0
^ permalink raw reply related
* [PATCH man-pages v2] capabilities.7, prctl.2: Document ambient capabilities
From: Andy Lutomirski @ 2015-05-15 6:43 UTC (permalink / raw)
To: Serge Hallyn, Andrew Morton
Cc: Jarkko Sakkinen, Andrew Lutomirski, Ted Ts'o,
Andrew G. Morgan, Linux API, Mimi Zohar, Michael Kerrisk,
Austin S Hemmelgarn, linux-security-module, Aaron Jones,
Serge Hallyn, LKML, Markku Savela, Kees Cook, Jonathan Corbet
Signed-off-by: Andy Lutomirski <luto@kernel.org>
---
There was no v1. I'm calling this v2 to keep it in sync with the kernel
patch versioning.
man2/prctl.2 | 10 ++++++++++
man7/capabilities.7 | 32 ++++++++++++++++++++++++++------
2 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/man2/prctl.2 b/man2/prctl.2
index b352f6283624..5861e3aefe9a 100644
--- a/man2/prctl.2
+++ b/man2/prctl.2
@@ -949,6 +949,16 @@ had been called.
For further information on Intel MPX, see the kernel source file
.IR Documentation/x86/intel_mpx.txt .
.\"
+.TP
+.BR PR_CAP_AMBIENT " (since Linux 4.2)"
+Reads or changes the ambient capability set. If arg2 is PR_CAP_AMBIENT_RAISE,
+then the capability specified in arg3 is added to the ambient set. This will
+fail, returning EPERM, if the capability is not already both permitted and
+inheritable or if the SECBIT_NO_CAP_AMBIENT_RAISE securebit is set. If arg2
+is PR_CAP_AMBIENT_LOWER, then the capability specified in arg3 is removed
+from the ambient set. If arg2 is PR_CAP_AMBIENT_GET, then
+.BR prctl (2)
+will return 1 if the capability in arg3 is in the ambient set and 0 if not.
.SH RETURN VALUE
On success,
.BR PR_GET_DUMPABLE ,
diff --git a/man7/capabilities.7 b/man7/capabilities.7
index d75ec65de05b..dae62f0be3b7 100644
--- a/man7/capabilities.7
+++ b/man7/capabilities.7
@@ -697,13 +697,26 @@ a program whose associated file capabilities grant that capability).
.IR Inheritable :
This is a set of capabilities preserved across an
.BR execve (2).
-It provides a mechanism for a process to assign capabilities
-to the permitted set of the new program during an
-.BR execve (2).
+Inheritable capabilities remain inheritable when executing any program,
+and inheritable capabilities are added to the permitted set when executing
+a program that has the corresponding bits set in the file inheritable set.
+When executing programs without file capabilities, ambient capabilities
.TP
.IR Effective :
This is the set of capabilities used by the kernel to
perform permission checks for the thread.
+.TP
+.IR Ambient " (since Linux 4.2) :"
+This is a set of capabilities that are preserved across an
+.BR execve (2)
+of a program that does not have file capabilities. The ambient capability
+set obeys the invariant that no capability can ever be ambient if it is
+not both permitted and inheritable. Ambient capabilities are, with some
+exceptions, preserved in the permitted set and added to the effective
+set when
+.BR execve (2)
+is called. The ambient capability set is modified using
+.BR prctl (2).
.PP
A child created via
.BR fork (2)
@@ -785,10 +798,12 @@ the process using the following algorithm:
.in +4n
.nf
+P'(ambient) = (file has capabilities or is setuid or setgid) ? 0 : P(ambient)
+
P'(permitted) = (P(inheritable) & F(inheritable)) |
- (F(permitted) & cap_bset)
+ (F(permitted) & cap_bset) | P'(ambient)
-P'(effective) = F(effective) ? P'(permitted) : 0
+P'(effective) = F(effective) ? P'(permitted) : P'(ambient)
P'(inheritable) = P(inheritable) [i.e., unchanged]
@@ -1071,6 +1086,10 @@ an effective or real UID of 0 calls
.BR execve (2).
(See the subsection
.IR "Capabilities and execution of programs by root" .)
+.TP
+.B SECBIT_NO_CAP_AMBIENT_RAISE
+Setting this flag disallows
+.BR PR_CAP_AMBIENT_RAISE .
.PP
Each of the above "base" flags has a companion "locked" flag.
Setting any of the "locked" flags is irreversible,
@@ -1079,8 +1098,9 @@ corresponding "base" flag.
The locked flags are:
.BR SECBIT_KEEP_CAPS_LOCKED ,
.BR SECBIT_NO_SETUID_FIXUP_LOCKED ,
+.BR SECBIT_NOROOT_LOCKED ,
and
-.BR SECBIT_NOROOT_LOCKED .
+.BR SECBIT_NO_CAP_AMBIENT_RAISE .
.PP
The
.I securebits
--
2.1.0
^ permalink raw reply related
* Re: [CFT][PATCH 0/10] Making new mounts of proc and sysfs as safe as bind mounts
From: Eric W. Biederman @ 2015-05-15 6:55 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Greg Kroah-Hartman, Linux Containers, Linux FS Devel, Linux API,
Serge E. Hallyn, Richard Weinberger, Kenton Varda,
Michael Kerrisk-manpages, Stéphane Graber, Eric Windisch,
Tejun Heo
In-Reply-To: <CALCETrU1yxcDfv4YV3wVpWMAdiOOsSUFOPUpFAN-mVA4M-OxdQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org> writes:
> Can we please just get rid of this implicit nodev thing once and for all? If it
> breaks some really weird /proc use case, then I think the right fix is to
> stop enforcing the nodev lock for the proc fully visible check. After
> all, /proc doesn't contain useful device nodes anyway.
On second look I don't think that will actually cause issues in this
case.
I actually have a fix for the implicit nodev weirdness in my development
qeueue but it requires figuring out how to add s_user_ns to superblocks.
My last round of testing told me I was doing that wrong.
But if the implicit nodev is actually a problem I will definitely delay
this until I have that change ready to go as well.
> Other than that, the code here looks okay to me on brief inspection.
At a practical level I am concerned that enforcing things like noexec
and nosuid from the original normal global proc might cause problems for
things like sandstorm, lxc, and possibly libvirt-lxc. So I would really
appreciate if people associated with those projects could test this and
tell me if I break things.
Other than my stupid refactor in my code for /proc/fs/nfsd that causes
the kernel to oops :( Doh!
Eric
^ permalink raw reply
* Re: [PATCH v2] Documentation/arch: Add kernel feature descriptions and arch support status under Documentation/features/
From: Ingo Molnar @ 2015-05-15 7:38 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, Josh Triplett, Borislav Petkov, Jonathan Corbet,
Peter Zijlstra, Andy Lutomirski, Ingo Molnar, H. Peter Anvin,
Thomas Gleixner, Linus Torvalds, linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
linux-arch-u79uwXL29TY76Z2rM5mHXA, Yoshinori Sato
In-Reply-To: <20150515083334.535ad43e-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
* Stephen Rothwell <sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org> wrote:
> Hi Ingo,
>
> Thanks for this. The concept is certainly good.
>
> On Thu, 14 May 2015 21:59:25 +0200 Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> >
> > The patch that adds a new architecture to all these files would give
> > us a good overview about how complete an initial port is.
>
> If you want to test how hard that is (and what sort of patch it
> produces), the h8300 architecture was added to linux-next recently.
I tried this out, this is the resulting feature support matrix for the
new h8300 architecture:
#
# Kernel feature support matrix of architecture 'h8300':
#
arch-tick-broadcast: | h8300: | TODO |
BPF-JIT: | h8300: | TODO |
clockevents: | h8300: | ok |
cmpxchg-local: | h8300: | TODO |
context-tracking: | h8300: | TODO |
dma-api-debug: | h8300: | TODO |
dma-contiguous: | h8300: | TODO |
dma_map_attrs: | h8300: | ok |
ELF-ASLR: | h8300: | TODO |
gcov-profile-all: | h8300: | TODO |
generic-idle-thread: | h8300: | TODO |
huge-vmap: | h8300: | TODO |
ioremap_prot: | h8300: | TODO |
irq-time-acct: | h8300: | TODO |
jump-labels: | h8300: | TODO |
KASAN: | h8300: | TODO |
kgdb: | h8300: | TODO |
kprobes: | h8300: | TODO |
kprobes-event: | h8300: | TODO |
kprobes-on-ftrace: | h8300: | TODO |
kretprobes: | h8300: | TODO |
lockdep: | h8300: | TODO |
modern-timekeeping: | h8300: | ok |
numa-balancing: | h8300: | .. |
numa-memblock: | h8300: | .. |
optprobes: | h8300: | TODO |
perf-regs: | h8300: | TODO |
perf-stackdump: | h8300: | TODO |
PG_uncached: | h8300: | TODO |
pmdp_splitting_flush: | h8300: | TODO |
pte_special: | h8300: | TODO |
queued-rwlocks: | h8300: | TODO |
queued-spinlocks: | h8300: | TODO |
rwsem-optimized: | h8300: | ok |
seccomp-filter: | h8300: | TODO |
sg-chain: | h8300: | TODO |
stackprotector: | h8300: | TODO |
strncasecmp: | h8300: | TODO |
THP: | h8300: | .. |
tracehook: | h8300: | TODO |
uprobes: | h8300: | TODO |
user-ret-profiler: | h8300: | TODO |
virt-cpuacct: | h8300: | TODO |
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH v2] Documentation/arch: Add kernel feature descriptions and arch support status under Documentation/features/
From: Ingo Molnar @ 2015-05-15 7:49 UTC (permalink / raw)
To: Michael Ellerman
Cc: Andrew Morton, Josh Triplett, Borislav Petkov, Jonathan Corbet,
Peter Zijlstra, Andy Lutomirski, Ingo Molnar, H. Peter Anvin,
Thomas Gleixner, Linus Torvalds, linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
linux-arch-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1431644248.2981.1.camel-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>
* Michael Ellerman <mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org> wrote:
> On Thu, 2015-05-14 at 12:38 -0700, Andrew Morton wrote:
> > > Add arch support matrices for more than 40 generic kernel features
> > > that need per architecture support.
> > >
> > > Each feature has its own directory under Documentation/features/feature_name/,
> > > and the arch-support.txt file shows its current arch porting status.
> >
> > It would be nice to provide people with commit IDs to look at, but the
> > IDs won't be known at the time the documentation file is created. We
> > could provide patch titles.
>
> +1 on patch titles.
Ok, I'll solve this.
> > But still, let's not overdo it - get something in there, see how
> > well it works, evolve it over time.
> >
> > I don't think we've heard from any (non-x86) arch maintainers? Do
> > they consider this useful at all? Poke.
>
> Yes it is. I have my own version I've cobbled together for powerpc,
> but this is much better.
Please double check the PowerPC support matrix for correctness (if you
haven't yet):
#
# Kernel feature support matrix of architecture 'powerpc':
#
arch-tick-broadcast: | ok | ARCH_HAS_TICK_BROADCAST # arch provides tick_broadcast()
BPF-JIT: | ok | HAVE_BPF_JIT # arch supports BPF JIT optimizations
clockevents: | ok | GENERIC_CLOCKEVENTS # arch support generic clock events
cmpxchg-local: | TODO | HAVE_CMPXCHG_LOCAL # arch supports the this_cpu_cmpxchg() API
context-tracking: | ok | HAVE_CONTEXT_TRACKING # arch supports context tracking for NO_HZ_FULL
dma-api-debug: | ok | HAVE_DMA_API_DEBUG # arch supports DMA debug facilities
dma-contiguous: | TODO | HAVE_DMA_CONTIGUOUS # arch supports the DMA CMA (continuous memory allocator)
dma_map_attrs: | ok | HAVE_DMA_ATTRS # arch provides dma_*map*_attrs() APIs
ELF-ASLR: | ok | ARCH_HAS_ELF_RANDOMIZE # arch randomizes the stack, heap and binary images of ELF binaries
gcov-profile-all: | ok | ARCH_HAS_GCOV_PROFILE_ALL # arch supports whole-kernel GCOV code coverage profiling
generic-idle-thread: | ok | GENERIC_SMP_IDLE_THREAD # arch makes use of the generic SMP idle thread facility
huge-vmap: | TODO | HAVE_ARCH_HUGE_VMAP # arch supports the ioremap_pud_enabled() and ioremap_pmd_enabled() VM APIs
ioremap_prot: | ok | HAVE_IOREMAP_PROT # arch has ioremap_prot()
irq-time-acct: | ok | HAVE_IRQ_TIME_ACCOUNTING # arch supports precise IRQ time accounting
jump-labels: | ok | HAVE_ARCH_JUMP_LABEL # arch supports live patched high efficiency branches
KASAN: | TODO | HAVE_ARCH_KASAN # arch supports the KASAN runtime memory checker
kgdb: | ok | HAVE_ARCH_KGDB # arch supports the kGDB kernel debugger
kprobes: | ok | HAVE_KPROBES # arch supports live patched kernel probe
kprobes-event: | ok | HAVE_REGS_AND_STACK_ACCESS_API # arch supports kprobes with perf events
kprobes-on-ftrace: | TODO | HAVE_KPROBES_ON_FTRACE # arch supports combined kprobes and ftrace live patching
kretprobes: | ok | HAVE_KRETPROBES # arch supports kernel function-return probes
lockdep: | ok | LOCKDEP_SUPPORT # arch supports the runtime locking correctness debug facility
modern-timekeeping: | ok | !ARCH_USES_GETTIMEOFFSET # arch does not use arch_gettimeoffset() anymore
numa-balancing: | ok | ARCH_SUPPORTS_NUMA_BALANCING && 64BIT && NUMA # arch supports NUMA balancing
numa-memblock: | ok | HAVE_MEMBLOCK_NODE_MAP # arch supports NUMA aware memblocks
optprobes: | TODO | HAVE_OPTPROBES # arch supports live patched optprobes
perf-regs: | TODO | HAVE_PERF_REGS # arch supports perf events register access
perf-stackdump: | TODO | HAVE_PERF_USER_STACK_DUMP # arch supports perf events stack dumps
PG_uncached: | TODO | ARCH_USES_PG_UNCACHED # arch supports the PG_uncached page flag
pmdp_splitting_flush: | ok | #define __HAVE_ARCH_PMDP_SPLITTING_FLUSH # arch supports the pmdp_splitting_flush() VM API
pte_special: | ok | #define __HAVE_ARCH_PTE_SPECIAL # arch supports the pte_special()/pte_mkspecial() VM APIs
queued-rwlocks: | TODO | ARCH_USE_QUEUED_RWLOCKS # arch supports queued rwlocks
queued-spinlocks: | TODO | ARCH_USE_QUEUED_SPINLOCKS # arch supports queued spinlocks
rwsem-optimized: | ok | Optimized asm/rwsem.h # arch provides optimized rwsem APIs
seccomp-filter: | TODO | HAVE_ARCH_SECCOMP_FILTER # arch supports seccomp filters
sg-chain: | ok | ARCH_HAS_SG_CHAIN # arch supports chained scatter-gather lists
stackprotector: | TODO | HAVE_CC_STACKPROTECTOR # arch supports compiler driven stack overflow protection
strncasecmp: | TODO | __HAVE_ARCH_STRNCASECMP # arch provides an optimized strncasecmp() function
THP: | ok | HAVE_ARCH_TRANSPARENT_HUGEPAGE && 64BIT # arch supports transparent hugepages
tracehook: | ok | HAVE_ARCH_TRACEHOOK # arch supports tracehook (ptrace) register handling APIs
uprobes: | ok | ARCH_SUPPORTS_UPROBES # arch supports live patched user probes
user-ret-profiler: | TODO | HAVE_USER_RETURN_NOTIFIER # arch supports user-space return from system call profiler
virt-cpuacct: | ok | HAVE_VIRT_CPU_ACCOUNTING || 64BIT # arch supports precise virtual CPU time accounting
> I'd like to see more description in the individual files of what the
> feature is, and preferably some pointers to what's needed to
> implement it.
Yeah, so I tried to add a short description to the feature file
itself, and for many of these features that single sentence is the
only documentation we have in the kernel source ...
More comprehensive description can be added both to the Kconfig and to
the feature description as well, by the maintainers of the individual
features.
> The kconfig for HAVE_ARCH_SECCOMP_FILTER is a good example of what I
> mean.
Yes, that's a positive example. It's the exception.
> I realise retrofitting that for all these existing features is quite
> time consuming, but for new features hopefully the bar can be raised
> a little in terms of that description.
Yeah.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH v2] Documentation/arch: Add kernel feature descriptions and arch support status under Documentation/features/
From: Ingo Molnar @ 2015-05-15 7:51 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, Josh Triplett, Borislav Petkov, Jonathan Corbet,
Peter Zijlstra, Andy Lutomirski, Ingo Molnar, H. Peter Anvin,
Thomas Gleixner, Linus Torvalds, linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, x86-DgEjT+Ai2ygdnm+yROfE0A,
linux-arch-u79uwXL29TY76Z2rM5mHXA, Yoshinori Sato
In-Reply-To: <20150515073805.GA14993-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
* Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>
> * Stephen Rothwell <sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org> wrote:
>
> > Hi Ingo,
> >
> > Thanks for this. The concept is certainly good.
> >
> > On Thu, 14 May 2015 21:59:25 +0200 Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > >
> > > The patch that adds a new architecture to all these files would give
> > > us a good overview about how complete an initial port is.
> >
> > If you want to test how hard that is (and what sort of patch it
> > produces), the h8300 architecture was added to linux-next recently.
>
> I tried this out, this is the resulting feature support matrix for the
> new h8300 architecture:
>
> #
> # Kernel feature support matrix of architecture 'h8300':
> #
> arch-tick-broadcast: | h8300: | TODO |
> BPF-JIT: | h8300: | TODO |
Perhaps the more verbose table is more useful:
#
# Kernel feature support matrix of architecture 'h8300':
#
arch-tick-broadcast: | TODO | ARCH_HAS_TICK_BROADCAST # arch provides tick_broadcast()
BPF-JIT: | TODO | HAVE_BPF_JIT # arch supports BPF JIT optimizations
clockevents: | ok | GENERIC_CLOCKEVENTS # arch support generic clock events
cmpxchg-local: | TODO | HAVE_CMPXCHG_LOCAL # arch supports the this_cpu_cmpxchg() API
context-tracking: | TODO | HAVE_CONTEXT_TRACKING # arch supports context tracking for NO_HZ_FULL
dma-api-debug: | TODO | HAVE_DMA_API_DEBUG # arch supports DMA debug facilities
dma-contiguous: | TODO | HAVE_DMA_CONTIGUOUS # arch supports the DMA CMA (continuous memory allocator)
dma_map_attrs: | ok | HAVE_DMA_ATTRS # arch provides dma_*map*_attrs() APIs
ELF-ASLR: | TODO | ARCH_HAS_ELF_RANDOMIZE # arch randomizes the stack, heap and binary images of ELF binaries
gcov-profile-all: | TODO | ARCH_HAS_GCOV_PROFILE_ALL # arch supports whole-kernel GCOV code coverage profiling
generic-idle-thread: | TODO | GENERIC_SMP_IDLE_THREAD # arch makes use of the generic SMP idle thread facility
huge-vmap: | TODO | HAVE_ARCH_HUGE_VMAP # arch supports the ioremap_pud_enabled() and ioremap_pmd_enabled() VM APIs
ioremap_prot: | TODO | HAVE_IOREMAP_PROT # arch has ioremap_prot()
irq-time-acct: | TODO | HAVE_IRQ_TIME_ACCOUNTING # arch supports precise IRQ time accounting
jump-labels: | TODO | HAVE_ARCH_JUMP_LABEL # arch supports live patched high efficiency branches
KASAN: | TODO | HAVE_ARCH_KASAN # arch supports the KASAN runtime memory checker
kgdb: | TODO | HAVE_ARCH_KGDB # arch supports the kGDB kernel debugger
kprobes: | TODO | HAVE_KPROBES # arch supports live patched kernel probe
kprobes-event: | TODO | HAVE_REGS_AND_STACK_ACCESS_API # arch supports kprobes with perf events
kprobes-on-ftrace: | TODO | HAVE_KPROBES_ON_FTRACE # arch supports combined kprobes and ftrace live patching
kretprobes: | TODO | HAVE_KRETPROBES # arch supports kernel function-return probes
lockdep: | TODO | LOCKDEP_SUPPORT # arch supports the runtime locking correctness debug facility
modern-timekeeping: | ok | !ARCH_USES_GETTIMEOFFSET # arch does not use arch_gettimeoffset() anymore
numa-balancing: | .. | ARCH_SUPPORTS_NUMA_BALANCING && 64BIT && NUMA # arch supports NUMA balancing
numa-memblock: | .. | HAVE_MEMBLOCK_NODE_MAP # arch supports NUMA aware memblocks
optprobes: | TODO | HAVE_OPTPROBES # arch supports live patched optprobes
perf-regs: | TODO | HAVE_PERF_REGS # arch supports perf events register access
perf-stackdump: | TODO | HAVE_PERF_USER_STACK_DUMP # arch supports perf events stack dumps
PG_uncached: | TODO | ARCH_USES_PG_UNCACHED # arch supports the PG_uncached page flag
pmdp_splitting_flush: | TODO | #define __HAVE_ARCH_PMDP_SPLITTING_FLUSH # arch supports the pmdp_splitting_flush() VM API
pte_special: | TODO | #define __HAVE_ARCH_PTE_SPECIAL # arch supports the pte_special()/pte_mkspecial() VM APIs
queued-rwlocks: | TODO | ARCH_USE_QUEUED_RWLOCKS # arch supports queued rwlocks
queued-spinlocks: | TODO | ARCH_USE_QUEUED_SPINLOCKS # arch supports queued spinlocks
rwsem-optimized: | ok | Optimized asm/rwsem.h # arch provides optimized rwsem APIs
seccomp-filter: | TODO | HAVE_ARCH_SECCOMP_FILTER # arch supports seccomp filters
sg-chain: | TODO | ARCH_HAS_SG_CHAIN # arch supports chained scatter-gather lists
stackprotector: | TODO | HAVE_CC_STACKPROTECTOR # arch supports compiler driven stack overflow protection
strncasecmp: | TODO | __HAVE_ARCH_STRNCASECMP # arch provides an optimized strncasecmp() function
THP: | .. | HAVE_ARCH_TRANSPARENT_HUGEPAGE && 64BIT # arch supports transparent hugepages
tracehook: | TODO | HAVE_ARCH_TRACEHOOK # arch supports tracehook (ptrace) register handling APIs
uprobes: | TODO | ARCH_SUPPORTS_UPROBES # arch supports live patched user probes
user-ret-profiler: | TODO | HAVE_USER_RETURN_NOTIFIER # arch supports user-space return from system call profiler
virt-cpuacct: | TODO | HAVE_VIRT_CPU_ACCOUNTING || 64BIT # arch supports precise virtual CPU time accounting
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH v2] Documentation/arch: Add kernel feature descriptions and arch support status under Documentation/features/
From: Ingo Molnar @ 2015-05-15 9:37 UTC (permalink / raw)
To: Andrew Morton
Cc: Josh Triplett, Borislav Petkov, Jonathan Corbet, Peter Zijlstra,
Andy Lutomirski, Ingo Molnar, H. Peter Anvin, Thomas Gleixner,
Linus Torvalds, linux-api, linux-kernel, x86, linux-arch
In-Reply-To: <20150514195925.GA27570@gmail.com>
* Ingo Molnar <mingo@kernel.org> wrote:
> > > This directory structure can be used in the future to add other
> > > files - such as porting guides, testing description, etc.
> >
> > I suppose so. Having a great bunch of directories, each
> > containing a single file is a bit odd.
>
> It's a starting point and nicely extensible. I was thinking about
> one more intermediate level:
>
> Documentation/features/locking/lockdep/
> Documentation/features/locking/rwsem-optimized/
> Documentation/features/locking/queued-rwlocks/
> Documentation/features/locking/queued-spinlocks/
> ...
>
> Documentation/features/vm/PG_uncached/
> Documentation/features/vm/pmdp_splitting_flush/
> Documentation/features/vm/pte_special/
> ...
>
> The advantage of this, beyond more structure, would be that I'd
> probably move most of the Documentation/locking/*.txt files into
> Documentation/features/locking/, for example lockdep-design.txt
> would go into Documentation/features/locking/lockdep/.
>
> I'd keep the hierarchy at a predictable depth though, i.e.:
>
> Documentation/features/<subsystem>/<feature_name>/
So I've implemented this, the high level structure now looks like
this:
triton:~/tip/Documentation/features> ls -l
total 48
-rw-rw-r-- 1 mingo mingo 396 May 15 11:26 arch-support.txt
drwxrwxr-x 6 mingo mingo 4096 May 15 11:26 core
drwxrwxr-x 12 mingo mingo 4096 May 15 11:26 debug
drwxrwxr-x 6 mingo mingo 4096 May 15 11:26 io
drwxrwxr-x 3 mingo mingo 4096 May 15 11:26 lib
-rwxrwxr-x 1 mingo mingo 692 May 15 11:31 list-arch.sh
drwxrwxr-x 7 mingo mingo 4096 May 15 11:26 locking
drwxrwxr-x 5 mingo mingo 4096 May 15 11:26 perf
drwxrwxr-x 3 mingo mingo 4096 May 15 11:26 sched
drwxrwxr-x 3 mingo mingo 4096 May 15 11:26 seccomp
drwxrwxr-x 8 mingo mingo 4096 May 15 11:26 time
drwxrwxr-x 10 mingo mingo 4096 May 15 11:26 vm
triton:~/tip/Documentation/features>
triton:~/tip/Documentation/features> ls -l locking/
total 20
drwxrwxr-x 2 mingo mingo 4096 May 15 11:26 cmpxchg-local
drwxrwxr-x 2 mingo mingo 4096 May 15 11:26 lockdep
drwxrwxr-x 2 mingo mingo 4096 May 15 11:26 queued-rwlocks
drwxrwxr-x 2 mingo mingo 4096 May 15 11:26 queued-spinlocks
drwxrwxr-x 2 mingo mingo 4096 May 15 11:26 rwsem-optimized
triton:~/tip/Documentation/features> ls -l vm/
total 32
drwxrwxr-x 2 mingo mingo 4096 May 15 11:26 ELF-ASLR
drwxrwxr-x 2 mingo mingo 4096 May 15 11:26 huge-vmap
drwxrwxr-x 2 mingo mingo 4096 May 15 11:26 ioremap_prot
drwxrwxr-x 2 mingo mingo 4096 May 15 11:26 numa-memblock
drwxrwxr-x 2 mingo mingo 4096 May 15 11:26 PG_uncached
drwxrwxr-x 2 mingo mingo 4096 May 15 11:26 pmdp_splitting_flush
drwxrwxr-x 2 mingo mingo 4096 May 15 11:26 pte_special
drwxrwxr-x 2 mingo mingo 4096 May 15 11:26 THP
And this structure, beyond making it easier to navigate, can be
utilized to improve the visualization output as well:
triton:~/tip/Documentation/features> ./list-arch.sh
#
# Kernel feature support matrix of the 'x86' architecture:
#
core/ BPF-JIT : ok | HAVE_BPF_JIT # arch supports BPF JIT optimizations
core/ generic-idle-thread : ok | GENERIC_SMP_IDLE_THREAD # arch makes use of the generic SMP idle thread facility
core/ jump-labels : ok | HAVE_ARCH_JUMP_LABEL # arch supports live patched, high efficiency branches
core/ tracehook : ok | HAVE_ARCH_TRACEHOOK # arch supports tracehook (ptrace) register handling APIs
debug/ gcov-profile-all : ok | ARCH_HAS_GCOV_PROFILE_ALL # arch supports whole-kernel GCOV code coverage profiling
debug/ KASAN : ok | HAVE_ARCH_KASAN # arch supports the KASAN runtime memory checker
debug/ kgdb : ok | HAVE_ARCH_KGDB # arch supports the kGDB kernel debugger
debug/ kprobes : ok | HAVE_KPROBES # arch supports live patched kernel probe
debug/ kprobes-on-ftrace : ok | HAVE_KPROBES_ON_FTRACE # arch supports combined kprobes and ftrace live patching
debug/ kretprobes : ok | HAVE_KRETPROBES # arch supports kernel function-return probes
debug/ optprobes : ok | HAVE_OPTPROBES # arch supports live patched optprobes
debug/ stackprotector : ok | HAVE_CC_STACKPROTECTOR # arch supports compiler driven stack overflow protection
debug/ uprobes : ok | ARCH_SUPPORTS_UPROBES # arch supports live patched user probes
debug/ user-ret-profiler : ok | HAVE_USER_RETURN_NOTIFIER # arch supports user-space return from system call profiler
io/ dma-api-debug : ok | HAVE_DMA_API_DEBUG # arch supports DMA debug facilities
io/ dma-contiguous : ok | HAVE_DMA_CONTIGUOUS # arch supports the DMA CMA (continuous memory allocator)
io/ dma_map_attrs : ok | HAVE_DMA_ATTRS # arch provides dma_*map*_attrs() APIs
io/ sg-chain : ok | ARCH_HAS_SG_CHAIN # arch supports chained scatter-gather lists
lib/ strncasecmp : TODO | __HAVE_ARCH_STRNCASECMP # arch provides an optimized strncasecmp() function
locking/ cmpxchg-local : ok | HAVE_CMPXCHG_LOCAL # arch supports the this_cpu_cmpxchg() API
locking/ lockdep : ok | LOCKDEP_SUPPORT # arch supports the runtime locking correctness debug facility
locking/ queued-rwlocks : ok | ARCH_USE_QUEUED_RWLOCKS # arch supports queued rwlocks
locking/ queued-spinlocks : ok | ARCH_USE_QUEUED_SPINLOCKS # arch supports queued spinlocks
locking/ rwsem-optimized : ok | Optimized asm/rwsem.h # arch provides optimized rwsem APIs
perf/ kprobes-event : ok | HAVE_REGS_AND_STACK_ACCESS_API # arch supports kprobes with perf events
perf/ perf-regs : ok | HAVE_PERF_REGS # arch supports perf events register access
perf/ perf-stackdump : ok | HAVE_PERF_USER_STACK_DUMP # arch supports perf events stack dumps
sched/ numa-balancing : ok | ARCH_SUPPORTS_NUMA_BALANCING # arch supports NUMA balancing
seccomp/ seccomp-filter : ok | HAVE_ARCH_SECCOMP_FILTER # arch supports seccomp filters
time/ arch-tick-broadcast : TODO | ARCH_HAS_TICK_BROADCAST # arch provides tick_broadcast()
time/ clockevents : ok | GENERIC_CLOCKEVENTS # arch support generic clock events
time/ context-tracking : ok | HAVE_CONTEXT_TRACKING # arch supports context tracking for NO_HZ_FULL
time/ irq-time-acct : ok | HAVE_IRQ_TIME_ACCOUNTING # arch supports precise IRQ time accounting
time/ modern-timekeeping : ok | !ARCH_USES_GETTIMEOFFSET # arch does not use arch_gettimeoffset() anymore
time/ virt-cpuacct : ok | HAVE_VIRT_CPU_ACCOUNTING # arch supports precise virtual CPU time accounting
vm/ ELF-ASLR : ok | ARCH_HAS_ELF_RANDOMIZE # arch randomizes the stack, heap and binary images of ELF binaries
vm/ huge-vmap : ok | HAVE_ARCH_HUGE_VMAP # arch supports the ioremap_pud_enabled() and ioremap_pmd_enabled() VM APIs
vm/ ioremap_prot : ok | HAVE_IOREMAP_PROT # arch has ioremap_prot()
vm/ numa-memblock : ok | HAVE_MEMBLOCK_NODE_MAP # arch supports NUMA aware memblocks
vm/ PG_uncached : ok | ARCH_USES_PG_UNCACHED # arch supports the PG_uncached page flag
vm/ pmdp_splitting_flush : ok | __HAVE_ARCH_PMDP_SPLITTING_FLUSH # arch supports the pmdp_splitting_flush() VM API
vm/ pte_special : ok | __HAVE_ARCH_PTE_SPECIAL # arch supports the pte_special()/pte_mkspecial() VM APIs
vm/ THP : ok | HAVE_ARCH_TRANSPARENT_HUGEPAGE # arch supports transparent hugepages
See the first column, the subsystem prefixes - this organizes the
feature list in a natural way as well, per subsystem.
Seems to work out well.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH v2 1/3] pagemap: add mmap-exclusive bit for marking pages mapped only here
From: Konstantin Khlebnikov @ 2015-05-15 9:39 UTC (permalink / raw)
To: Mark Williamson
Cc: linux-mm-Bw31MaZKKs3YtjvyW6yDsg, Naoya Horiguchi, kernel list,
Andrew Morton, Pavel Emelyanov, Linux API, Andy Lutomirski,
Vlastimil Babka, Pavel Machek, Mark Seaborn, Kirill A. Shutemov,
Linus Torvalds, Daniel James, Finn Grimwood
In-Reply-To: <CAEVpBa+r6AuB7hnCnTm8YKHzaj172q7Wy89yT=P_F6GQG-3-1A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 14.05.2015 21:50, Mark Williamson wrote:
> Hi Konstantin,
>
> On Wed, May 13, 2015 at 11:51 AM, Konstantin Khlebnikov
> <khlebnikov-XoJtRXgx1JseBXzfvpsJ4g@public.gmane.org> wrote:
>> On 12.05.2015 15:05, Mark Williamson wrote:
> <snip>
>>> 1. I was hoping we'd be able to backport a compatible fix to older
>>> kernels that might adopt the pagemap permissions change. Using the V2
>>> format flags rules out doing this for kernels that are too old to have
>>> soft-dirty, I think.
>>>
>>> 2. From our software's PoV, I feel it's worth noting that it doesn't
>>> strictly fix ABI compatibility, though I realise that's probably not
>>> your primary concern here. We'll need to modify our code to write the
>>> clear_refs file but that change is OK for us if it's the preferred
>>> solution.
> <snip>
>> I prefer to backport v2 format (except soft-dirty bit and clear_refs)
>> into older kernels. Page-shift bits are barely used so nobody will see
>> the difference.
>
> My concern was whether a change to format would be acceptable to
> include in the various -stable kernels; they are already including the
> additional protections on pagemap, so we're starting to need our
> fallback mode in distributions. Do you think that such a patch would
> be acceptable there?
>
> (As an application vendor we're likely to be particularly stuck with
> what the commercial distributions decide to ship, which is why I'm
> trying to keep an eye on this)
>
> I appreciate that this is a slightly administrative concern! I
> definitely like the technical approach of this code and it seems to
> work fine for us.
I cannot guarantee that v2 format will be accepted into stable kernels
and into distributives. I'm not the gate keeper.
As a fallback probably you should invent some kind of suid helper
which gives you access to required information without exposing pfn.
For example: it gets pids and memory ranges as arguments and prints
bitmap of CoWed pages into stdout.
--
Konstantin
^ permalink raw reply
* Re: [PATCH v2 1/2] capabilities: Ambient capabilities
From: Lukasz Pawelczyk @ 2015-05-15 11:32 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Serge Hallyn, Andrew Morton, Jarkko Sakkinen, Ted Ts'o,
Andrew G. Morgan, Linux API, Mimi Zohar, Michael Kerrisk,
Austin S Hemmelgarn, linux-security-module, Aaron Jones,
Serge Hallyn, LKML, Markku Savela, Kees Cook, Jonathan Corbet,
Christoph Lameter, Andy Lutomirski
In-Reply-To: <cc4749638a21079cce12f9f30c806170558e56e5.1431671529.git.luto@kernel.org>
On czw, 2015-05-14 at 23:39 -0700, Andy Lutomirski wrote:
> @@ -696,10 +729,18 @@ static inline void cap_emulate_setxuid(struct cred *new, const struct cred *old)
> uid_eq(old->suid, root_uid)) &&
> (!uid_eq(new->uid, root_uid) &&
> !uid_eq(new->euid, root_uid) &&
> - !uid_eq(new->suid, root_uid)) &&
> - !issecure(SECURE_KEEP_CAPS)) {
> - cap_clear(new->cap_permitted);
> - cap_clear(new->cap_effective);
> + !uid_eq(new->suid, root_uid))) {
> + if (!issecure(SECURE_KEEP_CAPS)) {
> + cap_clear(new->cap_permitted);
> + cap_clear(new->cap_effective);
> + }
> +
> + /*
> + * Pre-ambient programs except setresuid to nonroot followed
I think you meant "expect". This typo changes the meaning of the
sentence.
> + * by exec to drop capabilities. We should make sure that
> + * this remains the case.
> + */
> + cap_clear(new->cap_ambient);
> }
--
Lukasz Pawelczyk
^ permalink raw reply
* Re: [PATCH v2 1/2] capabilities: Ambient capabilities
From: Andy Lutomirski @ 2015-05-15 12:03 UTC (permalink / raw)
To: Lukasz Pawelczyk
Cc: Andy Lutomirski, Serge Hallyn, Andrew Morton, Jarkko Sakkinen,
Ted Ts'o, Andrew G. Morgan, Linux API, Mimi Zohar,
Michael Kerrisk, Austin S Hemmelgarn, linux-security-module,
Aaron Jones, Serge Hallyn, LKML, Markku Savela, Kees Cook,
Jonathan Corbet, Christoph Lameter
In-Reply-To: <1431689523.1769.1.camel-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Fri, May 15, 2015 at 4:32 AM, Lukasz Pawelczyk
<l.pawelczyk-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
> On czw, 2015-05-14 at 23:39 -0700, Andy Lutomirski wrote:
>> @@ -696,10 +729,18 @@ static inline void cap_emulate_setxuid(struct cred *new, const struct cred *old)
>> uid_eq(old->suid, root_uid)) &&
>> (!uid_eq(new->uid, root_uid) &&
>> !uid_eq(new->euid, root_uid) &&
>> - !uid_eq(new->suid, root_uid)) &&
>> - !issecure(SECURE_KEEP_CAPS)) {
>> - cap_clear(new->cap_permitted);
>> - cap_clear(new->cap_effective);
>> + !uid_eq(new->suid, root_uid))) {
>> + if (!issecure(SECURE_KEEP_CAPS)) {
>> + cap_clear(new->cap_permitted);
>> + cap_clear(new->cap_effective);
>> + }
>> +
>> + /*
>> + * Pre-ambient programs except setresuid to nonroot followed
>
> I think you meant "expect". This typo changes the meaning of the
> sentence.
Good catch. I'll fix that for v3.
--Andy
^ permalink raw reply
* Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances
From: Steve Grubb @ 2015-05-15 12:38 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Linux API, Linux Containers,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Al Viro,
Paul Moore, linux-audit-H+wXaHxf7aLQT0dZR+AlfA, Eric W. Biederman,
Network Development, Linux FS Devel, Eric Paris, Mimi Zohar
In-Reply-To: <CALCETrWzM4+Vs8OVJWBcWJfbR_DRSb+e7SmUyy6CS4sHQaTkRw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thursday, May 14, 2015 11:23:09 PM Andy Lutomirski wrote:
> On Thu, May 14, 2015 at 7:32 PM, Richard Guy Briggs <rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > On 15/05/14, Paul Moore wrote:
> >> * Look at our existing audit records to determine which records should
> >> have
> >> namespace and container ID tokens added. We may only want to add the
> >> additional fields in the case where the namespace/container ID tokens are
> >> not the init namespace.
> >
> > If we have a record that ties a set of namespace IDs with a container
> > ID, then I expect we only need to list the containerID along with auid
> > and sessionID.
>
> The problem here is that the kernel has no concept of a "container", and I
> don't think it makes any sense to add one just for audit. "Container" is a
> marketing term used by some userspace tools.
No, its a real thing just like a login. Does the kernel have any concept of a
login? Yet it happens. And it causes us to generate events describing who,
where from, role, success, and time of day. :-)
> I can imagine that both audit could benefit from a concept of a
> namespace *path* that understands nesting (e.g. root/2/5/1 or
> something along those lines). Mapping these to "containers" belongs
> in userspace, I think.
I don't doubt that just as user space sequences the actions that are a login.
I just need the kernel to do some book keeping and associate the necessary
attributes in the event record to be able to reconstruct what is actually
happening.
-Steve
^ permalink raw reply
* Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances
From: Steve Grubb @ 2015-05-15 13:17 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Paul Moore, Richard Guy Briggs,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-audit-H+wXaHxf7aLQT0dZR+AlfA, eparis-FjpueFixGhCM4zKIHC2jIg,
arozansk-H+wXaHxf7aLQT0dZR+AlfA, serge-A9i7LUbDfNHQT0dZR+AlfA,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <87bnhmbp8e.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
On Thursday, May 14, 2015 08:31:45 PM Eric W. Biederman wrote:
> Paul Moore <pmoore-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:
> > As Eric, and others, have stated, the container concept is a userspace
> > idea, not a kernel idea; the kernel only knows, and cares about,
> > namespaces. This is unlikely to change.
> >
> > However, as Steve points out, there is precedence for the kernel to record
> > userspace tokens for the sake of audit. Personally I'm not a big fan of
> > this in general, but I do recognize that it does satisfy a legitimate
> > need. Think of things like auid and the sessionid as necessary evils;
> > audit is already chock full of evilness I doubt one more will doom us all
> > to hell.
> >
> > Moving forward, I'd like to see the following:
> >
> > * Create a container ID token (unsigned 32-bit integer?), similar to
> > auid/sessionid, that is set by userspace and carried by the kernel to be
> > used in audit records. I'd like to see some discussion on how we manage
> > this, e.g. how do handle container ID inheritance, how do we handle
> > nested containers (setting the containerid when it is already set), do we
> > care if multiple different containers share the same namespace config,
> > etc.?
> >
> > Can we all live with this? If not, please suggest some alternate ideas;
> > simply shouting "IT'S ALL CRAP!" isn't helpful for anyone ... it may be
> > true, but it doesn't help us solve the problem ;)
>
> Without stopping and defining what someone means by container I think it
> is pretty much nonsense.
Maybe this is what's hanging everyone up? Its easy to get lost when your view
is down at the syscall level and what is happening in the kernel. Starting a
container is akin to the idea of login. Not every call to setresuid is a
login. It could be a setuid program starting or a daemon dropping privileges.
The idea of a container is a higher level concept that starting a name space.
I think comparing a login with a container is a useful analogy because both
are higher level concepts but employ low level ideas. A login is a collection
of chdir, setuid, setgid, allocating a tty, associating the first 3 file
descriptors, setting a process group, and starting a specific executable. All
these low level concepts each by itself is not special.
A container is what we need auditing events around not creation of namespaces.
If we want creation of namespaces, we can audit the clone/unshare/setns
syscalls. The container is when a managing program such as docker, lxc, or
sometimes systemd creates a special operating environment for the express
purpose of running programs disassociated in some way from the parent
namespaces, cgroups, and security assumptions. Its this orchestration, just as
sshd orchestrates a login, that makes it different.
> Should every vsftp connection get a container every? Every chrome tab?
No. Also, note that not every program that grants a user session constitutes a
login.
> At some of the connections per second numbers I have seen we might
> exhaust a 32bit number in an hour or two. Will any of that make sense
> to someone reading the audit logs?
I would agree if we were auditing creation of name spaces. But going back to
the concept of login, these could occur at a high rate. This is a bruteforce
login attack. We put countermeasures in place to prevent it. But it is
possible for the session id to wrap. But in our case, things like lxc or
docker don't start hundreds of these a minute.
> Without considerning that container creation is an unprivileged
> operation I think it is pretty much nonsense. Do I get to say I am any
> container I want? That would seem to invalidate the concept of
> userspace setting a container id.
It would need to be a privileged operation just as setuid is.
> How does any of this interact with setns? AKA entering a container?
We have to audit this. For the moment, auditing the setns syscall may be
enough. I'd have to look at the lifecycle of the application that's doing this
to determine if we need more.
> I will go as far as looking at patches. If someone comes up with
> a mission statement about what they are actually trying to achieve and a
> mechanism that actually achieves that, and that allows for containers to
> nest we can talk about doing something like that.
Auditing wouldn't impose any restrictions on this. We just need a way to
observe actions within and associate them as needed to investigate violations
of security policy.
> But for right now I just hear proposals for things that make no sense
> and can not possibly work. Not least because it will require modifying
> every program that creates a container and who knows how many of them
> there are.
We only care about a couple programs doing the orchestration. They will need
to have the right support added to them. I'm hoping the analogy of a login
helps demonstrate what we are after.
-Steve
^ permalink raw reply
* Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances
From: Andy Lutomirski @ 2015-05-15 13:17 UTC (permalink / raw)
To: Steve Grubb
Cc: Eric W. Biederman, Linux API, Linux Containers,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Paul Moore,
linux-audit-H+wXaHxf7aLQT0dZR+AlfA, Al Viro, Network Development,
Linux FS Devel, Eric Paris, Mimi Zohar
In-Reply-To: <4153072.0EnVzNaVVH@x2>
On May 15, 2015 9:38 PM, "Steve Grubb" <sgrubb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
> On Thursday, May 14, 2015 11:23:09 PM Andy Lutomirski wrote:
> > On Thu, May 14, 2015 at 7:32 PM, Richard Guy Briggs <rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > > On 15/05/14, Paul Moore wrote:
> > >> * Look at our existing audit records to determine which records should
> > >> have
> > >> namespace and container ID tokens added. We may only want to add the
> > >> additional fields in the case where the namespace/container ID tokens are
> > >> not the init namespace.
> > >
> > > If we have a record that ties a set of namespace IDs with a container
> > > ID, then I expect we only need to list the containerID along with auid
> > > and sessionID.
> >
> > The problem here is that the kernel has no concept of a "container", and I
> > don't think it makes any sense to add one just for audit. "Container" is a
> > marketing term used by some userspace tools.
>
> No, its a real thing just like a login. Does the kernel have any concept of a
> login? Yet it happens. And it causes us to generate events describing who,
> where from, role, success, and time of day. :-)
>
I really hope those records come from userspace, not the kernel. I
also wonder what happens when a user logs in and types "sudo agetty
/dev/ttyS0 115200". If a user does that and then someone logs in on
/dev/ttyS0, which login are they?
>
> > I can imagine that both audit could benefit from a concept of a
> > namespace *path* that understands nesting (e.g. root/2/5/1 or
> > something along those lines). Mapping these to "containers" belongs
> > in userspace, I think.
>
> I don't doubt that just as user space sequences the actions that are a login.
> I just need the kernel to do some book keeping and associate the necessary
> attributes in the event record to be able to reconstruct what is actually
> happening.
A precondition for that is having those records have some
correspondence to what is actually happening. Since the kernel has no
concept of a container, and since the same kernel mechanisms could be
used for things that are probably not whatever the Common Criteria
rules think a container is, this could be quite difficult to define in
a meaningful manner.
Hence my suggestion to add only minimal support in the kernel and to
do this in userspace.
--Andy
^ permalink raw reply
* Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances
From: Daniel J Walsh @ 2015-05-15 13:19 UTC (permalink / raw)
To: Richard Guy Briggs, Oren Laadan
Cc: linux-api-u79uwXL29TY76Z2rM5mHXA, Linux Containers, linux-kernel,
linux-audit-H+wXaHxf7aLQT0dZR+AlfA,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
eparis-FjpueFixGhCM4zKIHC2jIg, Eric Biederman
In-Reply-To: <20150515021126.GA965-bcJWsdo4jJjeVoXN4CMphl7TgLCtbB0G@public.gmane.org>
On 05/14/2015 10:11 PM, Richard Guy Briggs wrote:
> On 15/05/14, Oren Laadan wrote:
>> On Thu, May 14, 2015 at 8:48 PM, Richard Guy Briggs <rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>
>>>>>> Recording each instance of a name space is giving me something that I
>>>>>> cannot use to do queries required by the security target. Given these
>>>>>> events, how do I locate a web server event where it accesses a
>>> watched
>>>>>> file? That authentication failed? That an update within the container
>>>>>> failed?
>>>>>>
>>>>>> The requirements are that we have to log the creation, suspension,
>>>>>> migration, and termination of a container. The requirements are not
>>> on
>>>>>> the individual name space.
>>>>> Ok. Do we have a robust definition of a container?
>>>> We call the combination of name spaces, cgroups, and seccomp rules a
>>>> container.
>>> Can you detail what information is required from each?
>>>
>>>>> Where is that definition managed?
>>>> In the thing that invokes a container.
>>> I was looking for a reference to a standards document rather than an
>>> application...
>>>
>>>
>> [focusing on "containers id" - snipped the rest away]
>>
>> I am unfamiliar with the audit subsystem, but work with namespaces in other
>> contexts. Perhaps the term "container" is overloaded here. The definition
>> suggested by Steve in this thread makes sense to me: "a combination of
>> namespaces". I imagine people may want to audit subsets of namespaces.
> I assume it would be a bit more than that, including cgroup and seccomp info.
I don't see why seccomp versus other Security mechanism come into this.
Not really
sure of cgroup. That stuff would all be associated with the process. I
would guess
you could look at the process that modified these for logging, but that
should happen
at the time they get changed, Not recorded for every process.
>> For namespaces, can use a string like "A:B:C:D:E:F" as an identifier for a
>> particular combination, where A-F are respective namespaces identifiers.
>> (Can be taken for example from /proc/PID/ns/{mnt,uts,ipc,user,pid,net}).
>> That will even be grep-able to locate records related to a particular
>> subset
>> of namespaces. So a "container" in the classic meaning would have all A-F
>> unique and different from the init process, but processes separated only by
>> e.g. mnt-ns and net-ns will differ from the init process in A and F.
>>
>> (If a string is a no go, then perhaps combine the IDs in a unique way into a
>> super ID).
> I'd be fine with either, even including the nsfs deviceID.
>
>> Oren.
> - RGB
>
> --
> Richard Guy Briggs <rbriggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
> Remote, Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
>
> --
> Linux-audit mailing list
> Linux-audit-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
> https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: [PATCH v2 1/2] capabilities: Ambient capabilities
From: Christoph Lameter @ 2015-05-15 14:19 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Serge Hallyn, Andrew Morton, Jarkko Sakkinen, Ted Ts'o,
Andrew G. Morgan, Linux API, Mimi Zohar, Michael Kerrisk,
Austin S Hemmelgarn, linux-security-module, Aaron Jones,
Serge Hallyn, LKML, Markku Savela, Kees Cook, Jonathan Corbet,
Andy Lutomirski
In-Reply-To: <cc4749638a21079cce12f9f30c806170558e56e5.1431671529.git.luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On Thu, 14 May 2015, Andy Lutomirski wrote:
> Cc: Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org>
This is partially my code it seems. So there should be a
Signed-off-by: Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org>
here.
Could you provide an example to demonstrate how it is to be used?
Something similar to what I had in my patch?
^ permalink raw reply
* [PATCH v4 01/12] KVM: add comments for kvm_debug_exit_arch struct
From: Alex Bennée @ 2015-05-15 14:27 UTC (permalink / raw)
To: kvm, linux-arm-kernel, kvmarm, christoffer.dall, marc.zyngier,
peter.maydell, agraf, drjones, pbonzini, zhichao.huang
Cc: Jonathan Corbet, Gleb Natapov, jan.kiszka,
open list:DOCUMENTATION, open list, open list:ABI/API, dahi,
r65777, bp
In-Reply-To: <1431700035-23479-1-git-send-email-alex.bennee@linaro.org>
Bring into line with the comments for the other structures and their
KVM_EXIT_* cases. Also update api.txt to reflect use in kvm_run
documentation.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
---
v2
- add comments for other exit types
v3
- s/commentary/comments/
- add rb tags
- update api.txt kvm_run to include KVM_EXIT_DEBUG desc
v4
- sp fixes
- add a-b
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 9fa2bf8..c34c32d 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -3070,11 +3070,13 @@ data_offset describes where the data is located (KVM_EXIT_IO_OUT) or
where kvm expects application code to place the data for the next
KVM_RUN invocation (KVM_EXIT_IO_IN). Data format is a packed array.
+ /* KVM_EXIT_DEBUG */
struct {
struct kvm_debug_exit_arch arch;
} debug;
-Unused.
+If the exit_reason is KVM_EXIT_DEBUG, then a vcpu is processing a debug event
+for which architecture specific information is returned.
/* KVM_EXIT_MMIO */
struct {
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 4b60056..70ac641 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -237,6 +237,7 @@ struct kvm_run {
__u32 count;
__u64 data_offset; /* relative to kvm_run start */
} io;
+ /* KVM_EXIT_DEBUG */
struct {
struct kvm_debug_exit_arch arch;
} debug;
@@ -285,6 +286,7 @@ struct kvm_run {
__u32 data;
__u8 is_write;
} dcr;
+ /* KVM_EXIT_INTERNAL_ERROR */
struct {
__u32 suberror;
/* Available with KVM_CAP_INTERNAL_ERROR_DATA: */
@@ -295,6 +297,7 @@ struct kvm_run {
struct {
__u64 gprs[32];
} osi;
+ /* KVM_EXIT_PAPR_HCALL */
struct {
__u64 nr;
__u64 ret;
--
2.3.5
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related
* [PATCH v4 02/12] KVM: define common KVM_GUESTDBG_USE_SW/HW_BP bits
From: Alex Bennée @ 2015-05-15 14:27 UTC (permalink / raw)
To: kvm, linux-arm-kernel, kvmarm, christoffer.dall, marc.zyngier,
peter.maydell, agraf, drjones, pbonzini, zhichao.huang
Cc: Tony Krowiak, Alexey Kardashevskiy, Benjamin Herrenschmidt,
Heiko Carstens, Paul Mackerras, H. Peter Anvin, open list:S390,
Michael Mueller, Nadav Amit, Michael Ellerman,
maintainer:X86 ARCHITECTURE..., Christian Borntraeger,
Ingo Molnar, Jason J. Herne, jan.kiszka, bp, Gleb Natapov, r65777,
Cornelia Huck, Thomas Gleixner, Eric Farman, open list:ABI/API,
open list
In-Reply-To: <1431700035-23479-1-git-send-email-alex.bennee@linaro.org>
Currently x86, powerpc and soon arm64 use the same two architecture
specific bits for guest debug support for software and hardware
breakpoints. This makes the shared values explicit.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Andrew Jones <drjones@redhat.com>
-
v4
- claim more bits for the common functionality
v5
- don't use __ mechanism to move values common
diff --git a/arch/powerpc/include/uapi/asm/kvm.h b/arch/powerpc/include/uapi/asm/kvm.h
index ab4d473..6ea24a5 100644
--- a/arch/powerpc/include/uapi/asm/kvm.h
+++ b/arch/powerpc/include/uapi/asm/kvm.h
@@ -307,11 +307,9 @@ struct kvm_guest_debug_arch {
/* Debug related defines */
/*
* kvm_guest_debug->control is a 32 bit field. The lower 16 bits are generic
- * and upper 16 bits are architecture specific. Architecture specific defines
+ * and upper 14 bits are architecture specific. Architecture specific defines
* that ioctl is for setting hardware breakpoint or software breakpoint.
*/
-#define KVM_GUESTDBG_USE_SW_BP 0x00010000
-#define KVM_GUESTDBG_USE_HW_BP 0x00020000
/* definition of registers in kvm_run */
struct kvm_sync_regs {
diff --git a/arch/s390/include/uapi/asm/kvm.h b/arch/s390/include/uapi/asm/kvm.h
index ef1a5fc..aca4f86 100644
--- a/arch/s390/include/uapi/asm/kvm.h
+++ b/arch/s390/include/uapi/asm/kvm.h
@@ -114,8 +114,6 @@ struct kvm_fpu {
__u64 fprs[16];
};
-#define KVM_GUESTDBG_USE_HW_BP 0x00010000
-
#define KVM_HW_BP 1
#define KVM_HW_WP_WRITE 2
#define KVM_SINGLESTEP 4
diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h
index d7dcef5..ca51d4c 100644
--- a/arch/x86/include/uapi/asm/kvm.h
+++ b/arch/x86/include/uapi/asm/kvm.h
@@ -250,8 +250,6 @@ struct kvm_debug_exit_arch {
__u64 dr7;
};
-#define KVM_GUESTDBG_USE_SW_BP 0x00010000
-#define KVM_GUESTDBG_USE_HW_BP 0x00020000
#define KVM_GUESTDBG_INJECT_DB 0x00040000
#define KVM_GUESTDBG_INJECT_BP 0x00080000
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 70ac641..7c5dd11 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -570,8 +570,10 @@ struct kvm_s390_irq_state {
/* for KVM_SET_GUEST_DEBUG */
-#define KVM_GUESTDBG_ENABLE 0x00000001
-#define KVM_GUESTDBG_SINGLESTEP 0x00000002
+#define KVM_GUESTDBG_ENABLE (1 << 0)
+#define KVM_GUESTDBG_SINGLESTEP (1 << 1)
+#define KVM_GUESTDBG_USE_SW_BP (1 << 16)
+#define KVM_GUESTDBG_USE_HW_BP (1 << 17)
struct kvm_guest_debug {
__u32 control;
--
2.3.5
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related
* [PATCH v4 10/12] KVM: arm64: guest debug, HW assisted debug support
From: Alex Bennée @ 2015-05-15 14:27 UTC (permalink / raw)
To: kvm, linux-arm-kernel, kvmarm, christoffer.dall, marc.zyngier,
peter.maydell, agraf, drjones, pbonzini, zhichao.huang
Cc: Lorenzo Pieralisi, Russell King, Jonathan Corbet, Gleb Natapov,
jan.kiszka, open list:DOCUMENTATION, Will Deacon, open list,
open list:ABI/API, dahi, Peter Zijlstra, Catalin Marinas, r65777,
bp, Ingo Molnar
In-Reply-To: <1431700035-23479-1-git-send-email-alex.bennee@linaro.org>
This adds support for userspace to control the HW debug registers for
guest debug. In the debug ioctl we copy the IMPDEF defined number of
registers into a new register set called host_debug_state. There is now
a new vcpu parameter called debug_ptr which selects which register set
is to copied into the real registers when world switch occurs.
I've moved some helper functions into the hw_breakpoint.h header for
re-use.
As with single step we need to tweak the guest registers to enable the
exceptions so we need to save and restore those bits.
Two new capabilities have been added to the KVM_EXTENSION ioctl to allow
userspace to query the number of hardware break and watch points
available on the host hardware.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
v2
- switched to C setup
- replace host debug registers directly into context
- minor tweak to api docs
- setup right register for debug
- add FAR_EL2 to debug exit structure
- add support for trapping debug register access
v3
- remove stray trace statement
- fix spacing around operators (various)
- clean-up usage of trap_debug
- introduce debug_ptr, replace excessive memcpy stuff
- don't use memcpy in ioctl, just assign
- update cap ioctl documentation
- reword a number comments
- rename host_debug_state->external_debug_state
v4
- use the new u32/u64 split debug_ptr approach
- fix some wording/comments
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 33c8143..ada57df 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2668,7 +2668,7 @@ The top 16 bits of the control field are architecture specific control
flags which can include the following:
- KVM_GUESTDBG_USE_SW_BP: using software breakpoints [x86, arm64]
- - KVM_GUESTDBG_USE_HW_BP: using hardware breakpoints [x86, s390]
+ - KVM_GUESTDBG_USE_HW_BP: using hardware breakpoints [x86, s390, arm64]
- KVM_GUESTDBG_INJECT_DB: inject DB type exception [x86]
- KVM_GUESTDBG_INJECT_BP: inject BP type exception [x86]
- KVM_GUESTDBG_EXIT_PENDING: trigger an immediate guest exit [s390]
@@ -2683,6 +2683,11 @@ updated to the correct (supplied) values.
The second part of the structure is architecture specific and
typically contains a set of debug registers.
+For arm64 the number of debug registers is implementation defined and
+can be determined by querying the KVM_CAP_GUEST_DEBUG_HW_BPS and
+KVM_CAP_GUEST_DEBUG_HW_WPS capabilities which return a positive number
+indicating the number of supported registers.
+
When debug events exit the main run loop with the reason
KVM_EXIT_DEBUG with the kvm_debug_exit_arch part of the kvm_run
structure containing architecture specific debug information.
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 0d17c7b..6df47c1 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -307,6 +307,7 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
#define KVM_GUESTDBG_VALID_MASK (KVM_GUESTDBG_ENABLE | \
KVM_GUESTDBG_USE_SW_BP | \
+ KVM_GUESTDBG_USE_HW_BP | \
KVM_GUESTDBG_SINGLESTEP)
/**
@@ -327,6 +328,12 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
if (dbg->control & KVM_GUESTDBG_ENABLE) {
vcpu->guest_debug = dbg->control;
+
+ /* Hardware assisted Break and Watch points */
+ if (vcpu->guest_debug & KVM_GUESTDBG_USE_HW_BP) {
+ vcpu->arch.external_debug_state = dbg->arch;
+ }
+
} else {
/* If not enabled clear all flags */
vcpu->guest_debug = 0;
diff --git a/arch/arm64/include/asm/hw_breakpoint.h b/arch/arm64/include/asm/hw_breakpoint.h
index 52b484b..c450552 100644
--- a/arch/arm64/include/asm/hw_breakpoint.h
+++ b/arch/arm64/include/asm/hw_breakpoint.h
@@ -130,6 +130,18 @@ static inline void ptrace_hw_copy_thread(struct task_struct *task)
}
#endif
+/* Determine number of BRP registers available. */
+static inline int get_num_brps(void)
+{
+ return ((read_cpuid(ID_AA64DFR0_EL1) >> 12) & 0xf) + 1;
+}
+
+/* Determine number of WRP registers available. */
+static inline int get_num_wrps(void)
+{
+ return ((read_cpuid(ID_AA64DFR0_EL1) >> 20) & 0xf) + 1;
+}
+
extern struct pmu perf_ops_bp;
#endif /* __KERNEL__ */
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index ad792cb..ba3a1c5 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -113,12 +113,13 @@ struct kvm_vcpu_arch {
/*
* For debugging the guest we need to keep a set of debug
- * registers which can override the guests own debug state
+ * registers which can override the guest's own debug state
* while being used. These are set via the KVM_SET_GUEST_DEBUG
* ioctl.
*/
struct kvm_guest_debug_arch *debug_ptr;
struct kvm_guest_debug_arch vcpu_debug_state;
+ struct kvm_guest_debug_arch external_debug_state;
/* Pointer to host CPU context */
kvm_cpu_context_t *host_cpu_context;
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 8796610..144edee 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -121,7 +121,7 @@ struct kvm_guest_debug_arch {
struct kvm_debug_exit_arch {
__u32 hsr;
- __u64 far;
+ __u64 far; /* used for watchpoints */
};
struct kvm_sync_regs {
diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
index e7d934d..3a41bbf 100644
--- a/arch/arm64/kernel/hw_breakpoint.c
+++ b/arch/arm64/kernel/hw_breakpoint.c
@@ -49,18 +49,6 @@ static DEFINE_PER_CPU(int, stepping_kernel_bp);
static int core_num_brps;
static int core_num_wrps;
-/* Determine number of BRP registers available. */
-static int get_num_brps(void)
-{
- return ((read_cpuid(ID_AA64DFR0_EL1) >> 12) & 0xf) + 1;
-}
-
-/* Determine number of WRP registers available. */
-static int get_num_wrps(void)
-{
- return ((read_cpuid(ID_AA64DFR0_EL1) >> 20) & 0xf) + 1;
-}
-
int hw_breakpoint_slots(int type)
{
/*
diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
index f630f4d..7cfcb53 100644
--- a/arch/arm64/kvm/debug.c
+++ b/arch/arm64/kvm/debug.c
@@ -103,10 +103,6 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu)
MDCR_EL2_TDRA |
MDCR_EL2_TDOSA);
- /* Trap on access to debug registers? */
- if (trap_debug)
- vcpu->arch.mdcr_el2 |= MDCR_EL2_TDA;
-
/* Is Guest debugging in effect? */
if (vcpu->guest_debug) {
vcpu->arch.mdcr_el2 |= MDCR_EL2_TDE;
@@ -129,11 +125,43 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu)
*vcpu_cpsr(vcpu) &= ~DBG_SPSR_SS;
vcpu_sys_reg(vcpu, MDSCR_EL1) &= ~DBG_MDSCR_SS;
}
+
+ /*
+ * HW Break/Watch points
+ *
+ * We simply switch the debug_ptr to point to our new
+ * external_debug_state which has been populated by the
+ * debug ioctl. The existing KVM_ARM64_DEBUG_DIRTY
+ * mechanism ensures the registers are updated on the
+ * world switch.
+ */
+ if (vcpu->guest_debug & KVM_GUESTDBG_USE_HW_BP) {
+ /* Enable debug exceptions for all EL0/EL1 */
+ vcpu_sys_reg(vcpu, MDSCR_EL1) |=
+ (DBG_MDSCR_KDE | DBG_MDSCR_MDE);
+
+ vcpu->arch.debug_ptr = &vcpu->arch.external_debug_state;
+ vcpu->arch.debug_flags |= KVM_ARM64_DEBUG_DIRTY;
+ trap_debug = true;
+ }
}
+
+ /* Trap debug register access */
+ if (trap_debug)
+ vcpu->arch.mdcr_el2 |= MDCR_EL2_TDA;
}
void kvm_arm_clear_debug(struct kvm_vcpu *vcpu)
{
- if (vcpu->guest_debug)
+ if (vcpu->guest_debug) {
restore_guest_debug_regs(vcpu);
+
+ /*
+ * If we were using HW debug we need to restore the
+ * debug_ptr to the guest debug state.
+ */
+ if (vcpu->guest_debug & KVM_GUESTDBG_USE_HW_BP)
+ vcpu->arch.debug_ptr = &vcpu->arch.vcpu_debug_state;
+
+ }
}
diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
index e9de13e..68a0759 100644
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@ -103,7 +103,11 @@ static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu, struct kvm_run *run)
run->debug.arch.hsr = hsr;
switch (hsr >> ESR_ELx_EC_SHIFT) {
+ case ESR_ELx_EC_WATCHPT_LOW:
+ run->debug.arch.far = vcpu->arch.fault.far_el2;
+ /* fall through */
case ESR_ELx_EC_SOFTSTP_LOW:
+ case ESR_ELx_EC_BREAKPT_LOW:
case ESR_ELx_EC_BKPT32:
case ESR_ELx_EC_BRK64:
break;
@@ -132,6 +136,8 @@ static exit_handle_fn arm_exit_handlers[] = {
[ESR_ELx_EC_IABT_LOW] = kvm_handle_guest_abort,
[ESR_ELx_EC_DABT_LOW] = kvm_handle_guest_abort,
[ESR_ELx_EC_SOFTSTP_LOW]= kvm_handle_guest_debug,
+ [ESR_ELx_EC_WATCHPT_LOW]= kvm_handle_guest_debug,
+ [ESR_ELx_EC_BREAKPT_LOW]= kvm_handle_guest_debug,
[ESR_ELx_EC_BKPT32] = kvm_handle_guest_debug,
[ESR_ELx_EC_BRK64] = kvm_handle_guest_debug,
};
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 0b43265..21d5a62 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -56,6 +56,12 @@ static bool cpu_has_32bit_el1(void)
return !!(pfr0 & 0x20);
}
+/**
+ * kvm_arch_dev_ioctl_check_extension
+ *
+ * We currently assume that the number of HW registers is uniform
+ * across all CPUs (see cpuinfo_sanity_check).
+ */
int kvm_arch_dev_ioctl_check_extension(long ext)
{
int r;
@@ -64,6 +70,12 @@ int kvm_arch_dev_ioctl_check_extension(long ext)
case KVM_CAP_ARM_EL1_32BIT:
r = cpu_has_32bit_el1();
break;
+ case KVM_CAP_GUEST_DEBUG_HW_BPS:
+ r = get_num_brps();
+ break;
+ case KVM_CAP_GUEST_DEBUG_HW_WPS:
+ r = get_num_wrps();
+ break;
default:
r = 0;
}
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 7c5dd11..d3e661d 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -819,6 +819,8 @@ struct kvm_ppc_smmu_info {
#define KVM_CAP_S390_INJECT_IRQ 113
#define KVM_CAP_S390_IRQ_STATE 114
#define KVM_CAP_PPC_HWRNG 115
+#define KVM_CAP_GUEST_DEBUG_HW_BPS 116
+#define KVM_CAP_GUEST_DEBUG_HW_WPS 117
#ifdef KVM_CAP_IRQ_ROUTING
--
2.3.5
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply related
* Re: [PATCH v2 1/2] capabilities: Ambient capabilities
From: Christoph Lameter @ 2015-05-15 14:31 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Serge Hallyn, Andrew Morton, Jarkko Sakkinen, Ted Ts'o,
Andrew G. Morgan, Linux API, Mimi Zohar, Michael Kerrisk,
Austin S Hemmelgarn, linux-security-module, Aaron Jones,
Serge Hallyn, LKML, Markku Savela, Kees Cook, Jonathan Corbet,
Andy Lutomirski
In-Reply-To: <cc4749638a21079cce12f9f30c806170558e56e5.1431671529.git.luto@kernel.org>
It would be best to start a complete new thread about this. You
replied to earlier posts about ambient capabilities and
people may not see it as a new release.
> pA obeys the invariant that no bit can ever be set in pA if it is
> not set in both pP and pI. Dropping a bit from pP or pI drops that
> bit from pA. This ensures that existing programs that try to drop
> capabilities still do so, with a complication. Because capability
Ok that is a good improvement.
> inheritance is so broken, setting KEEPCAPS, using setresuid to
> switch to nonroot uids, or calling execve effectively drops
> capabilities. Therefore, setresuid from root to nonroot
> conditionally clears pA unless SECBIT_NO_SETUID_FIXUP is set.
> Processes that don't like this can re-add bits to pA afterwards.
>
> The capability evolution rules are changed:
>
> pA' = (file caps or setuid or setgid ? 0 : pA)
> pP' = (X & fP) | (pI & fI) | pA'
> pI' = pI
> pE' = (fE ? pP' : pA')
Isnt this equal to
pE' = (fE & pP') | pA'
which does not require conditionals and is symmetric to how pP' is
calculated. Your formula seems to indicate that pA' bits are not set if
fE is set. However they are already set unconditionally in pP' regardless.
This makes it more explicit I think. And I thought we are dealing with
bitmask arithmetic here?
> If you are nonroot but you have a capability, you can add it to pA.
> If you do so, your children get that capability in pA, pP, and pE.
> For example, you can set pA = CAP_NET_BIND_SERVICE, and your
> children can automatically bind low-numbered ports. Hallelujah!
I love this solution.
> [2] The libcap capability mask parsers and formatters are
> dangerously misleading and the documentation is flat-out wrong. fE
> is *not* a mask; it's a single bit. This has probably confused
> every single person who has tried to use file capabilities.
Hmmm... yes lets clean that up as well. Then your formula makes sense.
^ permalink raw reply
* Re: [PATCH V6 05/10] audit: log creation and deletion of namespace instances
From: Eric W. Biederman @ 2015-05-15 14:51 UTC (permalink / raw)
To: Steve Grubb
Cc: linux-api-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn, Paul Moore,
linux-audit-H+wXaHxf7aLQT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
eparis-FjpueFixGhCM4zKIHC2jIg,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
In-Reply-To: <2519397.QJshNan19e@x2>
Steve Grubb <sgrubb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:
> On Thursday, May 14, 2015 08:31:45 PM Eric W. Biederman wrote:
>> Paul Moore <pmoore-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:
>> > As Eric, and others, have stated, the container concept is a userspace
>> > idea, not a kernel idea; the kernel only knows, and cares about,
>> > namespaces. This is unlikely to change.
>> >
>> > However, as Steve points out, there is precedence for the kernel to record
>> > userspace tokens for the sake of audit. Personally I'm not a big fan of
>> > this in general, but I do recognize that it does satisfy a legitimate
>> > need. Think of things like auid and the sessionid as necessary evils;
>> > audit is already chock full of evilness I doubt one more will doom us all
>> > to hell.
>> >
>> > Moving forward, I'd like to see the following:
>> >
>> > * Create a container ID token (unsigned 32-bit integer?), similar to
>> > auid/sessionid, that is set by userspace and carried by the kernel to be
>> > used in audit records. I'd like to see some discussion on how we manage
>> > this, e.g. how do handle container ID inheritance, how do we handle
>> > nested containers (setting the containerid when it is already set), do we
>> > care if multiple different containers share the same namespace config,
>> > etc.?
>> >
>> > Can we all live with this? If not, please suggest some alternate ideas;
>> > simply shouting "IT'S ALL CRAP!" isn't helpful for anyone ... it may be
>> > true, but it doesn't help us solve the problem ;)
>>
>> Without stopping and defining what someone means by container I think it
>> is pretty much nonsense.
>
> Maybe this is what's hanging everyone up? Its easy to get lost when your view
> is down at the syscall level and what is happening in the kernel. Starting a
> container is akin to the idea of login. Not every call to setresuid is a
> login. It could be a setuid program starting or a daemon dropping privileges.
> The idea of a container is a higher level concept that starting a name space.
> I think comparing a login with a container is a useful analogy because both
> are higher level concepts but employ low level ideas. A login is a collection
> of chdir, setuid, setgid, allocating a tty, associating the first 3 file
> descriptors, setting a process group, and starting a specific executable. All
> these low level concepts each by itself is not special.
Except login and setresuid are privileged operation.
CREATING A CONTAINER IS NOT A PRIVILGED OPERATION.
Your analagy fails rather badly with respect to that fact.
> A container is what we need auditing events around not creation of namespaces.
> If we want creation of namespaces, we can audit the clone/unshare/setns
> syscalls. The container is when a managing program such as docker, lxc, or
> sometimes systemd creates a special operating environment for the express
> purpose of running programs disassociated in some way from the parent
> namespaces, cgroups, and security assumptions. Its this orchestration, just as
> sshd orchestrates a login, that makes it different.
What do you define as a container? From what I can tell we share
a similiar understanding of the term, and running lxc is not a
privileged operation. Running sandstorm.io is not a privileged
operation.
>> Should every vsftp connection get a container every? Every chrome tab?
>
> No. Also, note that not every program that grants a user session constitutes a
> login.
>> At some of the connections per second numbers I have seen we might
>> exhaust a 32bit number in an hour or two. Will any of that make sense
>> to someone reading the audit logs?
>
> I would agree if we were auditing creation of name spaces. But going back to
> the concept of login, these could occur at a high rate. This is a bruteforce
> login attack. We put countermeasures in place to prevent it. But it is
> possible for the session id to wrap. But in our case, things like lxc or
> docker don't start hundreds of these a minute.
Except there are reasonable situtations where container creation does
happen at fast rates. Outside of a container per network connection
(which is likely to happen at some point) I have seen builds fire up
more containers than I can count as part of automated testing.
>> Without considerning that container creation is an unprivileged
>> operation I think it is pretty much nonsense. Do I get to say I am any
>> container I want? That would seem to invalidate the concept of
>> userspace setting a container id.
>
> It would need to be a privileged operation just as setuid is.
CONTAINER CREATION IS NOT A PRIVILEGED OPERATION.
That is today. That is talking about lxc.
CONTAINER CREATION IS NOT A PRIVILEGED OPERATION.
And ultimately we don't want it to be, as if you can safely create a
container without privilege your system is safer.
>> How does any of this interact with setns? AKA entering a container?
>
> We have to audit this. For the moment, auditing the setns syscall may be
> enough. I'd have to look at the lifecycle of the application that's doing this
> to determine if we need more.
Frequently it will be sysadmins for some arbitrary reason calling
nsenter or a similar program that is more aware of their favorite
container flavor.
>> I will go as far as looking at patches. If someone comes up with
>> a mission statement about what they are actually trying to achieve and a
>> mechanism that actually achieves that, and that allows for containers to
>> nest we can talk about doing something like that.
>
> Auditing wouldn't impose any restrictions on this. We just need a way to
> observe actions within and associate them as needed to investigate violations
> of security policy.
*Rolls eyes* But the rest of the container tool kit in the kernel will
impose limitations on those identifiers.
>> But for right now I just hear proposals for things that make no sense
>> and can not possibly work. Not least because it will require modifying
>> every program that creates a container and who knows how many of them
>> there are.
>
> We only care about a couple programs doing the orchestration. They will need
> to have the right support added to them. I'm hoping the analogy of a login
> helps demonstrate what we are after.
All I see is that (a) you have not defined what you see a container as
(b) you have failed to acknowledge I can create a container without
privilege (which breaks your analogy with login).
But I think I am with Andy. If you only care about privileged events
and privileged containers, it is unlikely you need to do anything in the
kernel and you can perform whatever logging you see fit in your
privileged userspace applications.
Of course in the log run I don't see what good that will do you as I
expect increasingly there will not need to be any special permissions to
create containers.
Eric
^ permalink raw reply
* Re: [PATCH 0/6] support "dataplane" mode for nohz_full
From: Chris Metcalf @ 2015-05-15 15:10 UTC (permalink / raw)
To: Peter Zijlstra, Steven Rostedt
Cc: Ingo Molnar, Andrew Morton, Gilad Ben Yossef, Ingo Molnar,
Rik van Riel, Tejun Heo, Frederic Weisbecker, Thomas Gleixner,
Paul E. McKenney, Christoph Lameter, Srivatsa S. Bhat, linux-doc,
linux-api, linux-kernel
In-Reply-To: <20150512104622.GK21418@twins.programming.kicks-ass.net>
On 05/12/2015 06:46 AM, Peter Zijlstra wrote:
> On Mon, May 11, 2015 at 08:57:59AM -0400, Steven Rostedt wrote:
>> Please lets get NO_HZ_FULL up to par. That should be the main focus.
>>
> ACK, much of this dataplane stuff is (useful) hacks working around the
> fact that nohz_full just isn't complete.
There are enough disjoint threads on this topic that I want
to just touch base here and see if you have been convinced
on other threads that there is stuff beyond the hacks here:
in particular
1. The basic "dataplane" mode to arrange to do extra work on
return to kernel space that normally isn't warranted, to avoid
future IPIs, and additionally to wait in the kernel until any timer
interrupts required by the kernel invocation itself are done; and
2. The "strict" mode to allow a task to tell the kernel it isn't
planning on making any more such calls, and have the kernel
help diagnose any resulting application bugs.
--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com
^ permalink raw reply
* Re: [PATCH v4 10/12] KVM: arm64: guest debug, HW assisted debug support
From: Mark Rutland @ 2015-05-15 15:23 UTC (permalink / raw)
To: Alex Bennée
Cc: kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg@public.gmane.org,
christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
Marc Zyngier,
peter.maydell-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
agraf-l3A5Bk7waGM@public.gmane.org,
drjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
pbonzini-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
zhichao.huang-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
Lorenzo Pieralisi, Russell King, Jonathan Corbet, Gleb Natapov,
jan.kiszka-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org,
open list:DOCUMENTATION, Will Deacon, open list
In-Reply-To: <1431700035-23479-11-git-send-email-alex.bennee-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Hi Alex,
On Fri, May 15, 2015 at 03:27:13PM +0100, Alex Bennée wrote:
> This adds support for userspace to control the HW debug registers for
> guest debug. In the debug ioctl we copy the IMPDEF defined number of
> registers into a new register set called host_debug_state. There is now
> a new vcpu parameter called debug_ptr which selects which register set
> is to copied into the real registers when world switch occurs.
>
> I've moved some helper functions into the hw_breakpoint.h header for
> re-use.
>
> As with single step we need to tweak the guest registers to enable the
> exceptions so we need to save and restore those bits.
>
> Two new capabilities have been added to the KVM_EXTENSION ioctl to allow
> userspace to query the number of hardware break and watch points
> available on the host hardware.
There's the unfortunate possibility that these could vary across cores
in a big.LITTLE system (though we haven't seen that thus far). The
kernel sanity checks should currently explode if such a case is
encountered, but I don't know what we'd do were that to happen.
This gets more fun when you consider the context-aware breakpoints are
the highest numbered. So the set of (context-aware) breakpoints might
not intersect across all CPUs.
I'm not sure what the best thing to do is w.r.t. exposing that to
userspace.
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH 0/3] Allow user to request memory to be locked on page fault
From: Eric B Munson @ 2015-05-15 15:35 UTC (permalink / raw)
To: Michal Hocko
Cc: Andrew Morton, Shuah Khan, linux-alpha, linux-kernel, linux-mips,
linux-parisc, linuxppc-dev, sparclinux, linux-xtensa, linux-mm,
linux-arch, linux-api
In-Reply-To: <20150514080812.GC6433@dhcp22.suse.cz>
[-- Attachment #1: Type: text/plain, Size: 4446 bytes --]
On Thu, 14 May 2015, Michal Hocko wrote:
> On Wed 13-05-15 11:00:36, Eric B Munson wrote:
> > On Mon, 11 May 2015, Eric B Munson wrote:
> >
> > > On Fri, 08 May 2015, Andrew Morton wrote:
> > >
> > > > On Fri, 8 May 2015 15:33:43 -0400 Eric B Munson <emunson@akamai.com> wrote:
> > > >
> > > > > mlock() allows a user to control page out of program memory, but this
> > > > > comes at the cost of faulting in the entire mapping when it is
> > > > > allocated. For large mappings where the entire area is not necessary
> > > > > this is not ideal.
> > > > >
> > > > > This series introduces new flags for mmap() and mlockall() that allow a
> > > > > user to specify that the covered are should not be paged out, but only
> > > > > after the memory has been used the first time.
> > > >
> > > > Please tell us much much more about the value of these changes: the use
> > > > cases, the behavioural improvements and performance results which the
> > > > patchset brings to those use cases, etc.
> > > >
> > >
> > > To illustrate the proposed use case I wrote a quick program that mmaps
> > > a 5GB file which is filled with random data and accesses 150,000 pages
> > > from that mapping. Setup and processing were timed separately to
> > > illustrate the differences between the three tested approaches. the
> > > setup portion is simply the call to mmap, the processing is the
> > > accessing of the various locations in that mapping. The following
> > > values are in milliseconds and are the averages of 20 runs each with a
> > > call to echo 3 > /proc/sys/vm/drop_caches between each run.
> > >
> > > The first mapping was made with MAP_PRIVATE | MAP_LOCKED as a baseline:
> > > Startup average: 9476.506
> > > Processing average: 3.573
> > >
> > > The second mapping was simply MAP_PRIVATE but each page was passed to
> > > mlock() before being read:
> > > Startup average: 0.051
> > > Processing average: 721.859
> > >
> > > The final mapping was MAP_PRIVATE | MAP_LOCKONFAULT:
> > > Startup average: 0.084
> > > Processing average: 42.125
> > >
> >
> > Michal's suggestion of changing protections and locking in a signal
> > handler was better than the locking as needed, but still significantly
> > more work required than the LOCKONFAULT case.
> >
> > Startup average: 0.047
> > Processing average: 86.431
>
> Have you played with batching? Has it helped? Anyway it is to be
> expected that the overhead will be higher than a single mmap call. The
> question is whether you can live with it because adding a new semantic
> to mlock sounds trickier and MAP_LOCKED is tricky enough already...
>
I reworked the experiment to better cover the batching solution. The
same 5GB data file is used, however instead of 150,000 accesses at
regular intervals, the test program now does 15,000,000 accesses to
random pages in the mapping. The rest of the setup remains the same.
mmap with MAP_LOCKED:
Setup avg: 11821.193
Processing avg: 3404.286
mmap with mlock() before each access:
Setup avg: 0.054
Processing avg: 34263.201
mmap with PROT_NONE and signal handler and batch size of 1 page:
With the default value in max_map_count, this gets ENOMEM as I attempt
to change the permissions, after upping the sysctl significantly I get:
Setup avg: 0.050
Processing avg: 67690.625
mmap with PROT_NONE and signal handler and batch size of 8 pages:
Setup avg: 0.098
Processing avg: 37344.197
mmap with PROT_NONE and signal handler and batch size of 16 pages:
Setup avg: 0.0548
Processing avg: 29295.669
mmap with MAP_LOCKONFAULT:
Setup avg: 0.073
Processing avg: 18392.136
The signal handler in the batch cases faulted in memory in two steps to
avoid having to know the start and end of the faulting mapping. The
first step covers the page that caused the fault as we know that it will
be possible to lock. The second step speculatively tries to mlock and
mprotect the batch size - 1 pages that follow. There may be a clever
way to avoid this without having the program track each mapping to be
covered by this handeler in a globally accessible structure, but I could
not find it.
These results show that if the developer knows that a majority of the
mapping will be used, it is better to try and fault it in at once,
otherwise MAP_LOCKONFAULT is significantly faster.
Eric
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v4 02/12] KVM: define common KVM_GUESTDBG_USE_SW/HW_BP bits
From: Christian Borntraeger @ 2015-05-15 15:42 UTC (permalink / raw)
To: Alex Bennée, kvm, linux-arm-kernel, kvmarm, christoffer.dall,
marc.zyngier, peter.maydell, agraf, drjones, pbonzini,
zhichao.huang
Cc: Tony Krowiak, Alexey Kardashevskiy, Benjamin Herrenschmidt,
Heiko Carstens, Paul Mackerras, H. Peter Anvin, S390,
Michael Mueller, Nadav Amit, Michael Ellerman,
maintainer:X86 ARCHITECTURE..., supporter, Ingo Molnar,
Jason J. Herne, jan.kiszka, bp, Gleb Natapov, r65777,
Cornelia Huck, Thomas Gleixner, Eric Farman, list, ABI/API,
open list
In-Reply-To: <1431700035-23479-3-git-send-email-alex.bennee@linaro.org>
Am 15.05.2015 um 16:27 schrieb Alex Bennée:
> +++ b/arch/s390/include/uapi/asm/kvm.h
> @@ -114,8 +114,6 @@ struct kvm_fpu {
> __u64 fprs[16];
> };
>
> -#define KVM_GUESTDBG_USE_HW_BP 0x00010000
[...]
> +++ b/include/uapi/linux/kvm.h
[...]
> +#define KVM_GUESTDBG_USE_SW_BP (1 << 16)
> +#define KVM_GUESTDBG_USE_HW_BP (1 << 17)
This is an ABI break for s390, no?
David, do you remember why we do not use KVM_GUESTDBG_USE_SW_BP?
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply
* Re: [PATCH v4 02/12] KVM: define common KVM_GUESTDBG_USE_SW/HW_BP bits
From: Christian Borntraeger @ 2015-05-15 15:58 UTC (permalink / raw)
To: Alex Bennée, kvm, linux-arm-kernel, kvmarm, christoffer.dall,
marc.zyngier, peter.maydell, agraf, drjones, pbonzini,
zhichao.huang
Cc: Tony Krowiak, Alexey Kardashevskiy, Benjamin Herrenschmidt,
Heiko Carstens, Paul Mackerras, H. Peter Anvin, linux-s390,
Michael Mueller, Nadav Amit, Michael Ellerman, x86, Ingo Molnar,
Jason J. Herne, jan.kiszka, bp, Gleb Natapov, r65777,
Cornelia Huck, Thomas Gleixner, Eric Farman, linux-api, open list,
Dominik Dingel, dahi, Martin Schwidefsky
In-Reply-To: <1431700035-23479-3-git-send-email-alex.bennee@linaro.org>
Am 15.05.2015 um 16:27 schrieb Alex Bennée:
> index ef1a5fc..aca4f86 100644
> --- a/arch/s390/include/uapi/asm/kvm.h
> +++ b/arch/s390/include/uapi/asm/kvm.h
> @@ -114,8 +114,6 @@ struct kvm_fpu {
> __u64 fprs[16];
> };
>
> -#define KVM_GUESTDBG_USE_HW_BP 0x00010000
> -
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 70ac641..7c5dd11 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
[...]
> +#define KVM_GUESTDBG_USE_SW_BP (1 << 16)
> +#define KVM_GUESTDBG_USE_HW_BP (1 << 17)
This is a abi break for s390, no?
David do you remember why we did not use SW_BP?
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ 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