[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d31189fc94392eb733c1e310ac1ec498@natalenko.name>
Date: Tue, 10 Apr 2018 15:47:41 +0200
From: Oleksandr Natalenko <oleksandr@...alenko.name>
To: Kees Cook <keescook@...omium.org>
Cc: David Windsor <dave@...lcore.net>,
"James E.J. Bottomley" <jejb@...ux.vnet.ibm.com>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
linux-scsi@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
Christoph Hellwig <hch@....de>, Jens Axboe <axboe@...nel.dk>,
Hannes Reinecke <hare@...e.com>,
Johannes Thumshirn <jthumshirn@...e.de>,
linux-block@...r.kernel.org, paolo.valente@...aro.org,
keescook@...gle.com
Subject: Re: usercopy whitelist woe in scsi_sense_cache
Hi.
10.04.2018 08:35, Oleksandr Natalenko wrote:
>> - does it reproduce _without_ hardened usercopy? (I would assume yes,
>> but you'd just not get any warning until the hangs started.) If it
>> does reproduce without hardened usercopy, then a new bisect run could
>> narrow the search even more.
>
> Looks like it cannot be disabled via kernel cmdline, so I have to
> re-compile the kernel, right? I can certainly do that anyway.
Okay, I've recompiled the kernel without hardened usercopy:
[root@...hlinux ~]# zgrep USERCOPY /proc/config.gz
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_HAVE_HARDENED_USERCOPY_ALLOCATOR=y
# CONFIG_HARDENED_USERCOPY is not set
and I cannot reproduce the issue anymore. I/O doesn't hang regardless of
how long I hammer it.
Eeeh? Maybe, this is a matter of some cleanup code path once the
warn/bug condition is hit with hardening enabled? I'm just guessing here
again.
Will work towards checking Linus' master branch now…
Regards,
Oleksandr
Powered by blists - more mailing lists