Re: Linux messages full of `random: get_random_u32 called from`

On Tue, May 01, 2018 at 05:43:17PM -0700, Sultan Alsawaf wrote: > > I've attached what I think is a reasonable stopgap solution until this is > actually fixed. If you're willing to revert the CVE-2018-1108 patches > completely, then I don't think you'll mind using this patch in the meantime. I

Re: [PATCH 2/3] random: Return nbytes filled from hw RNG

On Wed, May 02, 2018 at 09:33:39AM +1000, Tobin C. Harding wrote: > Currently the function get_random_bytes_arch() has return value 'void'. > If the hw RNG fails we currently fall back to using get_random_bytes(). > This defeats the purpose of requesting random material from the hw RNG > in the

Re: [PATCH 2/3] random: Return nbytes filled from hw RNG

On Wed, May 02, 2018 at 09:33:39AM +1000, Tobin C. Harding wrote: > Currently the function get_random_bytes_arch() has return value 'void'. > If the hw RNG fails we currently fall back to using get_random_bytes(). > This defeats the purpose of requesting random material from the hw RNG > in the

Re: [PATCH 1/3] random: Fix whitespace pre random-bytes work

On Wed, May 02, 2018 at 09:33:38AM +1000, Tobin C. Harding wrote: > There are a couple of whitespace issues around the function > get_random_bytes_arch(). In preparation for patching this function > let's clean them up. > > Signed-off-by: Tobin C. Harding Acked-by: Theodore Ts'o

Re: [PATCH 1/3] random: Fix whitespace pre random-bytes work

On Wed, May 02, 2018 at 09:33:38AM +1000, Tobin C. Harding wrote: > There are a couple of whitespace issues around the function > get_random_bytes_arch(). In preparation for patching this function > let's clean them up. > > Signed-off-by: Tobin C. Harding Acked-by: Theodore Ts'o > --- >

Re: Linux messages full of `random: get_random_u32 called from`

