Andy Lutomirski | 22 Jul 03:49 2014
Picon

[PATCH v3 0/8] Two-phase seccomp and x86 tracing changes

[applies on jmorris's security-next tree]

This is both a cleanup and a speedup.  It reduces overhead due to
installing a trivial seccomp filter by 87%.  The speedup comes from
avoiding the full syscall tracing mechanism for filters that don't
return SECCOMP_RET_TRACE.

This series works by splitting the seccomp hooks into two phases.
The first phase evaluates the filter; it can skip syscalls, allow
them, kill the calling task, or pass a u32 to the second phase.  The
second phase requires a full tracing context, and it sends ptrace
events if necessary.

Once this is done, I implemented a similar split for the x86 syscall
entry work.  The C callback is invoked in two phases: the first has
only a partial frame, and it can request phase 2 processing with a
full frame.

Finally, I switch the 64-bit system_call code to use the new split
entry work.  This is a net deletion of assembly code: it replaces
all of the audit entry muck.

In the process, I fixed some bugs.

If this is acceptable, someone can do the same tweak for the
ia32entry and entry_32 code.

This passes all seccomp tests that I know of.  Now that it's properly
rebased, even the previously expected failures are gone.

(Continue reading)

Kees Cook | 17 Jul 20:08 2014

[PATCH v12 11/11] seccomp: add thread sync ability

Twelfth time's the charm! :)

This adds the ability for threads to request seccomp filter
synchronization across their thread group (at filter attach time).
For example, for Chrome to make sure graphic driver threads are fully
confined after seccomp filters have been attached.

To support this, locking on seccomp changes via thread-group-shared
sighand lock is introduced, along with refactoring of no_new_privs. Races
with thread creation are handled via delayed duplication of the seccomp
task struct field and cred_guard_mutex.

This includes a new syscall (instead of adding a new prctl option),
as suggested by Andy Lutomirski and Michael Kerrisk.

Thanks!

-Kees

v12:
 - fixed bug where initial filter wouldn't allow TSYNC flag (drysdale)
 - optimized thread loops (drysdale)
v11:
 - updated writer locking commit log for clarity (luto)
 - clarified writer lock thread flag setting comment (luto)
 - inverted SECCOMP_FILTER_FLAG_MASK (luto)
 - renamed is_acestor parameter (luto)
 - added BUG_ON to catch currently impossible integer overflow (luto)
v10:
 - dropped pending-kill checks (oleg)
(Continue reading)

Mr. Alfred Robert | 17 Jul 07:50 2014

Kindly consider my proposal

---------------------------- Original Message ----------------------------
Good day

My name is Alfred Robert and I work with the finance house here in the
Netherlands. I found your address through my countries international
Web directory. During our last meeting and examination of the bank
accounts here in the Netherlands, my department found a dormant account
with an enormous sum of US$ 6,500,000.00 (Six million five hundred
thousand US dollar) which was deposited by late Mr. Williams
from England.

Before his death he transferred the sum of US$ 6,500,000.00 (Six million
five hundred thousand US dollar) to a bank here in Netherlands. From our
investigation he had no beneficiary or next of kin to claim these funds.
The financial regulations of our bank allow only a foreigner to stand as
next relatives or next of kin. The request of a foreigner as a next of kin
is base on the fact that the depositor was a foreigner and somebody in the
Netherlands cannot stand as the next of kin.

I need your permission as the next relative or next of kin of our deceased
customer, so that the funds can be released and transferred to your
account, at the end of the transaction 40% will be for you and 60% will be
for me and my colleague.
We need a foreign account. I still work at the financial house and that's
the actual reason that I need a second party or person to stand and work
with me and apply to the bank here in the Netherlands as the next of kin.
I have in my possession all the necessary documents to have this
transaction carried out successfully.

Further information will be provided upon the receipt of your prompt
(Continue reading)

Kees Cook | 16 Jul 23:50 2014

[PATCH v11 0/11] seccomp: add thread sync ability

This adds the ability for threads to request seccomp filter
synchronization across their thread group (at filter attach time).
For example, for Chrome to make sure graphic driver threads are fully
confined after seccomp filters have been attached.

To support this, locking on seccomp changes via thread-group-shared
sighand lock is introduced, along with refactoring of no_new_privs. Races
with thread creation are handled via delayed duplication of the seccomp
task struct field and cred_guard_mutex.

This includes a new syscall (instead of adding a new prctl option),
as suggested by Andy Lutomirski and Michael Kerrisk.

Thanks!

-Kees

v11:
 - updated writer locking commit log for clarity (luto)
 - clarified writer lock thread flag setting comment (luto)
 - inverted SECCOMP_FILTER_FLAG_MASK (luto)
 - renamed is_acestor parameter (luto)
 - added BUG_ON to catch currently impossible integer overflow (luto)
v10:
 - dropped pending-kill checks (oleg)
 - tweaked memory barriers (oleg)
v9:
 - rearranged/split patches to make things more reviewable
 - added use of cred_guard_mutex to solve exec race (oleg, luto)
 - added barriers for TIF_SECCOMP vs seccomp.mode race (oleg, luto)
(Continue reading)

Zubair Lutfullah Kakakhel | 16 Jul 17:51 2014
Zubair Lutfullah Kakakhel <Zubair.Kakakhel <at> imgtec.com>

Subject: [PATCH 0/4] mips: Add cma support to mips

[PATCH 0/4] mips: Add cma support to mips

Here we have 4 patches that add cma support to mips.

Patch 1 adds dma-contiguous.h to asm-generic
Patch 2 and 3 make arm64 and x86 use dma-contiguous from asm-generic
Patch 4 adds cma to mips.

I'd like to request ralf to take these set of 4 patches via his tree.

acks from asm-generic, arm64 and x86 welcome.

patches based on linux-next b997a07604562f1a54cc531fe1cf7447f0ed6078

Zubair Lutfullah Kakakhel (4):
  asm-generic: Add dma-contiguous.h
  arm64: use generic dma-contiguous.h
  x86: use generic dma-contiguous.h
  mips: dma: Add cma support

 arch/arm64/include/asm/Kbuild           |  1 +
 arch/arm64/include/asm/dma-contiguous.h | 28 -------------------------
 arch/mips/Kconfig                       |  1 +
 arch/mips/include/asm/Kbuild            |  1 +
 arch/mips/kernel/setup.c                |  9 ++++++++
 arch/mips/mm/dma-default.c              | 37 ++++++++++++++++++++++-----------
 arch/x86/include/asm/Kbuild             |  1 +
 arch/x86/include/asm/dma-contiguous.h   | 12 -----------
 include/asm-generic/dma-contiguous.h    |  9 ++++++++
 9 files changed, 47 insertions(+), 52 deletions(-)
 delete mode 100644 arch/arm64/include/asm/dma-contiguous.h
 delete mode 100644 arch/x86/include/asm/dma-contiguous.h
(Continue reading)

Thierry Reding | 16 Jul 13:01 2014
Picon

[PATCH v3 1/3] asm-generic/io.h: Implement generic {read,write}s*()

From: Thierry Reding <treding <at> nvidia.com>

Currently driver writers need to use io{read,write}{8,16,32}_rep() when
accessing FIFO registers portably. This is bad for two reasons: it is
inconsistent with how other registers are accessed using the standard
{read,write}{b,w,l}() functions, which can lead to confusion. On some
architectures the io{read,write}*() functions also need to perform some
extra checks to determine whether an address is memory-mapped or refers
to I/O space. Drivers which can be expected to never use I/O can safely
use the {read,write}s{b,w,l,q}(), just like they use their non-string
variants and there's no need for these extra checks.

This patch implements generic versions of readsb(), readsw(), readsl(),
readsq(), writesb(), writesw(), writesl() and writesq(). Variants of
these string functions for I/O accesses (ins*() and outs*() as well as
ioread*_rep() and iowrite*_rep()) are now implemented in terms of the
new functions.

Going forward, {read,write}{,s}{b,w,l,q}() should be used consistently
by drivers for devices that will only ever be memory-mapped and hence
don't need to access I/O space, whereas io{read,write}{8,16,32}_rep()
should be used by drivers for devices that can be either memory-mapped
or I/O-mapped.

While at it, also make sure that any of the functions provided as
fallback for architectures that don't override them can't be overridden
subsequently.

This is compile- and runtime-tested on 32-bit and 64-bit ARM and compile
tested on Microblaze, s390, SPARC and Xtensa. For ARC, Blackfin, Metag,
(Continue reading)

Andy Lutomirski | 15 Jul 21:32 2014
Picon

[PATCH 0/7] Two-phase seccomp and x86 tracing changes

This is both a cleanup and a speedup.  It reduces overhead due to
installing a trivial seccomp filter by 87%.  The speedup comes from
avoiding the full syscall tracing mechanism for filters that don't
return SECCOMP_RET_TRACE.

This series works by splitting the seccomp hooks into two phases.
The first phase evaluates the filter; it can skip syscalls, allow
them, kill the calling task, or pass a u32 to the second phase.  The
second phase requires a full tracing context, and it sends ptrace
events if necessary.

Once this is done, I implemented a similar split for the x86 syscall
entry work.  The C callback is invoked in two phases: the first has
only a partial frame, and it can request phase 2 processing with a
full frame.

Finally, I switch the 64-bit system_call code to use the new split
entry work.  This is a net deletion of assembly code: it replaces
all of the audit entry muck.

In the process, I fixed some bugs.

If this is acceptable, someone can do the same tweak for the
ia32entry and entry_32 code.

This passes all seccomp tests that I know of, except for the ones
that don't work on current kernels.

Presumably, once everyone gets a chance to poke at this, it should
go in to some combination of James' and hpa's trees.
(Continue reading)

Sam Ravnborg | 14 Jul 17:06 2014

[RFC PATCH 0/38] clean-up uapi + asm-generic Kbuild files

While working one another patch-set I noticed some stray Kbuild files.
And then when I started to dig into this it somehow got out
of control and I ended up with the following set of patches.

Almost 600 lines chopped of the kernel - which is nice.
But even better is that the Kbuild files for uapi + asm-generic
has become simpler to grok after the clean-up.

The patch-set contains the following major items:

o Fix headers_install for cris - this was trivial to fix
  after uapi support was added.

o Drop a few unused Kbuild files.

o Drop obsolete support for non uapi files in Makefile.headersinst

o Perform a long overdue clean-up of the uapi files.
 The files contained a lot of redundant assignments.

o The last patch introduces include/asm-generic/Kbuild.generic
  This file shall list all asm-generic files that are used by all architectures.
  This makes it much simpler to add a new common asm-generic file.

The patch was broken up in many smaller peices as I wanted to keep the clean-up
patches separate for each architecture to make it easier for arch maintainers to
review/ack their part.

The clean-up patches rely on one of the former patches so they shall
be applied as one serie.
(Continue reading)

Helge Deller | 14 Jul 12:14 2014
Picon
Picon

Aw: [PATCH 15/43] parisc: Use get_signal() signal_setup_done()

Hi Richard,

nice work!
I pulled your tree and tested your patch series on parisc.
Everything seems OK.

Regarding the changes to the parisc arch, you can add my

Acked-by: Helge Deller <deller <at> gmx.de>

Thanks!
Helge

> Betreff: [PATCH 15/43] parisc: Use get_signal() signal_setup_done()
>
> Use the more generic functions get_signal() signal_setup_done()
> for signal delivery.
> 
> Signed-off-by: Richard Weinberger <richard <at> nod.at>
> ---
>  arch/parisc/kernel/signal.c | 58 +++++++++++++++++++--------------------------
>  1 file changed, 24 insertions(+), 34 deletions(-)
> 
> diff --git a/arch/parisc/kernel/signal.c b/arch/parisc/kernel/signal.c
> index 1cba8f2..012d4fa 100644
> --- a/arch/parisc/kernel/signal.c
> +++ b/arch/parisc/kernel/signal.c
>  <at>  <at>  -227,8 +227,8  <at>  <at>  setup_sigcontext(struct sigcontext __user *sc, struct pt_regs *regs, int in_sysc
>  }
>  
(Continue reading)

Mr.Mathew | 13 Jul 19:32 2014
Picon

Urgent

Dear Beneficiary,
Kindly get back to us for your winning prize.
Thanks and remain bless.
Mr.Mathew Okwu
Thierry Reding | 11 Jul 17:31 2014
Picon

[PATCH v2 1/3] asm-generic/io.h: Implement generic {read,write}s*()

From: Thierry Reding <treding <at> nvidia.com>

This patch implements generic versions of readsb(), readsw(), readsl(),
readsq(), writesb(), writesw(), writesl() and writesq(). Variants of
these string functions for I/O accesses (ins*() and outs*() as well as
ioread*_rep() and iowrite*_rep()) are now implemented in terms of the
new functions.

While at it, also make sure that any of the functions provided as
fallback for architectures that don't override them can't be overridden
subsequently.

This is compile- and runtime-tested on 32-bit and 64-bit ARM and compile
tested on Microblaze, s390, SPARC and Xtensa. For ARC, Blackfin, Metag,
OpenRISC, Score and Unicore32 which also use asm-generic/io.h I couldn't
find or build a cross-compiler that would run on my system. But by code
inspection they shouldn't break with this patch.

Signed-off-by: Thierry Reding <treding <at> nvidia.com>
---
Changes in v2:
- respect IO_SPACE_LIMIT in ioport_map()

 include/asm-generic/io.h | 278 +++++++++++++++++++++++++++++++++--------------
 1 file changed, 197 insertions(+), 81 deletions(-)

diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 975e1cc75edb..32aecbe41188 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
(Continue reading)


Gmane