Re: dangers of bots on the mailing lists was Re: divide error in ___bpf_prog_run

On Wed, Jan 17, 2018 at 04:21:13PM -0800, Alexei Starovoitov wrote: > > If syzkaller can only test one tree than linux-next should be the one. Well, there's been some controversy about that. The problem is that it's often not clear if this is long-standing bug, or a bug which is in a particular

Re: dangers of bots on the mailing lists was Re: divide error in ___bpf_prog_run

On Wed, Jan 17, 2018 at 12:09:18PM +0100, Dmitry Vyukov wrote: > On Wed, Jan 17, 2018 at 10:49 AM, Daniel Borkmann > wrote: > > Don't know if there's such a possibility, but it would be nice if we could > > target fuzzing for specific subsystems in related subtrees directly

Re: [PATCH 13/38] ext4: Define usercopy region in ext4_inode_cache slab cache

On Wed, Jan 10, 2018 at 06:02:45PM -0800, Kees Cook wrote: > The ext4 symlink pathnames, stored in struct ext4_inode_info.i_data > and therefore contained in the ext4_inode_cache slab cache, need > to be copied to/from userspace. Symlink operations to/from userspace aren't common or in the hot

Re: [PATCH v5 next 1/5] modules:capabilities: add request_module_cap()

On Wed, Nov 29, 2017 at 11:28:52AM -0600, Serge E. Hallyn wrote: > > Just to be clear, module loading requires - and must always continue to > require - CAP_SYS_MODULE against the initial user namespace. Containers > in user namespaces do not have that. > > I don't believe anyone has ever

Re: [PATCH v5 next 1/5] modules:capabilities: add request_module_cap()

On Wed, Nov 29, 2017 at 10:58:16AM -0500, David Miller wrote: > That's not what we're talking about. > > We're talking about making sure that loading "ppp.ko" really gets > ppp.ko rather than some_other_module.ko renamed to ppp.ko via some > other mechanism. Right, and the best solution to this

Re: [PATCH v5 next 1/5] modules:capabilities: add request_module_cap()

On Wed, Nov 29, 2017 at 09:50:14AM -0500, David Miller wrote: > From: Alan Cox > Date: Wed, 29 Nov 2017 13:46:12 + > > > I really don't care what the module loading rules end up with and > > whether we add CAP_SYS_YET_ANOTHER_MEANINGLESS_FLAG but what is > >

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 07:08:37PM +0100, Hannes Frederic Sowa wrote: > I wasn't concerned about performance but more about DoS resilience. I > wonder how safe half md4 actually is in terms of allowing users to > generate long hash chains in the filesystem (in terms of length > extension attacks

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 05:16:47PM +0100, Jason A. Donenfeld wrote: > Could you offer a bit of advice on how to manage dependencies between > patchsets during merge windows? I'm a bit new to the process. > > Specifically, we how have 4 parts: > 1. add siphash, and use it for some networking code.

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 07:03:29AM +0100, Jason A. Donenfeld wrote: > I find this compelling. We'll have one csprng for both > get_random_int/long and for /dev/urandom, and we'll be able to update > that silly warning on the comment of get_random_int/long to read > "gives output of either rdrand

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 02:10:33PM +0100, Jason A. Donenfeld wrote: > On Thu, Dec 22, 2016 at 1:47 PM, Hannes Frederic Sowa > wrote: > > following up on what appears to be a random subject: ;) > > > > IIRC, ext4 code by default still uses half_md4 for hashing of

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 03:49:39AM +0100, Jason A. Donenfeld wrote: > > Funny -- while you guys were sending this back & forth, I was writing > my reply to Andy which essentially arrives at the same conclusion. > Given that we're all arriving to the same thing, and that Ted shot in > this

Re: HalfSipHash Acceptable Usage

On Wed, Dec 21, 2016 at 01:37:51PM -0500, George Spelvin wrote: > SipHash annihilates the competition on 64-bit superscalar hardware. > SipHash dominates the field on 64-bit in-order hardware. > SipHash wins easily on 32-bit hardware *with enough registers*. > On register-starved 32-bit machines,

Re: HalfSipHash Acceptable Usage

On Mon, Dec 19, 2016 at 06:32:44PM +0100, Jason A. Donenfeld wrote: > 1) Anything that requires actual long-term security will use > SipHash2-4, with the 64-bit output and the 128-bit key. This includes > things like TCP sequence numbers. This seems pretty uncontroversial to > me. Seem okay to

Re: [kernel-hardening] Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

On Fri, Dec 16, 2016 at 09:15:03PM -0500, George Spelvin wrote: > >> - Ted, Andy Lutorminski and I will try to figure out a construction of > >> get_random_long() that we all like. We don't have to find the most optimal solution right away; we can approach this incrementally, after all. So

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

On Fri, Dec 16, 2016 at 03:17:39PM -0500, George Spelvin wrote: > > That's a nice analysis. Might one conclude from that that hsiphash is > > not useful for our purposes? Or does it still remain useful for > > network facing code? > > I think for attacks where the threat is a DoS, it's usable.

Re: "virtio-net: enable multiqueue by default" in linux-next breaks networking on GCE

On Wed, Dec 14, 2016 at 12:24:43PM +0800, Wei Xu wrote: > > BTW, although this is a guest issue, is there anyway to view the GCE > host kernel or qemu(if it is) version? No, there isn't, as far as I know. - Ted

Re: [PATCH 4/3] random: use siphash24 instead of md5 for get_random_int/long

On Wed, Dec 14, 2016 at 04:10:37AM +0100, Jason A. Donenfeld wrote: > This duplicates the current algorithm for get_random_int/long, but uses > siphash24 instead. This comes with several benefits. It's certainly > faster and more cryptographically secure than MD5. This patch also > hashes the pid,

Re: "virtio-net: enable multiqueue by default" in linux-next breaks networking on GCE

Jason's patch fixed the issue, so I think we have the proper fix, but to answer your questions: On Wed, Dec 14, 2016 at 01:46:44AM +0800, Wei Xu wrote: > > Q1: > Which distribution are you using for the GCE instance? The test appliance is based on Debian Jessie. > Q2: > Are you running xfs

Re: "virtio-net: enable multiqueue by default" in linux-next breaks networking on GCE

On Tue, Dec 13, 2016 at 11:43:00AM +0800, Jason Wang wrote: > Thanks for reporting this issue. Looks like I blindly set the affinity > instead of queues during probe. Could you please try the following patch to > see if it works? This fixed things, thanks!!

Re: "virtio-net: enable multiqueue by default" in linux-next breaks networking on GCE

On Tue, Dec 13, 2016 at 04:28:17AM +0200, Michael S. Tsirkin wrote: > > That's unfortunate, of course. It could be a hypervisor or > a guest kernel bug. ideas: > - does host have mq capability? how many queues? > - how about # of msix vectors? > - after you send something on tx queues, > are

"virtio-net: enable multiqueue by default" in linux-next breaks networking on GCE

Hi, I was doing a last minute regression test of the ext4 tree before sending a pull request to Linus, which I do using gce-xfstests[1], and I found that using networking was broken on GCE on linux-next. I was using next-20161209, and after bisecting things, I narrowed down the commit which