* Re: [PATCH 1/1] infiniband: hw: mlx4: fix improper return value
From: Doug Ledford @ 2016-12-14 19:35 UTC (permalink / raw)
To: Pan Bian, Leon Romanovsky, Yishai Hadas, Sean Hefty,
Hal Rosenstock, linux-rdma
Cc: linux-kernel, Pan Bian
In-Reply-To: <1480833938-6284-1-git-send-email-bianpan201603@163.com>
[-- Attachment #1.1: Type: text/plain, Size: 666 bytes --]
On 12/4/2016 1:45 AM, Pan Bian wrote:
> From: Pan Bian <bianpan2016@163.com>
>
> If uhw->inlen is non-zero, the value of variable err is 0 if the copy
> succeeds. Then, if kzalloc() or kmalloc() returns a NULL pointer, it
> will return 0 to the callers. As a result, the callers cannot detect the
> errors. This patch fixes the bug, assign "-ENOMEM" to err before the
> NULL pointer checks, and remove the initialization of err at the
> beginning.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=189031
> Signed-off-by: Pan Bian <bianpan2016@163.com>
Thanks, applied.
--
Doug Ledford <dledford@redhat.com>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function
From: Jason A. Donenfeld @ 2016-12-14 19:35 UTC (permalink / raw)
To: Tom Herbert
Cc: Netdev, kernel-hardening, LKML, Linux Crypto Mailing List,
Jean-Philippe Aumasson, Daniel J . Bernstein, Linus Torvalds,
Eric Biggers, David Laight
In-Reply-To: <CALx6S35UgTyqkYUjS5gYFH4HnjW974WQ_JiDXxgb9rZ7gnY52Q@mail.gmail.com>
Hi Tom,
On Wed, Dec 14, 2016 at 8:18 PM, Tom Herbert <tom@herbertland.com> wrote:
> "super fast" is relative. My quick test shows that this faster than
> Toeplitz (good, but not exactly hard to achieve), but is about 4x
> slower than jhash.
Fast relative to other cryptographically secure PRFs.
>> SipHash isn't just some new trendy hash function. It's been around for a
>> while, and there really isn't anything that comes remotely close to
>> being useful in the way SipHash is. With that said, why do we need this?
> I don't think we need advertising nor a lesson on hashing. It would be
> much more useful if you just point us to the paper on siphash (which I
> assume I http://cr.yp.to/siphash/siphash-20120918.pdf ?).
Ugh. Sorry. It definitely wasn't my intention to give an uninvited
lesson or an annoying advert. For the former, I didn't want to make
any expectations about fields of knowledge, because I honest have no
idea. For the latter, I wrote that sentence to indicate that siphash
isn't just some newfangled hipster function, but something useful and
well established. I didn't mean it as a form of advertising. My
apologies if I've offended your sensibilities.
That cr.yp.to link is fine, or https://131002.net/siphash/siphash.pdf I believe.
> Key rotation is important anyway, without any key rotation even if the
> key is compromised in siphash by some external means we would have an
> insecure hash until the system reboots.
I'm a bit surprised to read this. I've never designed a system to be
secure even in the event of remote arbitrary kernel memory disclosure,
and I wasn't aware this was generally considered an architectural
requirement or Linux.
In any case, if you want this, I suppose you can have it with siphash too.
> Maybe so, but we need to do due diligence before considering adopting
> siphash as the primary hashing in the network stack. Consider that we
> may very well perform a hash over L4 tuples on _every_ packet. We've
> done a good job at limiting this to be at most one hash per packet,
> but nevertheless the performance of the hash function must be take
> into account.
I agree with you. It seems like each case is going to needed to be
measured on a case by case basis. In this series I make the first use
of siphash in the secure sequence generation and get_random_int/long,
where siphash replaces md5, so there's a pretty clear performance in.
But for the jhash replacements indeed things are going to need to be
individually evaluated.
> 1) My quick test shows siphash is about four times more expensive than
> jhash. On my test system, computing a hash over IPv4 tuple (two 32 bit
> addresses and 2 16 bit source ports) is 6.9 nsecs in Jenkins hash, 33
> nsecs with siphash. Given that we have eliminated most of the packet
> header hashes this might be tolerable, but still should be looking at
> ways to optimize.
> 2) I like moving to use u64 (quad words) in the hash, this is an
> improvement over Jenkins which is based on 32 bit words. If we put
> this in the kernel we probably want to have several variants of
> siphash for specific sizes (e.g. siphash1, siphash2, siphash2,
> siphashn for hash over one, two, three, or n sixty four bit words).
I think your suggestion for (2) will contribute to further
optimizations for (1). In v2, I had another patch in there adding
siphash_1word, siphash_2words, etc, like jhash, but I implemented it
by taking u32 variables and then just concatenating these into a
buffer and passing them to the main siphash function. I removed it
from v3 because I thought that these kind of missed the whole point.
In particular:
a) siphash24_1word, siphash24_2words, siphash24_3words, etc should
take u64, not u32, since that's what siphash operates on natively
b) Rather than concatenating them in a buffer, I should write
specializations of the siphash24 function _especially_ for these size
inputs to avoid the copy and to reduce the book keeping.
I'll add these functions to v4 implemented like that.
Thanks for the useful feedback and benchmarks!
Jason
^ permalink raw reply
* Re: [PATCH 1/1] infiniband: hw: ocrdma: fix bad initialization
From: Doug Ledford @ 2016-12-14 19:34 UTC (permalink / raw)
To: Leon Romanovsky, Pan Bian
Cc: Selvin Xavier, Devesh Sharma, Mitesh Ahuja, Sean Hefty,
Hal Rosenstock, linux-rdma, linux-kernel, Pan Bian
In-Reply-To: <20161204062037.GH4497@leon.nu>
[-- Attachment #1.1: Type: text/plain, Size: 669 bytes --]
On 12/4/2016 1:20 AM, Leon Romanovsky wrote:
> On Sat, Dec 03, 2016 at 09:10:21PM +0800, Pan Bian wrote:
>> From: Pan Bian <bianpan2016@163.com>
>>
>> In function ocrdma_mbx_create_ah_tbl(), returns the value of status on
>> errors. However, because status is initialized with 0, 0 will be
>> returned even if on error paths. This patch initialize status with
>> "-ENOMEM".
>>
>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188831
>>
>> Signed-off-by: Pan Bian <bianpan2016@163.com>
>
> Thanks,
> Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
>
Thanks, applied.
--
Doug Ledford <dledford@redhat.com>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH v2] crypto: sun4i-ss: support the Security System PRNG
From: PrasannaKumar Muralidharan @ 2016-12-14 19:17 UTC (permalink / raw)
To: Herbert Xu
Cc: Corentin Labbe, davem, maxime.ripard, Chen-Yu Tsai, linux-kernel,
linux-crypto, linux-arm-kernel
In-Reply-To: <20161214050551.GD9592@gondor.apana.org.au>
>> I have found two solutions:
>
> No we already have algif_rng so let's not confuse things even
> further by making hwrng take PRNGs.
Even if both the solutions could not be adopted I think there must be
a way for applications to use similar API to get true rng or prng.
Given the case that no user complained about prng data when using
/dev/hwrng is it safe to assume that the random data generated is
acceptable for users? If so, the drivers can be left without any
modification.
Should there be a mandate that driver will be accepted only when it
passes 'rngtest'. This will make sure that prng drivers won't get
added in future.
Regards,
PrasannaKumar
^ permalink raw reply
* Re: [PATCH 1/1] infiniband: nes: return value of skb_linearize should be handled
From: Doug Ledford @ 2016-12-14 19:29 UTC (permalink / raw)
To: Zhouyi Zhou, faisal.latif, sean.hefty, hal.rosenstock,
eric.dumazet, linux-rdma, linux-kernel
Cc: Zhouyi Zhou
In-Reply-To: <1481095805-25010-1-git-send-email-zhouzhouyi@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 410 bytes --]
On 12/7/2016 2:30 AM, Zhouyi Zhou wrote:
> Return value of skb_linearize should be handled in function
> nes_netdev_start_xmit.
>
> Compiled in x86_64
> Signed-off-by: Zhouyi Zhou <yizhouzhou@ict.ac.cn>
> Reviewed-by: Yuval Shaia <yuval.shaia@oracle.com>
> Reviewed-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks.
--
Doug Ledford <dledford@redhat.com>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [tip:x86/urgent] x86/boot/64: Use 'push' instead of 'call' in start_cpu()
From: hpa @ 2016-12-14 19:24 UTC (permalink / raw)
To: linux-tip-commits, tip-bot for Josh Poimboeuf
Cc: linux-kernel, bp, tglx, torvalds, peterz, luto, jpoimboe, mingo,
brgerst, dvlasenk
In-Reply-To: <tip-ec2d86a9b646d93f1948569f368e2c6f5449e6c7@git.kernel.org>
On December 14, 2016 12:36:58 AM PST, tip-bot for Josh Poimboeuf <tipbot@zytor.com> wrote:
>Commit-ID: ec2d86a9b646d93f1948569f368e2c6f5449e6c7
>Gitweb:
>http://git.kernel.org/tip/ec2d86a9b646d93f1948569f368e2c6f5449e6c7
>Author: Josh Poimboeuf <jpoimboe@redhat.com>
>AuthorDate: Tue, 13 Dec 2016 21:25:35 -0600
>Committer: Ingo Molnar <mingo@kernel.org>
>CommitDate: Wed, 14 Dec 2016 08:48:05 +0100
>
>x86/boot/64: Use 'push' instead of 'call' in start_cpu()
>
>start_cpu() pushes a text address on the stack so that stack traces
>from
>idle tasks will show start_cpu() at the end. But it uses a call
>instruction to do that, which is rather obtuse. Use a straightforward
>push instead.
>
>Suggested-by: Borislav Petkov <bp@alien8.de>
>Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
>Cc: Andy Lutomirski <luto@kernel.org>
>Cc: Brian Gerst <brgerst@gmail.com>
>Cc: Denys Vlasenko <dvlasenk@redhat.com>
>Cc: H. Peter Anvin <hpa@zytor.com>
>Cc: Linus Torvalds <torvalds@linux-foundation.org>
>Cc: Peter Zijlstra <peterz@infradead.org>
>Cc: Thomas Gleixner <tglx@linutronix.de>
>Link:
>http://lkml.kernel.org/r/4d8a1952759721d42d1e62ba9e4a7e3ac5df8574.1481685203.git.jpoimboe@redhat.com
>Signed-off-by: Ingo Molnar <mingo@kernel.org>
>---
> arch/x86/kernel/head_64.S | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
>index 90de288..1facaf4 100644
>--- a/arch/x86/kernel/head_64.S
>+++ b/arch/x86/kernel/head_64.S
>@@ -298,7 +298,7 @@ ENTRY(start_cpu)
> * REX.W + FF /5 JMP m16:64 Jump far, absolute indirect,
> * address given in m16:64.
> */
>- call 1f # put return address on stack for unwinder
>+ pushq $1f # put return address on stack for unwinder
> 1: xorq %rbp, %rbp # clear frame pointer
> movq initial_code(%rip), %rax
> pushq $__KERNEL_CS # set correct cs
This adds another relocation to the kernel. I hope this is safe at this point in the code?
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
^ permalink raw reply
* [PATCH] usb: musb: debugfs: allow forcing host mode together with speed in testmode
From: Pali Rohár @ 2016-12-14 19:23 UTC (permalink / raw)
To: Bin Liu, Greg Kroah-Hartman
Cc: linux-usb, linux-kernel, Tony Lindgren, joerg Reisenweber,
linux-omap, Ivaylo Dimitrov, Sebastian Reichel, Aaro Koskinen,
Pavel Machek, Nishanth Menon, Felipe Balbi, Pali Rohár
In-Reply-To: <1481726877-18548-1-git-send-email-pali.rohar@gmail.com>
Based on the musb ug, force_host bit is allowed to be set along with
force_hs or force_fs bit.
It could help to implement forced host mode via testmode on Nokia N900.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
---
drivers/usb/musb/musb_debugfs.c | 44 +++++++++++++++++++++++++--------------
1 file changed, 28 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/musb/musb_debugfs.c b/drivers/usb/musb/musb_debugfs.c
index 9b22d94..62c13a2 100644
--- a/drivers/usb/musb/musb_debugfs.c
+++ b/drivers/usb/musb/musb_debugfs.c
@@ -147,28 +147,34 @@ static int musb_test_mode_show(struct seq_file *s, void *unused)
test = musb_readb(musb->mregs, MUSB_TESTMODE);
- if (test & MUSB_TEST_FORCE_HOST)
+ if (test & (MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_FS))
+ seq_printf(s, "force host full-speed\n");
+
+ else if (test & (MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_HS))
+ seq_printf(s, "force host high-speed\n");
+
+ else if (test & MUSB_TEST_FORCE_HOST)
seq_printf(s, "force host\n");
- if (test & MUSB_TEST_FIFO_ACCESS)
+ else if (test & MUSB_TEST_FIFO_ACCESS)
seq_printf(s, "fifo access\n");
- if (test & MUSB_TEST_FORCE_FS)
+ else if (test & MUSB_TEST_FORCE_FS)
seq_printf(s, "force full-speed\n");
- if (test & MUSB_TEST_FORCE_HS)
+ else if (test & MUSB_TEST_FORCE_HS)
seq_printf(s, "force high-speed\n");
- if (test & MUSB_TEST_PACKET)
+ else if (test & MUSB_TEST_PACKET)
seq_printf(s, "test packet\n");
- if (test & MUSB_TEST_K)
+ else if (test & MUSB_TEST_K)
seq_printf(s, "test K\n");
- if (test & MUSB_TEST_J)
+ else if (test & MUSB_TEST_J)
seq_printf(s, "test J\n");
- if (test & MUSB_TEST_SE0_NAK)
+ else if (test & MUSB_TEST_SE0_NAK)
seq_printf(s, "test SE0 NAK\n");
return 0;
@@ -206,30 +212,36 @@ static ssize_t musb_test_mode_write(struct file *file,
if (copy_from_user(buf, ubuf, min_t(size_t, sizeof(buf) - 1, count)))
return -EFAULT;
- if (strstarts(buf, "force host"))
+ if (strstarts(buf, "force host full-speed"))
+ test = MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_FS;
+
+ else if (strstarts(buf, "force host high-speed"))
+ test = MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_HS;
+
+ else if (strstarts(buf, "force host"))
test = MUSB_TEST_FORCE_HOST;
- if (strstarts(buf, "fifo access"))
+ else if (strstarts(buf, "fifo access"))
test = MUSB_TEST_FIFO_ACCESS;
- if (strstarts(buf, "force full-speed"))
+ else if (strstarts(buf, "force full-speed"))
test = MUSB_TEST_FORCE_FS;
- if (strstarts(buf, "force high-speed"))
+ else if (strstarts(buf, "force high-speed"))
test = MUSB_TEST_FORCE_HS;
- if (strstarts(buf, "test packet")) {
+ else if (strstarts(buf, "test packet")) {
test = MUSB_TEST_PACKET;
musb_load_testpacket(musb);
}
- if (strstarts(buf, "test K"))
+ else if (strstarts(buf, "test K"))
test = MUSB_TEST_K;
- if (strstarts(buf, "test J"))
+ else if (strstarts(buf, "test J"))
test = MUSB_TEST_J;
- if (strstarts(buf, "test SE0 NAK"))
+ else if (strstarts(buf, "test SE0 NAK"))
test = MUSB_TEST_SE0_NAK;
musb_writeb(musb->mregs, MUSB_TESTMODE, test);
--
1.7.9.5
^ permalink raw reply related
* Re: [kernel-hardening] [RFC 0/4] make call_usermodehelper a bit more "safe"
From: Mark Rutland @ 2016-12-14 19:25 UTC (permalink / raw)
To: Greg KH; +Cc: kernel-hardening, linux-kernel, Gengjia Chen, Kees Cook
In-Reply-To: <20161214185000.GA3930@kroah.com>
Hi,
On Wed, Dec 14, 2016 at 10:50:00AM -0800, Greg KH wrote:
> The issue is that if you end up getting write access to kernel memory,
> if you change the string '/sbin/hotplug' to point to
> '/home/hacked/my_binary', then the next uevent that the system makes
> will call this binary instead of the "trusted" one.
>
> It does this by moving the location of the binary to be in read-only
> memory. This works for a number of call_usermodehelper strings, as they
> are specified at build or configuration time. But, some subsystems have
> the option to let userspace change the value at runtime, so those values
> can't live in read-only memory.
> So, anyone have any better ideas? Is this approach worth it? Or should
> we just go down the "whitelist" path?
As a general note, I believe the write-rarely / mostly-ro [1] stuff is
meant to cater for this case, but I haven't heard anything on that front
recently (and there doesn't appear to be anything on the KSPP TODO
page).
If that does cater for this case, and if we're able to implement that
generically, that might be nicer than locking down the set of binaries
at build time.
Chen, are you still looking at implementing write-rarely support?
Thanks,
Mark.
[1] http://www.openwall.com/lists/kernel-hardening/2016/11/16/3
^ permalink raw reply
* Re: [PATCH v2 01/46] mtdpart: Propagate _get/put_device()
From: Karl Beldan @ 2016-12-14 19:24 UTC (permalink / raw)
To: Brian Norris
Cc: Boris Brezillon, Richard Weinberger,
linux-mtd@lists.infradead.org, David Woodhouse,
linux-kernel@vger.kernel.org, Daniel Walter, Stable
In-Reply-To: <20160928201611.GB142302@google.com>
On Wed, Sep 28, 2016 at 8:16 PM, Brian Norris
<computersforpeace@gmail.com> wrote:
> On Wed, Sep 21, 2016 at 12:15:31PM +0200, Boris Brezillon wrote:
>> On Wed, 21 Sep 2016 11:43:56 +0200
>> Daniel Walter <dwalter@sigma-star.at> wrote:
>>
>> > From: Richard Weinberger <richard@nod.at>
>> >
>> > If the master device has callbacks for _get/put_device()
>> > and this MTD has slaves a get_mtd_device() call on paritions
>> > will never issue the registered callbacks.
>> > Fix this by propagating _get/put_device() down.
>>
>> Brian, can we have this one queued for 4.9? I can't take it in my tree
>> if you want, but it's probably better if it's in the mtd tree.
>
> Applied this patch to l2-mtd.git
>
I think this should also go into -stable.
^ permalink raw reply
* Re: [PATCH] IB/core: fix unmap_sg argument
From: Doug Ledford @ 2016-12-14 19:21 UTC (permalink / raw)
To: Sebastian Ott, Sean Hefty, Hal Rosenstock; +Cc: linux-rdma, linux-kernel
In-Reply-To: <alpine.LFD.2.20.1612021439450.3570@schleppi>
[-- Attachment #1.1: Type: text/plain, Size: 1218 bytes --]
On 12/2/2016 8:45 AM, Sebastian Ott wrote:
> __ib_umem_release calls dma_unmap_sg with a different number of
> sg_entries than ib_umem_get uses for dma_map_sg. This might cause
> trouble for implementations that merge sglist entries and results
> in the following dma debug complaint:
>
> DMA-API: device driver frees DMA sg list with different entry
> count [map count=2] [unmap count=1]
>
> Fix it by using the correct value.
>
> Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
> ---
> drivers/infiniband/core/umem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
> index 84b4eff..1e62a5f 100644
> --- a/drivers/infiniband/core/umem.c
> +++ b/drivers/infiniband/core/umem.c
> @@ -51,7 +51,7 @@ static void __ib_umem_release(struct ib_device *dev, struct ib_umem *umem, int d
>
> if (umem->nmap > 0)
> ib_dma_unmap_sg(dev, umem->sg_head.sgl,
> - umem->nmap,
> + umem->npages,
> DMA_BIDIRECTIONAL);
>
> for_each_sg(umem->sg_head.sgl, sg, umem->npages, i) {
>
Thanks, applied.
--
Doug Ledford <dledford@redhat.com>
GPG Key ID: 0E572FDD
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform
From: Hannes Frederic Sowa @ 2016-12-14 19:22 UTC (permalink / raw)
To: Jason A. Donenfeld, David Miller
Cc: David Laight, Netdev, kernel-hardening, Andi Kleen, LKML,
Linux Crypto Mailing List
In-Reply-To: <CAHmME9pz4XudfeqhKBwFNDmp7AYuNwbnevMqB3e6ScPDnUnq9g@mail.gmail.com>
On 14.12.2016 19:06, Jason A. Donenfeld wrote:
> Hi David,
>
> On Wed, Dec 14, 2016 at 6:56 PM, David Miller <davem@davemloft.net> wrote:
>> Just marking the structure __packed, whether necessary or not, makes
>> the compiler assume that the members are not aligned and causes
>> byte-by-byte accesses to be performed for words.
>> Never, _ever_, use __packed unless absolutely necessary, it pessimizes
>> the code on cpus that require proper alignment of types.
>
> Oh, jimminy cricket, I did not realize that it made assignments
> byte-by-byte *always*. So what options am I left with? What
> immediately comes to mind are:
>
> 1)
>
> struct {
> u64 a;
> u32 b;
> u32 c;
> u16 d;
> u8 end[];
I don't think this helps. Did you test it? I don't see reason why
padding could be left out between `d' and `end' because of the flexible
array member?
Bye,
Hannes
^ permalink raw reply
* RE: [PATCH] perf tools: ignore zombie process for user profile
From: Liang, Kan @ 2016-12-14 19:19 UTC (permalink / raw)
To: acme@kernel.org
Cc: Jiri Olsa, linux-kernel@vger.kernel.org, mingo@redhat.com,
peterz@infradead.org, jolsa@kernel.org, Hunter, Adrian,
andi@firstfloor.org
In-Reply-To: <20161214191320.GA6866@kernel.org>
.
> Em Wed, Dec 14, 2016 at 06:26:02PM +0000, Liang, Kan escreveu:
> > > On Wed, Dec 14, 2016 at 12:48:05PM -0500, kan.liang@intel.com wrote:
> > > > From: Kan Liang <kan.liang@intel.com> Zombie process is dead
> > > > process. It is meaningless to profile it.
> > > > It's better to ignore it for user profile.
>
> > > I recently posted different patch for same issue:
> > > http://marc.info/?l=linux-kernel&m=148153895827359&w=2
>
> > The change as below make me confuse.
> > + /* The system wide setup does not work with threads. */
> > + if (!evsel->system_wide)
> > + return false;
> > It looks the meaning of the comments is inconsistent with the code.
>
> > Your original patch doesn't work well with the issue.
> > But if I change the above code as below, the issue is fixed.
> > if (evsel->system_wide)
> > return false;
>
> yeah, Namhyung noticed that, Jiri sent a fixed patch, I have it already in my
> perf/core branch.
>
That's great. Then Jiri's patch would work on my case.
Please ignore this patch.
Thanks,
Kan
^ permalink raw reply
* Re: [f2fs-dev] [GIT PULL] f2fs update for 4.10
From: Jaegeuk Kim @ 2016-12-14 19:18 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux FS Dev Mailing List, Linux Kernel Mailing List,
Linux F2FS Dev Mailing List
In-Reply-To: <20161214184014.GA1116@jaegeuk.local>
On 12/14, Jaegeuk Kim wrote:
> On 12/14, Linus Torvalds wrote:
> > On Mon, Dec 12, 2016 at 2:15 PM, Jaegeuk Kim <jaegeuk@kernel.org> wrote:
> > >
> > > Could you please consider this pull request?
> >
> > Pulled. Mind double-checking my resolution wrt commit 70fd76140a6c
> > ("block,fs: use REQ_* flags directly")?
>
> Thank you, and the resolution looks good to me as well.
BTW, I just downloaded mainline, and tried to build a debian package but
failed due to missing Documentation/Changes.
I've found out that it was renamed by commit 186128f753
("docs-rst: add documents to development-process")
And when taking a look at its description, it was supposed to do symlink for
document files, but did rename all of them.
Afterwards, I could see some files were re-added by commit 08a9a8d44c1
("doc: re-add CodingStyle and SubmittingPatches")
In order to build a package for now, I just added a symlink like below.
---
Documentation/Changes | 1 +
1 file changed, 1 insertion(+)
create mode 120000 Documentation/Changes
diff --git a/Documentation/Changes b/Documentation/Changes
new file mode 120000
index 000000000000..7564ae1682ba
--- /dev/null
+++ b/Documentation/Changes
@@ -0,0 +1 @@
+process/changes.rst
\ No newline at end of file
--
2.11.0
Thanks,
>
> Thanks,
>
> >
> > Linus
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply related
* Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function
From: Tom Herbert @ 2016-12-14 19:18 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Netdev, kernel-hardening, LKML, linux-crypto,
Jean-Philippe Aumasson, Daniel J . Bernstein, Linus Torvalds,
Eric Biggers, David Laight
In-Reply-To: <20161214184605.24006-1-Jason@zx2c4.com>
On Wed, Dec 14, 2016 at 10:46 AM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> SipHash is a 64-bit keyed hash function that is actually a
> cryptographically secure PRF, like HMAC. Except SipHash is super fast,
> and is meant to be used as a hashtable keyed lookup function.
>
"super fast" is relative. My quick test shows that this faster than
Toeplitz (good, but not exactly hard to achieve), but is about 4x
slower than jhash.
> SipHash isn't just some new trendy hash function. It's been around for a
> while, and there really isn't anything that comes remotely close to
> being useful in the way SipHash is. With that said, why do we need this?
>
I don't think we need advertising nor a lesson on hashing. It would be
much more useful if you just point us to the paper on siphash (which I
assume I http://cr.yp.to/siphash/siphash-20120918.pdf ?).
> There are a variety of attacks known as "hashtable poisoning" in which an
> attacker forms some data such that the hash of that data will be the
> same, and then preceeds to fill up all entries of a hashbucket. This is
> a realistic and well-known denial-of-service vector.
>
> Linux developers already seem to be aware that this is an issue, and
> various places that use hash tables in, say, a network context, use a
> non-cryptographically secure function (usually jhash) and then try to
> twiddle with the key on a time basis (or in many cases just do nothing
> and hope that nobody notices). While this is an admirable attempt at
> solving the problem, it doesn't actually fix it. SipHash fixes it.
>
Key rotation is important anyway, without any key rotation even if the
key is compromised in siphash by some external means we would have an
insecure hash until the system reboots.
> (It fixes it in such a sound way that you could even build a stream
> cipher out of SipHash that would resist the modern cryptanalysis.)
>
> There are a modicum of places in the kernel that are vulnerable to
> hashtable poisoning attacks, either via userspace vectors or network
> vectors, and there's not a reliable mechanism inside the kernel at the
> moment to fix it. The first step toward fixing these issues is actually
> getting a secure primitive into the kernel for developers to use. Then
> we can, bit by bit, port things over to it as deemed appropriate.
>
> Secondly, a few places are using MD5 for creating secure sequence
> numbers, port numbers, or fast random numbers. Siphash is a faster, more
> fittting, and more secure replacement for MD5 in those situations.
>
> Dozens of languages are already using this internally for their hash
> tables. Some of the BSDs already use this in their kernels. SipHash is
> a widely known high-speed solution to a widely known problem, and it's
> time we catch-up.
>
Maybe so, but we need to do due diligence before considering adopting
siphash as the primary hashing in the network stack. Consider that we
may very well perform a hash over L4 tuples on _every_ packet. We've
done a good job at limiting this to be at most one hash per packet,
but nevertheless the performance of the hash function must be take
into account.
A few points:
1) My quick test shows siphash is about four times more expensive than
jhash. On my test system, computing a hash over IPv4 tuple (two 32 bit
addresses and 2 16 bit source ports) is 6.9 nsecs in Jenkins hash, 33
nsecs with siphash. Given that we have eliminated most of the packet
header hashes this might be tolerable, but still should be looking at
ways to optimize.
2) I like moving to use u64 (quad words) in the hash, this is an
improvement over Jenkins which is based on 32 bit words. If we put
this in the kernel we probably want to have several variants of
siphash for specific sizes (e.g. siphash1, siphash2, siphash2,
siphashn for hash over one, two, three, or n sixty four bit words).
3) I also tested siphash distribution and Avalanche Effect (these
really should have been covered in the paper :-( ). Both of these are
good with siphash, in fact almost have identical characteristics to
Jenkins hash.
Tom
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> Cc: Jean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com>
> Cc: Daniel J. Bernstein <djb@cr.yp.to>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Eric Biggers <ebiggers3@gmail.com>
> Cc: David Laight <David.Laight@aculab.com>
> ---
> Changes from v2->v3:
>
> - There is now a fast aligned version of the function and a not-as-fast
> unaligned version. The requirements for each have been documented in
> a docbook-style comment. As well, the header now contains a constant
> for the expected alignment.
>
> - The test suite has been updated to check both the unaligned and aligned
> version of the function.
>
> include/linux/siphash.h | 30 ++++++++++
> lib/Kconfig.debug | 6 +-
> lib/Makefile | 5 +-
> lib/siphash.c | 153 ++++++++++++++++++++++++++++++++++++++++++++++++
> lib/test_siphash.c | 85 +++++++++++++++++++++++++++
> 5 files changed, 274 insertions(+), 5 deletions(-)
> create mode 100644 include/linux/siphash.h
> create mode 100644 lib/siphash.c
> create mode 100644 lib/test_siphash.c
>
> diff --git a/include/linux/siphash.h b/include/linux/siphash.h
> new file mode 100644
> index 000000000000..82dc1a911a2e
> --- /dev/null
> +++ b/include/linux/siphash.h
> @@ -0,0 +1,30 @@
> +/* Copyright (C) 2016 Jason A. Donenfeld <Jason@zx2c4.com>
> + *
> + * This file is provided under a dual BSD/GPLv2 license.
> + *
> + * SipHash: a fast short-input PRF
> + * https://131002.net/siphash/
> + */
> +
> +#ifndef _LINUX_SIPHASH_H
> +#define _LINUX_SIPHASH_H
> +
> +#include <linux/types.h>
> +
> +enum siphash_lengths {
> + SIPHASH24_KEY_LEN = 16,
> + SIPHASH24_ALIGNMENT = 8
> +};
> +
> +u64 siphash24(const u8 *data, size_t len, const u8 key[SIPHASH24_KEY_LEN]);
> +
> +#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> +static inline u64 siphash24_unaligned(const u8 *data, size_t len, const u8 key[SIPHASH24_KEY_LEN])
> +{
> + return siphash24(data, len, key);
> +}
> +#else
> +u64 siphash24_unaligned(const u8 *data, size_t len, const u8 key[SIPHASH24_KEY_LEN]);
> +#endif
> +
> +#endif /* _LINUX_SIPHASH_H */
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index e6327d102184..32bbf689fc46 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1843,9 +1843,9 @@ config TEST_HASH
> tristate "Perform selftest on hash functions"
> default n
> help
> - Enable this option to test the kernel's integer (<linux/hash,h>)
> - and string (<linux/stringhash.h>) hash functions on boot
> - (or module load).
> + Enable this option to test the kernel's integer (<linux/hash.h>),
> + string (<linux/stringhash.h>), and siphash (<linux/siphash.h>)
> + hash functions on boot (or module load).
>
> This is intended to help people writing architecture-specific
> optimized versions. If unsure, say N.
> diff --git a/lib/Makefile b/lib/Makefile
> index 50144a3aeebd..71d398b04a74 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -22,7 +22,8 @@ lib-y := ctype.o string.o vsprintf.o cmdline.o \
> sha1.o chacha20.o md5.o irq_regs.o argv_split.o \
> flex_proportions.o ratelimit.o show_mem.o \
> is_single_threaded.o plist.o decompress.o kobject_uevent.o \
> - earlycpio.o seq_buf.o nmi_backtrace.o nodemask.o win_minmax.o
> + earlycpio.o seq_buf.o siphash.o \
> + nmi_backtrace.o nodemask.o win_minmax.o
>
> lib-$(CONFIG_MMU) += ioremap.o
> lib-$(CONFIG_SMP) += cpumask.o
> @@ -44,7 +45,7 @@ obj-$(CONFIG_TEST_HEXDUMP) += test_hexdump.o
> obj-y += kstrtox.o
> obj-$(CONFIG_TEST_BPF) += test_bpf.o
> obj-$(CONFIG_TEST_FIRMWARE) += test_firmware.o
> -obj-$(CONFIG_TEST_HASH) += test_hash.o
> +obj-$(CONFIG_TEST_HASH) += test_hash.o test_siphash.o
> obj-$(CONFIG_TEST_KASAN) += test_kasan.o
> obj-$(CONFIG_TEST_KSTRTOX) += test-kstrtox.o
> obj-$(CONFIG_TEST_LKM) += test_module.o
> diff --git a/lib/siphash.c b/lib/siphash.c
> new file mode 100644
> index 000000000000..32acdc26234f
> --- /dev/null
> +++ b/lib/siphash.c
> @@ -0,0 +1,153 @@
> +/* Copyright (C) 2015-2016 Jason A. Donenfeld <Jason@zx2c4.com>
> + * Copyright (C) 2012-2014 Jean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com>
> + * Copyright (C) 2012-2014 Daniel J. Bernstein <djb@cr.yp.to>
> + *
> + * This file is provided under a dual BSD/GPLv2 license.
> + *
> + * SipHash: a fast short-input PRF
> + * https://131002.net/siphash/
> + */
> +
> +#include <linux/siphash.h>
> +#include <linux/kernel.h>
> +#include <asm/unaligned.h>
> +
> +#if defined(CONFIG_DCACHE_WORD_ACCESS) && BITS_PER_LONG == 64
> +#include <linux/dcache.h>
> +#include <asm/word-at-a-time.h>
> +#endif
> +
> +#define SIPROUND \
> + do { \
> + v0 += v1; v1 = rol64(v1, 13); v1 ^= v0; v0 = rol64(v0, 32); \
> + v2 += v3; v3 = rol64(v3, 16); v3 ^= v2; \
> + v0 += v3; v3 = rol64(v3, 21); v3 ^= v0; \
> + v2 += v1; v1 = rol64(v1, 17); v1 ^= v2; v2 = rol64(v2, 32); \
> + } while(0)
> +
> +static inline u16 le16_to_cpuvp(const void *p)
> +{
> + return le16_to_cpup(p);
> +}
> +static inline u32 le32_to_cpuvp(const void *p)
> +{
> + return le32_to_cpup(p);
> +}
> +static inline u64 le64_to_cpuvp(const void *p)
> +{
> + return le64_to_cpup(p);
> +}
> +
> +/**
> + * siphash24 - compute 64-bit siphash24 PRF value
> + * @data: buffer to hash, must be aligned to SIPHASH24_ALIGNMENT
> + * @size: size of @data
> + * @key: key buffer of size SIPHASH24_KEY_LEN, must be aligned to SIPHASH24_ALIGNMENT
> + */
> +u64 siphash24(const u8 *data, size_t len, const u8 key[SIPHASH24_KEY_LEN])
> +{
> + u64 v0 = 0x736f6d6570736575ULL;
> + u64 v1 = 0x646f72616e646f6dULL;
> + u64 v2 = 0x6c7967656e657261ULL;
> + u64 v3 = 0x7465646279746573ULL;
> + u64 b = ((u64)len) << 56;
> + u64 k0 = le64_to_cpuvp(key);
> + u64 k1 = le64_to_cpuvp(key + sizeof(u64));
> + u64 m;
> + const u8 *end = data + len - (len % sizeof(u64));
> + const u8 left = len & (sizeof(u64) - 1);
> + v3 ^= k1;
> + v2 ^= k0;
> + v1 ^= k1;
> + v0 ^= k0;
> + for (; data != end; data += sizeof(u64)) {
> + m = le64_to_cpuvp(data);
> + v3 ^= m;
> + SIPROUND;
> + SIPROUND;
> + v0 ^= m;
> + }
> +#if defined(CONFIG_DCACHE_WORD_ACCESS) && BITS_PER_LONG == 64
> + if (left)
> + b |= le64_to_cpu((__force __le64)(load_unaligned_zeropad(data) & bytemask_from_count(left)));
> +#else
> + switch (left) {
> + case 7: b |= ((u64)data[6]) << 48;
> + case 6: b |= ((u64)data[5]) << 40;
> + case 5: b |= ((u64)data[4]) << 32;
> + case 4: b |= le32_to_cpuvp(data); break;
> + case 3: b |= ((u64)data[2]) << 16;
> + case 2: b |= le16_to_cpuvp(data); break;
> + case 1: b |= data[0];
> + }
> +#endif
> + v3 ^= b;
> + SIPROUND;
> + SIPROUND;
> + v0 ^= b;
> + v2 ^= 0xff;
> + SIPROUND;
> + SIPROUND;
> + SIPROUND;
> + SIPROUND;
> + return (v0 ^ v1) ^ (v2 ^ v3);
> +}
> +EXPORT_SYMBOL(siphash24);
> +
> +#ifndef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> +/**
> + * siphash24 - compute 64-bit siphash24 PRF value, without alignment requirements
> + * @data: buffer to hash
> + * @size: size of @data
> + * @key: key buffer of size SIPHASH24_KEY_LEN
> + */
> +u64 siphash24_unaligned(const u8 *data, size_t len, const u8 key[SIPHASH24_KEY_LEN])
> +{
> + u64 v0 = 0x736f6d6570736575ULL;
> + u64 v1 = 0x646f72616e646f6dULL;
> + u64 v2 = 0x6c7967656e657261ULL;
> + u64 v3 = 0x7465646279746573ULL;
> + u64 b = ((u64)len) << 56;
> + u64 k0 = get_unaligned_le64(key);
> + u64 k1 = get_unaligned_le64(key + sizeof(u64));
> + u64 m;
> + const u8 *end = data + len - (len % sizeof(u64));
> + const u8 left = len & (sizeof(u64) - 1);
> + v3 ^= k1;
> + v2 ^= k0;
> + v1 ^= k1;
> + v0 ^= k0;
> + for (; data != end; data += sizeof(u64)) {
> + m = get_unaligned_le64(data);
> + v3 ^= m;
> + SIPROUND;
> + SIPROUND;
> + v0 ^= m;
> + }
> +#if defined(CONFIG_DCACHE_WORD_ACCESS) && BITS_PER_LONG == 64
> + if (left)
> + b |= le64_to_cpu((__force __le64)(load_unaligned_zeropad(data) & bytemask_from_count(left)));
> +#else
> + switch (left) {
> + case 7: b |= ((u64)data[6]) << 48;
> + case 6: b |= ((u64)data[5]) << 40;
> + case 5: b |= ((u64)data[4]) << 32;
> + case 4: b |= get_unaligned_le32(data); break;
> + case 3: b |= ((u64)data[2]) << 16;
> + case 2: b |= get_unaligned_le16(data); break;
> + case 1: b |= data[0];
> + }
> +#endif
> + v3 ^= b;
> + SIPROUND;
> + SIPROUND;
> + v0 ^= b;
> + v2 ^= 0xff;
> + SIPROUND;
> + SIPROUND;
> + SIPROUND;
> + SIPROUND;
> + return (v0 ^ v1) ^ (v2 ^ v3);
> +}
> +EXPORT_SYMBOL(siphash24_unaligned);
> +#endif
> diff --git a/lib/test_siphash.c b/lib/test_siphash.c
> new file mode 100644
> index 000000000000..69ac94dec366
> --- /dev/null
> +++ b/lib/test_siphash.c
> @@ -0,0 +1,85 @@
> +/* Test cases for siphash.c
> + *
> + * Copyright (C) 2015-2016 Jason A. Donenfeld <Jason@zx2c4.com>
> + *
> + * This file is provided under a dual BSD/GPLv2 license.
> + *
> + * SipHash: a fast short-input PRF
> + * https://131002.net/siphash/
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include <linux/siphash.h>
> +#include <linux/kernel.h>
> +#include <linux/string.h>
> +#include <linux/errno.h>
> +#include <linux/module.h>
> +
> +/* Test vectors taken from official reference source available at:
> + * https://131002.net/siphash/siphash24.c
> + */
> +static const u64 test_vectors[64] = {
> + 0x726fdb47dd0e0e31ULL, 0x74f839c593dc67fdULL, 0x0d6c8009d9a94f5aULL,
> + 0x85676696d7fb7e2dULL, 0xcf2794e0277187b7ULL, 0x18765564cd99a68dULL,
> + 0xcbc9466e58fee3ceULL, 0xab0200f58b01d137ULL, 0x93f5f5799a932462ULL,
> + 0x9e0082df0ba9e4b0ULL, 0x7a5dbbc594ddb9f3ULL, 0xf4b32f46226bada7ULL,
> + 0x751e8fbc860ee5fbULL, 0x14ea5627c0843d90ULL, 0xf723ca908e7af2eeULL,
> + 0xa129ca6149be45e5ULL, 0x3f2acc7f57c29bdbULL, 0x699ae9f52cbe4794ULL,
> + 0x4bc1b3f0968dd39cULL, 0xbb6dc91da77961bdULL, 0xbed65cf21aa2ee98ULL,
> + 0xd0f2cbb02e3b67c7ULL, 0x93536795e3a33e88ULL, 0xa80c038ccd5ccec8ULL,
> + 0xb8ad50c6f649af94ULL, 0xbce192de8a85b8eaULL, 0x17d835b85bbb15f3ULL,
> + 0x2f2e6163076bcfadULL, 0xde4daaaca71dc9a5ULL, 0xa6a2506687956571ULL,
> + 0xad87a3535c49ef28ULL, 0x32d892fad841c342ULL, 0x7127512f72f27cceULL,
> + 0xa7f32346f95978e3ULL, 0x12e0b01abb051238ULL, 0x15e034d40fa197aeULL,
> + 0x314dffbe0815a3b4ULL, 0x027990f029623981ULL, 0xcadcd4e59ef40c4dULL,
> + 0x9abfd8766a33735cULL, 0x0e3ea96b5304a7d0ULL, 0xad0c42d6fc585992ULL,
> + 0x187306c89bc215a9ULL, 0xd4a60abcf3792b95ULL, 0xf935451de4f21df2ULL,
> + 0xa9538f0419755787ULL, 0xdb9acddff56ca510ULL, 0xd06c98cd5c0975ebULL,
> + 0xe612a3cb9ecba951ULL, 0xc766e62cfcadaf96ULL, 0xee64435a9752fe72ULL,
> + 0xa192d576b245165aULL, 0x0a8787bf8ecb74b2ULL, 0x81b3e73d20b49b6fULL,
> + 0x7fa8220ba3b2eceaULL, 0x245731c13ca42499ULL, 0xb78dbfaf3a8d83bdULL,
> + 0xea1ad565322a1a0bULL, 0x60e61c23a3795013ULL, 0x6606d7e446282b93ULL,
> + 0x6ca4ecb15c5f91e1ULL, 0x9f626da15c9625f3ULL, 0xe51b38608ef25f57ULL,
> + 0x958a324ceb064572ULL
> +};
> +
> +static int __init siphash_test_init(void)
> +{
> + u8 in[64] __aligned(SIPHASH24_ALIGNMENT);
> + u8 k[16] __aligned(SIPHASH24_ALIGNMENT);
> + u8 in_unaligned[65];
> + u8 k_unaligned[65];
> + u8 i;
> + int ret = 0;
> +
> + for (i = 0; i < 16; ++i) {
> + k[i] = i;
> + k_unaligned[i + 1] = i;
> + }
> + for (i = 0; i < 64; ++i) {
> + in[i] = i;
> + in_unaligned[i + 1] = i;
> + if (siphash24(in, i, k) != test_vectors[i]) {
> + pr_info("self-test aligned %u: FAIL\n", i + 1);
> + ret = -EINVAL;
> + }
> + if (siphash24_unaligned(in_unaligned + 1, i, k_unaligned + 1) != test_vectors[i]) {
> + pr_info("self-test unaligned %u: FAIL\n", i + 1);
> + ret = -EINVAL;
> + }
> + }
> + if (!ret)
> + pr_info("self-tests: pass\n");
> + return ret;
> +}
> +
> +static void __exit siphash_test_exit(void)
> +{
> +}
> +
> +module_init(siphash_test_init);
> +module_exit(siphash_test_exit);
> +
> +MODULE_AUTHOR("Jason A. Donenfeld <Jason@zx2c4.com>");
> +MODULE_LICENSE("Dual BSD/GPL");
> --
> 2.11.0
>
^ permalink raw reply
* Re: [PATCH] perf tools: ignore zombie process for user profile
From: acme @ 2016-12-14 19:13 UTC (permalink / raw)
To: Liang, Kan
Cc: Jiri Olsa, linux-kernel@vger.kernel.org, mingo@redhat.com,
peterz@infradead.org, jolsa@kernel.org, Hunter, Adrian,
andi@firstfloor.org
In-Reply-To: <37D7C6CF3E00A74B8858931C1DB2F0775367F8F6@SHSMSX103.ccr.corp.intel.com>
Em Wed, Dec 14, 2016 at 06:26:02PM +0000, Liang, Kan escreveu:
> > On Wed, Dec 14, 2016 at 12:48:05PM -0500, kan.liang@intel.com wrote:
> > > From: Kan Liang <kan.liang@intel.com>
> > > Zombie process is dead process. It is meaningless to profile it.
> > > It's better to ignore it for user profile.
> > I recently posted different patch for same issue:
> > http://marc.info/?l=linux-kernel&m=148153895827359&w=2
> The change as below make me confuse.
> + /* The system wide setup does not work with threads. */
> + if (!evsel->system_wide)
> + return false;
> It looks the meaning of the comments is inconsistent with the code.
> Your original patch doesn't work well with the issue.
> But if I change the above code as below, the issue is fixed.
> if (evsel->system_wide)
> return false;
yeah, Namhyung noticed that, Jiri sent a fixed patch, I have it already
in my perf/core branch.
- Arnaldo
^ permalink raw reply
* Re: [kernel-hardening] Re: [PATCH 4/3] random: use siphash24 instead of md5 for get_random_int/long
From: Jason A. Donenfeld @ 2016-12-14 19:12 UTC (permalink / raw)
To: kernel-hardening, Theodore Ts'o, Jason A. Donenfeld, Netdev,
David Miller, Linus Torvalds, LKML, George Spelvin, Scott Bauer,
Andi Kleen, Andy Lutomirski, Greg KH, Eric Biggers,
Linux Crypto Mailing List, Jean-Philippe Aumasson
In-Reply-To: <20161214163731.luj2dzmnihcuhn5p@thunk.org>
Hi again,
On Wed, Dec 14, 2016 at 5:37 PM, Theodore Ts'o <tytso@mit.edu> wrote:
> [ 3.606139] random benchmark!!
> [ 3.606276] get_random_int # cycles: 326578
> [ 3.606317] get_random_int_new # cycles: 95438
> [ 3.607423] get_random_bytes # cycles: 2653388
Looks to me like my siphash implementation is much faster for
get_random_long, and more or less tied for get_random_int:
[ 1.729370] random benchmark!!
[ 1.729710] get_random_long # cycles: 349771
[ 1.730128] get_random_long_chacha # cycles: 359660
[ 1.730457] get_random_long_siphash # cycles: 94255
[ 1.731307] get_random_bytes # cycles: 1354894
[ 1.731707] get_random_int # cycles: 305640
[ 1.732095] get_random_int_chacha # cycles: 80726
[ 1.732425] get_random_int_siphash # cycles: 94265
[ 1.733278] get_random_bytes # cycles: 1315873
Given the increasing usage of get_random_long for ASLR and related, I
think this makes the siphash approach worth pursuing. The chacha
approach is also not significantly different from the md5 approach in
terms of speed for get_rand_long. Additionally, since siphash is a
PRF, I think this opens up a big window for optimizing it even
further.
Benchmark here:
https://git.zx2c4.com/linux-dev/commit/?h=rng-bench
Jason
^ permalink raw reply
* RE: [PATCH v3 2/2] FPGA: Add TS-7300 FPGA manager
From: Hartley Sweeten @ 2016-12-14 18:58 UTC (permalink / raw)
To: Florian Fainelli, Moritz Fischer
Cc: Linux Kernel Mailing List, linux-arm-kernel, Alan Tull,
Russell King, rmallon@gmail.com, linux-fpga@vger.kernel.org
In-Reply-To: <cf772070-73d9-fa07-b2b9-e0038832b7be@gmail.com>
On Wednesday, December 14, 2016 11:55 AM, Florian Fainelli wrote:
> My understanding is that, yes, this triggers the final write. You are
> right that ts73xx_fpga_write() can be called multiple times. It sounds
> like what my write_complete function does right now is just return that
> we successfully completed the bistream write, but this snippet that you
> are quoting should actually be moved into write_complete.
Florian,
I'm in the process of getting a TS-7300 board so I can help test this. Hopefully
I will have it by next week.
Hartley
^ permalink raw reply
* Re: [kernel-hardening] [PATCH 3/4] Make static usermode helper binaries constant
From: Greg KH @ 2016-12-14 19:11 UTC (permalink / raw)
To: kernel-hardening; +Cc: linux-kernel
In-Reply-To: <20161214185052.GC4939@kroah.com>
On Wed, Dec 14, 2016 at 10:50:52AM -0800, Greg KH wrote:
>
> There are a number of usermode helper binaries that are "hard coded" in
> the kernel today, so mark them as "const" to make it harder for someone
> to change where the variables point to.
>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> drivers/macintosh/windfarm_core.c | 2 +-
> drivers/net/hamradio/baycom_epp.c | 2 +-
> drivers/pnp/pnpbios/core.c | 5 +++--
> drivers/staging/greybus/svc_watchdog.c | 4 ++--
> drivers/staging/rtl8192e/rtl8192e/rtl_dm.c | 6 +++---
> fs/nfsd/nfs4layouts.c | 6 ++++--
> security/keys/request_key.c | 7 ++++---
> 7 files changed, 18 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/macintosh/windfarm_core.c b/drivers/macintosh/windfarm_core.c
> index 465d770ab0bb..1b317cbb73cf 100644
> --- a/drivers/macintosh/windfarm_core.c
> +++ b/drivers/macintosh/windfarm_core.c
> @@ -74,7 +74,7 @@ static inline void wf_notify(int event, void *param)
>
> static int wf_critical_overtemp(void)
> {
> - static char * critical_overtemp_path = "/sbin/critical_overtemp";
> + static const char * critical_overtemp_path = "/sbin/critical_overtemp";
> char *argv[] = { critical_overtemp_path, NULL };
> static char *envp[] = { "HOME=/",
> "TERM=linux",
Doh, minor compiler warnings for this one, and others in this patch,
I'll fix them up...
^ permalink raw reply
* Applied "ASoC: dwc: Fix PIO mode initialization" to the asoc tree
From: Mark Brown @ 2016-12-14 18:03 UTC (permalink / raw)
To: Jose Abreu
Cc: Jose Abreu, Mark Brown, alsa-devel, Liam Girdwood, linux-kernel,
Takashi Iwai, Mark Brown, Carlos Palminha
In-Reply-To: <1ded72e27be422c2591fb252ea30b87cdbb7e7b1.1481626830.git.joabreu@synopsys.com>
The patch
ASoC: dwc: Fix PIO mode initialization
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 6fce983f9b3ef51d47e647b2cff15049ef803781 Mon Sep 17 00:00:00 2001
From: Jose Abreu <Jose.Abreu@synopsys.com>
Date: Tue, 13 Dec 2016 11:03:49 +0000
Subject: [PATCH] ASoC: dwc: Fix PIO mode initialization
We can no longer rely on the return value of
devm_snd_dmaengine_pcm_register(...) to check if the DMA
handle is declared in the DT.
Previously this check activated PIO mode but currently
dma_request_chan returns either a valid channel or -EPROBE_DEFER.
In order to activate PIO mode check instead if the interrupt
line is declared. This reflects better what is documented in
the DT bindings (see Documentation/devicetree/bindings/sound/
designware-i2s.txt).
Also, initialize use_pio variable which was never being set
causing PIO mode to never work.
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/dwc/designware_i2s.c | 25 +++++++++++--------------
1 file changed, 11 insertions(+), 14 deletions(-)
diff --git a/sound/soc/dwc/designware_i2s.c b/sound/soc/dwc/designware_i2s.c
index 2998954a1c74..bdf8398cbc81 100644
--- a/sound/soc/dwc/designware_i2s.c
+++ b/sound/soc/dwc/designware_i2s.c
@@ -681,22 +681,19 @@ static int dw_i2s_probe(struct platform_device *pdev)
}
if (!pdata) {
- ret = devm_snd_dmaengine_pcm_register(&pdev->dev, NULL, 0);
- if (ret == -EPROBE_DEFER) {
- dev_err(&pdev->dev,
- "failed to register PCM, deferring probe\n");
- return ret;
- } else if (ret) {
- dev_err(&pdev->dev,
- "Could not register DMA PCM: %d\n"
- "falling back to PIO mode\n", ret);
+ if (irq >= 0) {
ret = dw_pcm_register(pdev);
- if (ret) {
- dev_err(&pdev->dev,
- "Could not register PIO PCM: %d\n",
+ dev->use_pio = true;
+ } else {
+ ret = devm_snd_dmaengine_pcm_register(&pdev->dev, NULL,
+ 0);
+ dev->use_pio = false;
+ }
+
+ if (ret) {
+ dev_err(&pdev->dev, "could not register pcm: %d\n",
ret);
- goto err_clk_disable;
- }
+ goto err_clk_disable;
}
}
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v3 2/2] FPGA: Add TS-7300 FPGA manager
From: Florian Fainelli @ 2016-12-14 19:08 UTC (permalink / raw)
To: Hartley Sweeten, Moritz Fischer
Cc: Linux Kernel Mailing List, linux-arm-kernel, Alan Tull,
Russell King, rmallon@gmail.com, linux-fpga@vger.kernel.org
In-Reply-To: <SN1PR0101MB1565A30EFE8AFEB319B84124D09A0@SN1PR0101MB1565.prod.exchangelabs.com>
On 12/14/2016 10:58 AM, Hartley Sweeten wrote:
> On Wednesday, December 14, 2016 11:55 AM, Florian Fainelli wrote:
>> My understanding is that, yes, this triggers the final write. You are
>> right that ts73xx_fpga_write() can be called multiple times. It sounds
>> like what my write_complete function does right now is just return that
>> we successfully completed the bistream write, but this snippet that you
>> are quoting should actually be moved into write_complete.
>
> Florian,
>
> I'm in the process of getting a TS-7300 board so I can help test this. Hopefully
> I will have it by next week.
Great! I got a few things on my list that have not been submitted yet:
- tmp124 support through drivers/hwmon/lm70.c
- specific memcpy_{from,to}io accessors for ethoc from the FPGA
- serial port support for the UARTs from the FPGA
And some other things that are giving me issues at the moment, like
SPI_3WIRE support for spi-ep93xx so I can configure the tmp124 to send
alarms/have temperature thresholds.
My branch is here:
https://github.com/ffainelli/linux/tree/ts72xx
Cheers
--
Florian
^ permalink raw reply
* Re: [v2] net:ethernet:cavium:octeon:octeon_mgmt: Handle return NULL error from devm_ioremap
From: arvind Yadav @ 2016-12-14 19:05 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, linux-kernel
In-Reply-To: <262b3fdb-754b-a1f1-bd6a-3b15d72063b4@gmail.com>
Hi,
As per your suggestion, I have change the subject.
Thanks
On Thursday 15 December 2016 12:24 AM, Florian Fainelli wrote:
> On 12/14/2016 10:39 AM, arvind Yadav wrote:
>> Hi David,
>>
>> I have gave my comment.
>>
>> Thanks
>> Arvind
>>
>> On Wednesday 14 December 2016 11:44 PM, David Daney wrote:
>>> On 12/14/2016 10:06 AM, arvind Yadav wrote:
>>>> Yes, I have seen this error. We have a device with very less memory.
>>>> Basically it's OMAP2 board. We have to port Android L on this.
>>>> It's has 3.10 kernel version. In this device, we were getting Page
>>>> allocation failure.
>>> This makes absolutely no sense to me. OCTEON is a mips64 SoC with a
>>> ton of memory where ioremap can never fail, and it doesn't run
>>> Android, and you are talking about OMAP2.
>> -I just gave as example where i have seen ioremap issue.
>> Please don't relate. I know, Now it will not fail. ioremap will through
>> NULL on failure. We should catch this error. Even other driver of MIPS
>> soc is having same check. It's just check which will not impact any
>> functionality or performance of this driver. It will avoid NULL pointer
>> error. We know, if function is returning any error. we should catch.
> Your patch subject should also be changed to insert spaces between
> semicolon, so this would be:
>
> net: ethernet: cavium: octeon: octeon_mgmt:
^ permalink raw reply
* [v3] net: ethernet: cavium: octeon: octeon_mgmt: Handle return NULL error from devm_ioremap
From: Arvind Yadav @ 2016-12-14 19:03 UTC (permalink / raw)
To: peter.chen, fw, david.daney, f.fainelli; +Cc: netdev, linux-kernel
Here, If devm_ioremap will fail. It will return NULL.
Kernel can run into a NULL-pointer dereference.
This error check will avoid NULL pointer dereference.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
drivers/net/ethernet/cavium/octeon/octeon_mgmt.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/cavium/octeon/octeon_mgmt.c b/drivers/net/ethernet/cavium/octeon/octeon_mgmt.c
index 4ab404f..33c2fec 100644
--- a/drivers/net/ethernet/cavium/octeon/octeon_mgmt.c
+++ b/drivers/net/ethernet/cavium/octeon/octeon_mgmt.c
@@ -1479,6 +1479,12 @@ static int octeon_mgmt_probe(struct platform_device *pdev)
p->agl = (u64)devm_ioremap(&pdev->dev, p->agl_phys, p->agl_size);
p->agl_prt_ctl = (u64)devm_ioremap(&pdev->dev, p->agl_prt_ctl_phys,
p->agl_prt_ctl_size);
+ if (!p->mix || !p->agl || !p->agl_prt_ctl) {
+ dev_err(&pdev->dev, "failed to map I/O memory\n");
+ result = -ENOMEM;
+ goto err;
+ }
+
spin_lock_init(&p->lock);
skb_queue_head_init(&p->tx_list);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 1/3] mm, trace: extract COMPACTION_STATUS and ZONE_TYPE to a common header
From: Michal Hocko @ 2016-12-14 19:02 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, Andrew Morton, Vlastimil Babka, David Rientjes,
Johannes Weiner, linux-mm, LKML
In-Reply-To: <201612150127.1D06IAf6%fengguang.wu@intel.com>
On Thu 15-12-16 01:32:06, kbuild test robot wrote:
> Hi Michal,
>
> [auto build test ERROR on tip/perf/core]
> [also build test ERROR on v4.9 next-20161214]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Michal-Hocko/mm-oom-add-oom-detection-tracepoints/20161214-231225
> config: x86_64-randconfig-s2-12142134 (attached as .config)
> compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
> All error/warnings (new ones prefixed by >>):
>
> In file included from include/trace/trace_events.h:361,
> from include/trace/define_trace.h:95,
> from include/trace/events/compaction.h:356,
> from mm/compaction.c:43:
> include/trace/events/compaction.h: In function 'trace_raw_output_mm_compaction_end':
> >> include/trace/events/compaction.h:134: error: expected expression before ',' token
> include/trace/events/compaction.h: In function 'trace_raw_output_mm_compaction_suitable_template':
> include/trace/events/compaction.h:195: error: expected expression before ',' token
> >> include/trace/events/compaction.h:195: warning: missing braces around initializer
> include/trace/events/compaction.h:195: warning: (near initialization for 'symbols[0]')
> >> include/trace/events/compaction.h:195: error: initializer element is not constant
> include/trace/events/compaction.h:195: error: (near initialization for 'symbols[0].mask')
Interesting. I am pretty sure that my config battery has
CONFIG_COMPACTION=n. Not sure which part of your config made a change.
Anyway, I've added to my collection. And with the below diff it passes
all my configs.
---
>From 921bf07b8684ded5f076904cc6baa875b52c3a1e Mon Sep 17 00:00:00 2001
From: Michal Hocko <mhocko@suse.com>
Date: Wed, 14 Dec 2016 18:56:44 +0100
Subject: [PATCH] fold me "mm, trace: extract COMPACTION_STATUS and ZONE_TYPE
to a common header"
0-day has reported:
In file included from include/trace/trace_events.h:361,
from include/trace/define_trace.h:95,
from include/trace/events/compaction.h:356,
from mm/compaction.c:43:
include/trace/events/compaction.h: In function 'trace_raw_output_mm_compaction_end':
>> include/trace/events/compaction.h:134: error: expected expression before ',' token
include/trace/events/compaction.h: In function 'trace_raw_output_mm_compaction_suitable_template':
include/trace/events/compaction.h:195: error: expected expression before ',' token
>> include/trace/events/compaction.h:195: warning: missing braces around initializer
include/trace/events/compaction.h:195: warning: (near initialization for 'symbols[0]')
>> include/trace/events/compaction.h:195: error: initializer element is not constant
include/trace/events/compaction.h:195: error: (near initialization for 'symbols[0].mask')
CONFIG_COMPACTION=n so COMPACTION_STATUS is not defined properly.
Signed-off-by: Michal Hocko <mhocko@suse.com>
---
include/trace/events/compaction.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/trace/events/compaction.h b/include/trace/events/compaction.h
index 2334faa56323..0a18ab6483ff 100644
--- a/include/trace/events/compaction.h
+++ b/include/trace/events/compaction.h
@@ -131,6 +131,7 @@ TRACE_EVENT(mm_compaction_begin,
__entry->sync ? "sync" : "async")
);
+#ifdef CONFIG_COMPACTION
TRACE_EVENT(mm_compaction_end,
TP_PROTO(unsigned long zone_start, unsigned long migrate_pfn,
unsigned long free_pfn, unsigned long zone_end, bool sync,
@@ -164,6 +165,7 @@ TRACE_EVENT(mm_compaction_end,
__entry->sync ? "sync" : "async",
__print_symbolic(__entry->status, COMPACTION_STATUS))
);
+#endif
TRACE_EVENT(mm_compaction_try_to_compact_pages,
@@ -192,6 +194,7 @@ TRACE_EVENT(mm_compaction_try_to_compact_pages,
__entry->prio)
);
+#ifdef CONFIG_COMPACTION
DECLARE_EVENT_CLASS(mm_compaction_suitable_template,
TP_PROTO(struct zone *zone,
@@ -239,7 +242,6 @@ DEFINE_EVENT(mm_compaction_suitable_template, mm_compaction_suitable,
TP_ARGS(zone, order, ret)
);
-#ifdef CONFIG_COMPACTION
DECLARE_EVENT_CLASS(mm_compaction_defer_template,
TP_PROTO(struct zone *zone, int order),
--
2.10.2
--
Michal Hocko
SUSE Labs
^ permalink raw reply related
* Re: Question about regulator API
From: Mark Brown @ 2016-12-14 18:14 UTC (permalink / raw)
To: Harald Geyer; +Cc: Liam Girdwood, linux-kernel
In-Reply-To: <E1cHAvO-0000Qg-Hv@stardust.g4.wien.funkfeuer.at>
[-- Attachment #1: Type: text/plain, Size: 2880 bytes --]
On Wed, Dec 14, 2016 at 03:52:54PM +0100, Harald Geyer wrote:
> Thus the following constraints should be met:
> * When user space asks the driver to read a device, it needs to "claim"
> the supply and ensure that it has been up for at least 2 seconds
> before proceeding to read the HW. The supply would be "locked" enabled.
> (I think this is standard regulator API.)
> * When HW failure is detected, the driver needs to tell the supply to
> turn off for at least 2 seconds, wait for all other devices to release
> the supply so it can actually be turned off, then wait for the off period,
> then start over again.
> (This is easy only with getting the supply exclusively.)
You need to use a notification to figure out when the supply is actually
off.
> * It should be possible to read multiple devices quickly when everything
> is okay and working. (Having 6 2-second delays accumulate would be quite
> annoying.)
> (This won't work with exclusive supply usage.)
Similarly using a notification to discover when the supply is on would
help here.
> * Optionally: If all devices are idle the supply would be enabled if short
> response time is desired, but disabled if power saving is desired.
>
> Can this somehow be solved with the existing API?
> If not, do you think it would be reasonable/possible to extend the API
> to cover situations like the one described above?
This doesn't feel like a regulator API problem exactly, a lot of what
you're talking about here seems like you really need the devices to
coopereate with each other and know what they're doing in order to work
well together. From a regulator API point of view my first thought is
to use notifications to hook into the actual power on/off transitions
and then expressing the bit where the devices all work together at a
higher level. It may be that a lot of that higher level coordination
just falls out of normal usage patterns do doesn't need explicitly
implementing, assuming the devices are only powered up during reads
anyway. Using regulator_disable_deferred() in the driver may help
grease the wheels in terms of avoiding needless power bounces and
delays - just wait a little while before powering down in case you need
to power up again very soon after.
You'd end up with the devices all ignoring each other but keeping track
of when the supply was last enabled and disabled and individually
keeping timers to make sure that the needed delays are taken care of.
Userspace would then turn up and read all the devices, they'd then do
the enables and disables as though they were working alone but
coordinate through the notifications. If device A powered things up
then device B would know the power was already on via the notifications
and when it came on so could take account of that when doing its own
delays.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/3] kvm: svm: Use the hardware provided GPA instead of page walk
From: Brijesh Singh @ 2016-12-14 18:39 UTC (permalink / raw)
To: Paolo Bonzini
Cc: brijesh.singh, kvm, thomas lendacky, rkrcmar, joro, x86,
linux-kernel, mingo, hpa, tglx, bp
In-Reply-To: <ed5a3921-00b0-9214-0767-62585fb6b166@redhat.com>
On 12/14/2016 11:23 AM, Paolo Bonzini wrote:
>
>
> On 14/12/2016 18:07, Brijesh Singh wrote:
>>>
>>
>> Since now we are going to perform multiple conditional checks before
>> concluding that its safe to use HW provided GPA. How about if we add two
>> functions "emulator_is_rep_string_op" and "emulator_is_two_mem_op" into
>> emulator.c and use these functions inside the x86.c to determine if its
>> safe to use HW provided gpa?
>
> Why not export only emulator_can_use_gpa from emulate.c? (So in the end
> leaving emulator_is_string_op in emulate.c was the right thing to do, it
> was just the test that was wrong :)).
>
Actually, I was not sure if putting emulator_can_use_gpa() in emulate.c
was right thing - mainly because emulator.c does not deal with GPA. I
will go with your advice and put it in emulator.c, it makes easy :)
> The patch below is still missing the check for cross-page MMIO. Your
> reference to the BKDG only covers MMCONFIG (sometimes referred to as
> ECAM), not MMIO in general. Doing AND or OR into video memory for
> example is perfectly legal, and I'm fairly sure that some obscure legacy
> software does PUSH/POP into vram as well!
>
>
I used your below code snippet to detect cross-page MMIO access. After
applying these changes cross-page MMIO read/write unit test is passing
just fine. I will include it in patch.
> Actually there is a nice trick you can do to support cross-page
> MMIO access detection:
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 37cd31645d45..754d251dc611 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4549,6 +4549,7 @@ static int emulator_read_write_onepage(unsigned
long addr, void *val,
*/
if (vcpu->arch.gpa_available &&
!emulator_can_use_hw_gpa(ctxt) &&
+ (addr & ~PAGE_MASK) == (exception->address & ~PAGE_MASK) &&
vcpu_is_mmio_gpa(vcpu, addr, exception->address, write)) {
gpa = exception->address;
goto mmio;
^ permalink raw reply related
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