On Tue, May 01, 2018 at 05:35:56PM -0500, Justin Forbes wrote: > > I have not reproduced in GCE myself. We did get some confirmation > that removing dracut-fips does make the problem less dire (but I > wouldn't call a 4 minute boot a win, but booting in 4 minutes is > better than not booting at

Re: Linux messages full of `random: get_random_u32 called from`

On Tue, May 01, 2018 at 05:35:56PM -0500, Justin Forbes wrote: > > I have not reproduced in GCE myself. We did get some confirmation > that removing dracut-fips does make the problem less dire (but I > wouldn't call a 4 minute boot a win, but booting in 4 minutes is > better than not booting at

Re: bug-introducing patches

On Tue, May 01, 2018 at 08:00:21PM +, Sasha Levin wrote: > > Yes, linux-next users want it fixed *now* and I completely agree it > should be done that way, but the fix should not be immediately pushed to > Linus as well. I should have linux-head/linux-rc said testers, sorry. The fact that

Re: bug-introducing patches

On Tue, May 01, 2018 at 08:00:21PM +, Sasha Levin wrote: > > Yes, linux-next users want it fixed *now* and I completely agree it > should be done that way, but the fix should not be immediately pushed to > Linus as well. I should have linux-head/linux-rc said testers, sorry. The fact that

Re: bug-introducing patches

ou say that maintainers *need* to do X or Y, that there you are not the only one standing in line putting pressures on maintainers saying they *need* to do something. And quite frankly, I consider keeping people who are nice enough to test linux-next happy to be **far** more important than AUTOSEL.

Re: bug-introducing patches

ou say that maintainers *need* to do X or Y, that there you are not the only one standing in line putting pressures on maintainers saying they *need* to do something. And quite frankly, I consider keeping people who are nice enough to test linux-next happy to be **far** more important than AUTOSEL.

Re: Linux messages full of `random: get_random_u32 called from`

On Tue, May 01, 2018 at 06:52:47AM -0500, Justin Forbes wrote: > > We have also had reports that Fedora users are seeing this on Google > Compute Engine. Can you reproduce this yourself? If so, could you confirm that removing the dracut-fips package makes the problem go away for you? Thanks,

Re: Linux messages full of `random: get_random_u32 called from`

On Tue, May 01, 2018 at 06:52:47AM -0500, Justin Forbes wrote: > > We have also had reports that Fedora users are seeing this on Google > Compute Engine. Can you reproduce this yourself? If so, could you confirm that removing the dracut-fips package makes the problem go away for you? Thanks,

Re: Linux messages full of `random: get_random_u32 called from`

On Sun, Apr 29, 2018 at 09:34:45PM -0700, Sultan Alsawaf wrote: > > What about abusing high-resolution timers to get entropy? Since hrtimers can't > make guarantees down to the nanosecond, there's always a skew between the > requested expiry time and the actual expiry time. > > Please see the

Re: Linux messages full of `random: get_random_u32 called from`

On Sun, Apr 29, 2018 at 09:34:45PM -0700, Sultan Alsawaf wrote: > > What about abusing high-resolution timers to get entropy? Since hrtimers can't > make guarantees down to the nanosecond, there's always a skew between the > requested expiry time and the actual expiry time. > > Please see the

Re: Linux messages full of `random: get_random_u32 called from`

On Sun, Apr 29, 2018 at 07:07:29PM -0400, Dave Jones wrote: > > Why do we continue to print this stuff out when crng_init=1 though ? > > answering my own question, I think.. This is a tristate, and we need it > to be >1 to be quiet, which doesn't happen until.. > > > [ 165.806247] random:

Re: Linux messages full of `random: get_random_u32 called from`

On Sun, Apr 29, 2018 at 07:07:29PM -0400, Dave Jones wrote: > > Why do we continue to print this stuff out when crng_init=1 though ? > > answering my own question, I think.. This is a tristate, and we need it > to be >1 to be quiet, which doesn't happen until.. > > > [ 165.806247] random:

Re: Linux messages full of `random: get_random_u32 called from`

On Sun, Apr 29, 2018 at 03:49:28PM -0700, Sultan Alsawaf wrote: > On Mon, Apr 30, 2018 at 12:43:48AM +0200, Jason A. Donenfeld wrote: > > > - if ((fast_pool->count < 64) && > > > - !time_after(now, fast_pool->last + HZ)) > > > - return; > > > - > > > > I suspect you

Re: Linux messages full of `random: get_random_u32 called from`

On Sun, Apr 29, 2018 at 03:49:28PM -0700, Sultan Alsawaf wrote: > On Mon, Apr 30, 2018 at 12:43:48AM +0200, Jason A. Donenfeld wrote: > > > - if ((fast_pool->count < 64) && > > > - !time_after(now, fast_pool->last + HZ)) > > > - return; > > > - > > > > I suspect you

Re: Linux messages full of `random: get_random_u32 called from`

On Sun, Apr 29, 2018 at 01:20:33PM -0700, Sultan Alsawaf wrote: > On Sun, Apr 29, 2018 at 08:41:01PM +0200, Pavel Machek wrote: > > Umm. No. https://www.youtube.com/watch?v=xneBjc8z0DE > > Okay, but /dev/urandom isn't a solution to this problem because it isn't > usable > until crng init is

Re: Linux messages full of `random: get_random_u32 called from`

On Sun, Apr 29, 2018 at 01:20:33PM -0700, Sultan Alsawaf wrote: > On Sun, Apr 29, 2018 at 08:41:01PM +0200, Pavel Machek wrote: > > Umm. No. https://www.youtube.com/watch?v=xneBjc8z0DE > > Okay, but /dev/urandom isn't a solution to this problem because it isn't > usable > until crng init is

Re: Linux messages full of `random: get_random_u32 called from`

On Sun, Apr 29, 2018 at 11:30:57AM -0700, Sultan Alsawaf wrote: > > Mind you, this laptop has a 45W CPU, so power savings were definitely not > considered in its design. Do you have any machines that can provide enough > boot entropy to satisfy crng init without requiring user-provided entropy?

Re: Linux messages full of `random: get_random_u32 called from`

On Sun, Apr 29, 2018 at 11:30:57AM -0700, Sultan Alsawaf wrote: > > Mind you, this laptop has a 45W CPU, so power savings were definitely not > considered in its design. Do you have any machines that can provide enough > boot entropy to satisfy crng init without requiring user-provided entropy?

[GIT PULL] ext4 fixes for 4.17-rc3

The following changes since commit e40ff213898502d299351cc2fe1e350cd186f0d3: ext4: force revalidation of directory pointer after seekdir(2) (2018-04-01 23:21:03 -0400) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git

[GIT PULL] ext4 fixes for 4.17-rc3

The following changes since commit e40ff213898502d299351cc2fe1e350cd186f0d3: ext4: force revalidation of directory pointer after seekdir(2) (2018-04-01 23:21:03 -0400) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git

Re: Linux messages full of `random: get_random_u32 called from`

On Thu, Apr 26, 2018 at 10:20:44PM -0700, Sultan Alsawaf wrote: > > I noted at least 20,000 mmc interrupts before I intervened in the boot > process to provide entropy > myself. That's just for mmc, so I'm sure there were even more interrupts > elsewhere. Is 20k+ interrupts > really not

Re: Linux messages full of `random: get_random_u32 called from`

On Thu, Apr 26, 2018 at 10:20:44PM -0700, Sultan Alsawaf wrote: > > I noted at least 20,000 mmc interrupts before I intervened in the boot > process to provide entropy > myself. That's just for mmc, so I'm sure there were even more interrupts > elsewhere. Is 20k+ interrupts > really not

Re: [PATCH 3.18 00/24] 3.18.107-stable review

On Fri, Apr 27, 2018 at 03:57:35PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.107 release. The kernel.org page currently lists 3.18 as EOL. I assume we released an update for Spectre/Meltdown after we declared it end of life, but I was surprised

Re: [PATCH 3.18 00/24] 3.18.107-stable review

On Fri, Apr 27, 2018 at 03:57:35PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.107 release. The kernel.org page currently lists 3.18 as EOL. I assume we released an update for Spectre/Meltdown after we declared it end of life, but I was surprised

Re: Linux messages full of `random: get_random_u32 called from`

On Fri, Apr 27, 2018 at 05:38:52PM +0200, Jason A. Donenfeld wrote: > > Please correct me if I'm wrong, but my present understanding of this > is that crng readiness used to be broken, meaning people would have a > seeded rng without it actually being seeded. You fixed this bug, and > now people

Re: Linux messages full of `random: get_random_u32 called from`

On Fri, Apr 27, 2018 at 05:38:52PM +0200, Jason A. Donenfeld wrote: > > Please correct me if I'm wrong, but my present understanding of this > is that crng readiness used to be broken, meaning people would have a > seeded rng without it actually being seeded. You fixed this bug, and > now people

Re: Linux 4.17.0-rc2 - WARNING: inconsistent lock state

On Wed, Apr 25, 2018 at 08:44:04AM -0600, Shuah Khan wrote: > I am seeing the following on my system with 4.17-rc2. Probably in 4.17-rc1 > as well. > > Something to be concerned about. Is this related to > Commit: a45403b51582a87872927a3e0fc0a389c26867f1 > ext4: always initialize the crc32c

Re: Linux 4.17.0-rc2 - WARNING: inconsistent lock state

On Wed, Apr 25, 2018 at 08:44:04AM -0600, Shuah Khan wrote: > I am seeing the following on my system with 4.17-rc2. Probably in 4.17-rc1 > as well. > > Something to be concerned about. Is this related to > Commit: a45403b51582a87872927a3e0fc0a389c26867f1 > ext4: always initialize the crc32c

Re: Linux messages full of `random: get_random_u32 called from`

On Thu, Apr 26, 2018 at 10:47:49PM +0200, Christian Brauner wrote: > > We have observed a similiar problem with libvirt. As soon as entropy is > provided the boot finishes otherwise it hangs for a long time. > This is not happening with v4.17-rc1 afaict. For libvirt there is at least an easy

Re: Linux messages full of `random: get_random_u32 called from`

On Thu, Apr 26, 2018 at 10:47:49PM +0200, Christian Brauner wrote: > > We have observed a similiar problem with libvirt. As soon as entropy is > provided the boot finishes otherwise it hangs for a long time. > This is not happening with v4.17-rc1 afaict. For libvirt there is at least an easy

Re: Linux messages full of `random: get_random_u32 called from`

On Thu, Apr 26, 2018 at 01:22:02PM -0700, Sultan Alsawaf wrote: > > Also, regardless of what's hanging on CRNG init, CRNG should be able to init > on its own in a timely > manner without the need for user-provided entropy. Userspace was working fine > before the recent CRNG > kernel changes, so

Re: Linux messages full of `random: get_random_u32 called from`

On Thu, Apr 26, 2018 at 01:22:02PM -0700, Sultan Alsawaf wrote: > > Also, regardless of what's hanging on CRNG init, CRNG should be able to init > on its own in a timely > manner without the need for user-provided entropy. Userspace was working fine > before the recent CRNG > kernel changes, so

Re: random: GFP_KERNEL from irq context

On Thu, Apr 26, 2018 at 10:28:13AM -0600, Jens Axboe wrote: > during boot. We end up doing the numa_crng_init() from interrupt context, > which > makes things unhappy since you do GFP_KERNEL | __GFP_NOFAIL allocations from > there. I've already sent a pull request to Linux to fix this; see the

Re: random: GFP_KERNEL from irq context

On Thu, Apr 26, 2018 at 10:28:13AM -0600, Jens Axboe wrote: > during boot. We end up doing the numa_crng_init() from interrupt context, > which > makes things unhappy since you do GFP_KERNEL | __GFP_NOFAIL allocations from > there. I've already sent a pull request to Linux to fix this; see the

Re: Linux messages full of `random: get_random_u32 called from`

On Thu, Apr 26, 2018 at 08:17:34AM -0700, Sultan Alsawaf wrote: > > Hmm, can you let the boot hang for a while? It should continue after > > a few minutes if you wait long enough, but wait a minute or two, then > > give it entropy so the boot can continue. Then can you use > > "systemd-analyze

Re: Linux messages full of `random: get_random_u32 called from`

On Thu, Apr 26, 2018 at 08:17:34AM -0700, Sultan Alsawaf wrote: > > Hmm, can you let the boot hang for a while? It should continue after > > a few minutes if you wait long enough, but wait a minute or two, then > > give it entropy so the boot can continue. Then can you use > > "systemd-analyze

Re: [PATCH 4.9 75/95] random: set up the NUMA crng instances after the CRNG is fully initialized

On Thu, Apr 26, 2018 at 03:53:58PM +0900, Tetsuo Handa wrote: > Oh, pull request was already sent. Should be merged shortly. > > https://marc.info/?l=linux-kernel=152472466201090=2 More testing, either before or after merging, would be greatly appreciated. One of the challenges is that there

Re: [PATCH 4.9 75/95] random: set up the NUMA crng instances after the CRNG is fully initialized

On Thu, Apr 26, 2018 at 03:53:58PM +0900, Tetsuo Handa wrote: > Oh, pull request was already sent. Should be merged shortly. > > https://marc.info/?l=linux-kernel=152472466201090=2 More testing, either before or after merging, would be greatly appreciated. One of the challenges is that there

Re: Linux messages full of `random: get_random_u32 called from`

On Wed, Apr 25, 2018 at 10:05:55PM -0700, Sultan Alsawaf wrote: > > Correct, I'm running Xubuntu 18.04 with my own kernel based off linux-stable. > Hmm, can you let the boot hang for a while? It should continue after a few minutes if you wait long enough, but wait a minute or two, then give it

Re: Linux messages full of `random: get_random_u32 called from`

On Wed, Apr 25, 2018 at 10:05:55PM -0700, Sultan Alsawaf wrote: > > Correct, I'm running Xubuntu 18.04 with my own kernel based off linux-stable. > Hmm, can you let the boot hang for a while? It should continue after a few minutes if you wait long enough, but wait a minute or two, then give it

[GIT PULL] /dev/random fixes for 4.17-rc3

The following changes since commit d848e5f8e1ebdb227d045db55fe4f825e82965fa: random: add new ioctl RNDRESEEDCRNG (2018-04-14 11:59:31 -0400) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random.git tags/random_for_linus_stable for you to fetch

[GIT PULL] /dev/random fixes for 4.17-rc3

The following changes since commit d848e5f8e1ebdb227d045db55fe4f825e82965fa: random: add new ioctl RNDRESEEDCRNG (2018-04-14 11:59:31 -0400) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random.git tags/random_for_linus_stable for you to fetch

Re: Linux messages full of `random: get_random_u32 called from`

On Wed, Apr 25, 2018 at 09:11:08PM -0700, Sultan Alsawaf wrote: > I noticed "systems without sufficient boot randomness" and would like to add > to this. > > With the changes to /dev/random going from 4.16.3 to 4.16.4, my low-spec > Chromebook does not reach > the login screen upon boot (it

Re: Linux messages full of `random: get_random_u32 called from`

On Wed, Apr 25, 2018 at 09:11:08PM -0700, Sultan Alsawaf wrote: > I noticed "systems without sufficient boot randomness" and would like to add > to this. > > With the changes to /dev/random going from 4.16.3 to 4.16.4, my low-spec > Chromebook does not reach > the login screen upon boot (it

Re: Linux messages full of `random: get_random_u32 called from`

Does this help on your system? - Ted commit 4e00b339e264802851aff8e73cde7d24b57b18ce Author: Theodore Ts'o Date: Wed Apr 25 01:12:32 2018 -0400 random: rate limit unseeded randomness warnings On systems without

Re: Linux messages full of `random: get_random_u32 called from`

Does this help on your system? - Ted commit 4e00b339e264802851aff8e73cde7d24b57b18ce Author: Theodore Ts'o Date: Wed Apr 25 01:12:32 2018 -0400 random: rate limit unseeded randomness warnings On systems without sufficient boot

Re: [PATCH] random: fix possible sleeping allocation from irq context

On Wed, Apr 25, 2018 at 09:46:42AM +0900, Tetsuo Handa wrote: > Theodore Ts\'o wrote: > > We can do a sleeping allocation from an irq context when CONFIG_NUMA > > is enabled. Fix this by initializing the NUMA crng instances in a > > workqueue. > > Offloading to workqueue context itself would be

Re: [PATCH] random: fix possible sleeping allocation from irq context

On Wed, Apr 25, 2018 at 09:46:42AM +0900, Tetsuo Handa wrote: > Theodore Ts\'o wrote: > > We can do a sleeping allocation from an irq context when CONFIG_NUMA > > is enabled. Fix this by initializing the NUMA crng instances in a > > workqueue. > > Offloading to workqueue context itself would be

Re: vmalloc with GFP_NOFS

On Tue, Apr 24, 2018 at 10:27:12AM -0600, Michal Hocko wrote: > fs/ext4/xattr.c > > What to do about this? Well, there are two things. Firstly, it would be > really great to double check whether the GFP_NOFS is really needed. I > cannot judge that because I am not familiar with the code. *Most*

Re: vmalloc with GFP_NOFS

On Tue, Apr 24, 2018 at 10:27:12AM -0600, Michal Hocko wrote: > fs/ext4/xattr.c > > What to do about this? Well, there are two things. Firstly, it would be > really great to double check whether the GFP_NOFS is really needed. I > cannot judge that because I am not familiar with the code. *Most*

Re: [BUG, PATCH] random: sleep in irq context

On Tue, Apr 24, 2018 at 10:40:36AM +0200, Sebastian Ott wrote: > On Mon, 23 Apr 2018, Sebastian Ott wrote: > > This happend once during boot and I could not reproduce this since, but I > > think the following patch should fix the issue: > > I can now recreate the issue reliably. The following

Re: [BUG, PATCH] random: sleep in irq context

On Tue, Apr 24, 2018 at 10:40:36AM +0200, Sebastian Ott wrote: > On Mon, 23 Apr 2018, Sebastian Ott wrote: > > This happend once during boot and I could not reproduce this since, but I > > think the following patch should fix the issue: > > I can now recreate the issue reliably. The following

Re: Linux messages full of `random: get_random_u32 called from`

On Tue, Apr 24, 2018 at 09:56:21AM -0400, Theodore Y. Ts'o wrote: > On Tue, Apr 24, 2018 at 01:48:16PM +0200, Paul Menzel wrote: > > Dear Linux folks, > > > > > > Since Linux 4.17-rcX, Linux spams a lot of `random: get_random_u32 called > > from` message

Re: Linux messages full of `random: get_random_u32 called from`

On Tue, Apr 24, 2018 at 09:56:21AM -0400, Theodore Y. Ts'o wrote: > On Tue, Apr 24, 2018 at 01:48:16PM +0200, Paul Menzel wrote: > > Dear Linux folks, > > > > > > Since Linux 4.17-rcX, Linux spams a lot of `random: get_random_u32 called > > from` message

Re: Linux messages full of `random: get_random_u32 called from`

On Tue, Apr 24, 2018 at 01:48:16PM +0200, Paul Menzel wrote: > Dear Linux folks, > > w > Since Linux 4.17-rcX, Linux spams a lot of `random: get_random_u32 called > from` messages. I believe, this setting should be reverted by default as > otherwise a lot of other messages are not seen. Can you

Re: Linux messages full of `random: get_random_u32 called from`

On Tue, Apr 24, 2018 at 01:48:16PM +0200, Paul Menzel wrote: > Dear Linux folks, > > w > Since Linux 4.17-rcX, Linux spams a lot of `random: get_random_u32 called > from` messages. I believe, this setting should be reverted by default as > otherwise a lot of other messages are not seen. Can you

Re: WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected

On Mon, Apr 23, 2018 at 10:49:12AM -0700, Dmitry Torokhov wrote: > On Sun, Apr 22, 2018 at 7:02 PM, syzbot > wrote: > > > > Hello, > > > > syzbot hit the following crash on upstream commit > > 285848b0f4074f04ab606f1e5dca296482033d54 (Sun Apr

Re: WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected

On Mon, Apr 23, 2018 at 10:49:12AM -0700, Dmitry Torokhov wrote: > On Sun, Apr 22, 2018 at 7:02 PM, syzbot > wrote: > > > > Hello, > > > > syzbot hit the following crash on upstream commit > > 285848b0f4074f04ab606f1e5dca296482033d54 (Sun Apr 22 04:20:48 2018 +) > > Merge tag

Re: [PATCH 4.9 75/95] random: set up the NUMA crng instances after the CRNG is fully initialized

On Mon, Apr 23, 2018 at 07:21:10PM +0900, Tetsuo Handa wrote: > Greg Kroah-Hartman wrote: > > > I think this can be fixed by backporting commit 4a072c71f49b > > > "random: silence compiler warnings and fix race" but I'm not sure > > > whether that depends on other changes. > > > > According to

Re: [PATCH 4.9 75/95] random: set up the NUMA crng instances after the CRNG is fully initialized

On Mon, Apr 23, 2018 at 07:21:10PM +0900, Tetsuo Handa wrote: > Greg Kroah-Hartman wrote: > > > I think this can be fixed by backporting commit 4a072c71f49b > > > "random: silence compiler warnings and fix race" but I'm not sure > > > whether that depends on other changes. > > > > According to

Re: [PATCH 4.9 37/95] ext4: add validity checks for bitmap block numbers

On Sun, Apr 22, 2018 at 10:54:23PM +0100, Ben Hutchings wrote: > > offset = blk - group_first_block; > > - if (!ext4_test_bit(EXT4_B2C(sbi, offset), bh->b_data)) > > + if (offset < 0 || EXT4_B2C(sbi, offset) >= sb->s_blocksize || > > + !ext4_test_bit(EXT4_B2C(sbi, offset),

Re: [PATCH 4.9 37/95] ext4: add validity checks for bitmap block numbers

On Sun, Apr 22, 2018 at 10:54:23PM +0100, Ben Hutchings wrote: > > offset = blk - group_first_block; > > - if (!ext4_test_bit(EXT4_B2C(sbi, offset), bh->b_data)) > > + if (offset < 0 || EXT4_B2C(sbi, offset) >= sb->s_blocksize || > > + !ext4_test_bit(EXT4_B2C(sbi, offset),

Re: [PATCH] ext4 : fix comments in ext4_swap_extents

On Thu, Apr 19, 2018 at 04:50:28PM +0200, Jan Kara wrote: > On Mon 19-03-18 16:34:09, zhenwei.pi wrote: > > "mark_unwritten" in comment and "unwritten" in variable > > argument lists is mismatch. > > > > Signed-off-by: zhenwei.pi > > This seems to have fallen through

Re: [PATCH] ext4 : fix comments in ext4_swap_extents

On Thu, Apr 19, 2018 at 04:50:28PM +0200, Jan Kara wrote: > On Mon 19-03-18 16:34:09, zhenwei.pi wrote: > > "mark_unwritten" in comment and "unwritten" in variable > > argument lists is mismatch. > > > > Signed-off-by: zhenwei.pi > > This seems to have fallen through cracks. The patch looks

Re: repeatable boot randomness inside KVM guest

On Tue, Apr 17, 2018 at 04:42:39PM +0100, James Bottomley wrote: > Depends how the parameter is passed. If it can be influenced from the > command line then a large class of "trusted boot" systems actually > don't verify the command line, so you can boot a trusted system and > still inject bogus

Re: repeatable boot randomness inside KVM guest

On Tue, Apr 17, 2018 at 04:42:39PM +0100, James Bottomley wrote: > Depends how the parameter is passed. If it can be influenced from the > command line then a large class of "trusted boot" systems actually > don't verify the command line, so you can boot a trusted system and > still inject bogus

Re: repeatable boot randomness inside KVM guest

On Tue, Apr 17, 2018 at 12:57:12PM +0100, James Bottomley wrote: > > You don't have to compromise the bootloader to influence this, you > merely have to trick it into providing the random number you wanted. > The bigger you make the attack surface (the more inputs) the more > likelihood of

Re: repeatable boot randomness inside KVM guest

On Tue, Apr 17, 2018 at 12:57:12PM +0100, James Bottomley wrote: > > You don't have to compromise the bootloader to influence this, you > merely have to trick it into providing the random number you wanted. > The bigger you make the attack surface (the more inputs) the more > likelihood of

Re: repeatable boot randomness inside KVM guest

+linux...@kvack.org k...@vger.kernel.org, secur...@kernel.org moved to bcc On Sat, Apr 14, 2018 at 10:59:21PM +0300, Alexey Dobriyan wrote: > SLAB allocators got CONFIG_SLAB_FREELIST_RANDOM option which randomizes > allocation pattern inside a slab: > > int cache_random_seq_create(struct

Re: repeatable boot randomness inside KVM guest

+linux...@kvack.org k...@vger.kernel.org, secur...@kernel.org moved to bcc On Sat, Apr 14, 2018 at 10:59:21PM +0300, Alexey Dobriyan wrote: > SLAB allocators got CONFIG_SLAB_FREELIST_RANDOM option which randomizes > allocation pattern inside a slab: > > int cache_random_seq_create(struct

Re: [PATCH 1/5] random: fix crng_ready() test

On Fri, Apr 13, 2018 at 03:05:01PM +0200, Stephan Mueller wrote: > > What I would like to point out that more and more folks change to > getrandom(2). As this call will now unblock much later in the boot cycle, > these systems see a significant departure from the current system behavior. > >

Re: [PATCH 1/5] random: fix crng_ready() test

On Fri, Apr 13, 2018 at 03:05:01PM +0200, Stephan Mueller wrote: > > What I would like to point out that more and more folks change to > getrandom(2). As this call will now unblock much later in the boot cycle, > these systems see a significant departure from the current system behavior. > >

Re: [PATCH 1/5] random: fix crng_ready() test

On Fri, Apr 13, 2018 at 07:38:30AM +0200, Stephan Mueller wrote: > > The crng_init variable has three states: > > > > 0: The CRNG is not initialized at all > > 1: The CRNG has a small amount of entropy, hopefully good enough for > >early-boot, non-cryptographical use cases > > 2: The CRNG is

Re: [PATCH 1/5] random: fix crng_ready() test

On Fri, Apr 13, 2018 at 07:38:30AM +0200, Stephan Mueller wrote: > > The crng_init variable has three states: > > > > 0: The CRNG is not initialized at all > > 1: The CRNG has a small amount of entropy, hopefully good enough for > >early-boot, non-cryptographical use cases > > 2: The CRNG is

Re: [PATCH] crypto: DRBG - guard uninstantion by lock

On Sun, Apr 08, 2018 at 09:07:03PM +0200, Stephan Müller wrote: > Can you please check whether the attached patch fixes the issue? > Stephan, FYI, if you incude in your e-mail "#syz test " as the first line of your patch and the syzbot e-mail is cc'ed, the syzbot will automatically apply the

Re: [PATCH] crypto: DRBG - guard uninstantion by lock

On Sun, Apr 08, 2018 at 09:07:03PM +0200, Stephan Müller wrote: > Can you please check whether the attached patch fixes the issue? > Stephan, FYI, if you incude in your e-mail "#syz test " as the first line of your patch and the syzbot e-mail is cc'ed, the syzbot will automatically apply the

Re: Running syzkaller repros using kvm-xfstests

On Sun, Apr 08, 2018 at 03:18:39PM +0200, Dmitry Vyukov wrote: > > But note that syzkaller is under active development, so pre-canned > binaries may not always work. Mismatching binary may not understand > all syscalls, fail to parse program, interpret arguments differently, > execute program

Re: Running syzkaller repros using kvm-xfstests

On Sun, Apr 08, 2018 at 03:18:39PM +0200, Dmitry Vyukov wrote: > > But note that syzkaller is under active development, so pre-canned > binaries may not always work. Mismatching binary may not understand > all syscalls, fail to parse program, interpret arguments differently, > execute program

Re: possible deadlock in perf_event_detach_bpf_prog

On Thu, Mar 29, 2018 at 2:18 PM, Daniel Borkmann wrote: > On 03/29/2018 11:04 PM, syzbot wrote: >> Hello, >> >> syzbot hit the following crash on upstream commit >> 3eb2ce825ea1ad89d20f7a3b5780df850e4be274 (Sun Mar 25 22:44:30 2018 +) >> Linux 4.16-rc7 >> syzbot

Re: possible deadlock in perf_event_detach_bpf_prog

On Thu, Mar 29, 2018 at 2:18 PM, Daniel Borkmann wrote: > On 03/29/2018 11:04 PM, syzbot wrote: >> Hello, >> >> syzbot hit the following crash on upstream commit >> 3eb2ce825ea1ad89d20f7a3b5780df850e4be274 (Sun Mar 25 22:44:30 2018 +) >> Linux 4.16-rc7 >> syzbot dashboard link: >>

Running syzkaller repros using kvm-xfstests

On Thu, Apr 05, 2018 at 09:37:41PM -0400, Theodore Y. Ts'o wrote: > Note that I haven't just been complaining about it. I've been working > on ways so that the gce-xfstests and kvm-xfstests test appliances can > more easily be used to work on Syzbot reports. If I can make myself > mo

Running syzkaller repros using kvm-xfstests

On Thu, Apr 05, 2018 at 09:37:41PM -0400, Theodore Y. Ts'o wrote: > Note that I haven't just been complaining about it. I've been working > on ways so that the gce-xfstests and kvm-xfstests test appliances can > more easily be used to work on Syzbot reports. If I can make myself > mo

Re: WARNING in ext4_superblock_csum_set

#syz fix: ext4: always initialize the crc32c checksum driver

Re: WARNING in ext4_superblock_csum_set

#syz fix: ext4: always initialize the crc32c checksum driver

Re: WARNING in up_write

On Thu, Apr 05, 2018 at 05:13:25PM -0700, Eric Biggers wrote: > Well, ultimately a human needed to investigate the syzbot bug report to figure > out what was really going on. In my view, the largest problem is that there > are > simply too many bugs, so many are getting ignored. If there were

Re: WARNING in up_write

On Thu, Apr 05, 2018 at 05:13:25PM -0700, Eric Biggers wrote: > Well, ultimately a human needed to investigate the syzbot bug report to figure > out what was really going on. In my view, the largest problem is that there > are > simply too many bugs, so many are getting ignored. If there were

Re: [GIT PULL] x86/build changes for v4.17

On Thu, Apr 5, 2018 at 5:13 PM Linus Torvalds wrote: > And btw, I hate how stupid gcc is about "constant size arrays but acts > as a VLA because it wasn't an integer-constant-expression size" > things. > Your code generation example really is a sad sad example of

Re: [GIT PULL] x86/build changes for v4.17

On Thu, Apr 5, 2018 at 5:13 PM Linus Torvalds wrote: > And btw, I hate how stupid gcc is about "constant size arrays but acts > as a VLA because it wasn't an integer-constant-expression size" > things. > Your code generation example really is a sad sad example of it. A good > optimizer should

Re: [GIT PULL] x86/build changes for v4.17

On Thu, Apr 5, 2018 at 2:06 PM Linus Torvalds <torva...@linux-foundation.org> wrote: > On Thu, Apr 5, 2018 at 10:46 AM, James Y Knight <jykni...@google.com> wrote: > > > > GCC, however, mixes up the concept of a C "constant expression" with the >

Re: [GIT PULL] x86/build changes for v4.17

On Thu, Apr 5, 2018 at 2:06 PM Linus Torvalds wrote: > On Thu, Apr 5, 2018 at 10:46 AM, James Y Knight wrote: > > > > GCC, however, mixes up the concept of a C "constant expression" with the > > results of running optimization passes such as inlining for it

Re: [GIT PULL] x86/build changes for v4.17

I think maybe you're confused; those functions do not appear to use __builtin_constant_p, which is the issue at hand. Clang's optimizer is of course not a complete joke...it can perfectly well optimize functions after inlining in order to not generate "shit code gen". GCC, however, mixes up the

Re: [GIT PULL] x86/build changes for v4.17

I think maybe you're confused; those functions do not appear to use __builtin_constant_p, which is the issue at hand. Clang's optimizer is of course not a complete joke...it can perfectly well optimize functions after inlining in order to not generate "shit code gen". GCC, however, mixes up the

Re: [GIT PULL] x86/build changes for v4.17

On Thu, Apr 5, 2018 at 3:08 AM Peter Zijlstra <pet...@infradead.org> wrote: > On Wed, Apr 04, 2018 at 10:21:05PM +0000, James Y Knight wrote: > > But allowing random pointer arithmetic, and pointer arithmetic wraparound, > > is still different than asserting that an obje

Re: [GIT PULL] x86/build changes for v4.17

On Thu, Apr 5, 2018 at 3:08 AM Peter Zijlstra wrote: > On Wed, Apr 04, 2018 at 10:21:05PM +, James Y Knight wrote: > > But allowing random pointer arithmetic, and pointer arithmetic wraparound, > > is still different than asserting that an object _field access_ can > >

Re: WARNING in up_write

On Wed, Apr 04, 2018 at 12:35:04PM -0700, Matthew Wilcox wrote: > On Wed, Apr 04, 2018 at 09:24:05PM +0200, Dmitry Vyukov wrote: > > On Tue, Apr 3, 2018 at 4:01 AM, syzbot > > wrote: > > > DEBUG_LOCKS_WARN_ON(sem->owner != get_current()) > >

<    4   5   6   7   8   9   10   11   12   13   >