Margaret Crawford | 29 Jul 19:00 2014
Picon

Humanitarian help

Hello,

I am Mrs. Margaret Crawford, i write you this email to seek for your Humanitarian help, i have decided to
donate part of my inheritance to you for humanitarian work and your personal use. As a result of my heart
status. I need you to contact my Attorney. Mark Lawson. with this email for a better information only if you
are interested. Email: mlawson <at> citynew.com

Thank you
Mrs. Margaret Crawford
____________________________________________________________________________________

"Zero Problem 2014, Cakupan Semesta 2019"

Mari kita bergotong royong sukseskan Sistem Jaminan Sosial Kesehatan, demi tercapainya Jaminan
Kesehatan untuk Semesta Bagi Seluruh Rakyat Indonesia Tahun 
2019

HALLO BPJS KESEHATAN 500-400
Noemi Alvarez | 29 Jul 10:23 2014
Picon

Hello


I want to keep up with you with hope for friendship if you are interested.
If you don't mind i will like you to write me back. I am waiting to read
from you, because i have something important and urgent to discuss with
you. I will also send some of my beautiful photos to you.

Andy Lutomirski | 29 Jul 05:38 2014
Picon

[PATCH v4 0/5] x86: two-phase syscall tracing and seccomp fastpath

This applies to:
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git seccomp-fastpath

Gitweb:
https://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/log/?h=seccomp/fastpath

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 depends on 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.  The seccomp core part is in Kees' seccomp/fastpath
tree.

These patches implement 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
(Continue reading)

Yijing Wang | 26 Jul 05:08 2014

[RFC PATCH 00/11] Refactor MSI to support Non-PCI device

Hi all,
	The series is a draft of generic MSI driver that supports PCI
and Non-PCI device which have MSI capability. If you're not interested
it, sorry for the noise.

The series is based on Linux-3.16-rc1.

MSI was introduced in PCI Spec 2.2. Currently, kernel MSI 
driver codes are bonding with PCI device. Because MSI has a lot
advantages in design. More and more non-PCI devices want to
use MSI as their default interrupt. The existing MSI device
include HPET. HPET driver provide its own MSI code to initialize
and process MSI interrupts. In the latest GIC v3 spec, legacy device
can deliver MSI by the help of a relay device named consolidator.
Consolidator can translate the legacy interrupts connected to it
to MSI/MSI-X. And new non-PCI device will be designed to 
support MSI in future. So make the MSI driver code be generic will 
help the non-PCI device use MSI more simply.

The new data struct for generic MSI driver.
struct msi_irqs {
	u8 msi_enabled:1; /* Enable flag */
	u8 msix_enabled:1;
	struct list_head msi_list; /* MSI desc list */
	void *data;	/* help to find the MSI device */
	struct msi_ops *ops; /* MSI device specific hook */
};
struct msi_irqs is used to manage MSI related informations. Every device supports
MSI should contain this data struct and allocate it.

(Continue reading)

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)


Gmane