On Wed, Nov 14, 2018 at 6:06 PM, Omar Sandoval wrote:
> On Wed, Nov 14, 2018 at 05:23:06PM -0600, Kees Cook wrote:
>> On Sat, Nov 10, 2018 at 8:15 AM, Jordan Glover
>> wrote:
>> > Hello,
>> >
>> > Commit 6c3b7af1c975b87b86dcb2af233d1ae21eb05107 ("
/torvalds/linux.git/commit/?h=v4.20-rc1=6c3b7af1c975b87b86dcb2af233d1ae21eb05107
>
> [2]
> https://github.com/anthraxx/linux-hardened/commit/9460692de8eb53fd62d59f564eba215e7c03a34b
>
> [3] https://lwn.net/Articles/763641/
>
> [4] https://outflux.net/slides/2018/lss/danger.pdf
--
Kees Cook
On Wed, Jul 25, 2018 at 4:32 AM, Rafael J. Wysocki wrote:
> On Tue, Jul 24, 2018 at 6:49 PM, Kees Cook wrote:
>> In the quest to remove all stack VLA usage from the kernel[1], this
>> removes the discouraged use of AHASH_REQUEST_ON_STACK by switching to
>> shash di
ng like this respin of Kees' series?
>
> http://git.infradead.org/users/hch/block.git/shortlog/refs/heads/sense-cleanup
Does the CONFIG_PCMCIA in drivers/scsi/Makefile now get exposed in
weird config cases?
Otherwise, yeah, looks good to me. Thanks!
-Kees
--
Kees Cook
Pixel Security
ere originally.
Honestly, it's almost so small I could make it a static inline. :P
> I'm traveling today so I probably won't get a chance to look closely
> until tomorrow morning.
No worries; thanks for looking at it!
-Kees
--
Kees Cook
Pixel Security
On Wed, May 23, 2018 at 1:25 AM, Sergei Shtylyov
<sergei.shtyl...@cogentembedded.com> wrote:
> Hello!
>
> On 5/22/2018 9:15 PM, Kees Cook wrote:
>
>> To avoid introducing problems like those fixed in commit f7068114d45e
>> ("sr: pass down correctly sized SCSI s
about that,
> mostly getting rid of the entire stack dependency.
Aaand, I can't do this and leave it in drivers/scsi because of drivers/Makefile:
obj-$(CONFIG_SCSI) += scsi/
So: this needs to live in block/ just like CONFIG_BLK_SCSI_REQUEST's
scsi_ioctl.c. I will split it into CONFIG_BLK_SCSI_SENSE, but I'll
still need to move the code from drivers/scsi/ to block/. Is this
okay?
-Kees
--
Kees Cook
Pixel Security
On Tue, May 22, 2018 at 4:42 PM, Jens Axboe <ax...@kernel.dk> wrote:
> On May 22, 2018, at 5:31 PM, Kees Cook <keesc...@chromium.org> wrote:
>>
>>> On Tue, May 22, 2018 at 12:16 PM, Jens Axboe <ax...@kernel.dk> wrote:
>>>> On 5/22/18 1:13 PM, Chr
about
>> everyone else, and keep the scsi code where it belongs.
>
> Fine with me then, hopefully we can some day kill it off.
I'll send a v2. I found a few other things to fix up (including the
cdrom.c one).
Thanks!
-Kees
--
Kees Cook
Pixel Security
On Tue, May 22, 2018 at 11:50 AM, Martin K. Petersen
<martin.peter...@oracle.com> wrote:
>
> Christoph,
>
>> On Tue, May 22, 2018 at 11:15:09AM -0700, Kees Cook wrote:
>>> Both SCSI and ATAPI share the sense header. In preparation for using the
>>>
Both SCSI and ATAPI share the sense header. In preparation for using the
struct scsi_sense_hdr more widely, move this into a separate header and
move the helper function to scsi_ioctl.c which is linked with CONFIG_IDE
by way of CONFIG_BLK_SCSI_REQUEST.
Signed-off-by: Kees Cook <ke
This removes the unused sense buffer in read_cap16() and write_same16().
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/scsi/cxlflash/superpipe.c | 8 ++--
drivers/scsi/cxlflash/vlun.c | 7 ++-
2 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/d
This drops unused sense buffers from:
cdrom_eject()
cdrom_read_capacity()
cdrom_read_tocentry()
ide_cd_lockdoor()
ide_cd_read_toc()
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/ide/ide-cd.c
This is a follow-up to commit f7068114d45e ("sr: pass down correctly
sized SCSI sense buffer") which further cleans up and removes needless
sense character array buffers and "struct request_sense" usage in favor
of the common "struct scsi_sense_hdr".
First, drop a bunch of unused sense buffers:
those 96 bytes onto the stack to avoid triggering
the sizeof() check.
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/scsi/scsi_lib.c| 6 +++---
include/scsi/scsi_device.h | 12 +++-
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi
Instead of dynamically allocating the sense buffers, put them on the
stack so that future compile-time sizeof() checks will be able to see
their buffer length.
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/ata/libata-scsi.c | 18 ++
1 file changed, 6 inse
dable to distinguish between "sense" meaning "struct request_sense"
and "sshdr" meaning "struct scsi_sense_hdr".
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
drivers/block/pktcdvd.c| 36 ++--
drivers/cdrom/cdrom.c
only found the "what". :) If you want, grab
the reproducer VM linked to earlier in this thread; it'll hit the
problem within about 30 seconds of running the reproducer.
-Kees
--
Kees Cook
Pixel Security
On Tue, Apr 17, 2018 at 3:57 PM, Jens Axboe <ax...@kernel.dk> wrote:
> On 4/17/18 3:48 PM, Jens Axboe wrote:
>> On 4/17/18 3:47 PM, Kees Cook wrote:
>>> On Tue, Apr 17, 2018 at 2:39 PM, Jens Axboe <ax...@kernel.dk> wrote:
>>>> On 4/17/18 3:25 PM, Kees Cook
On Tue, Apr 17, 2018 at 2:45 PM, Jens Axboe <ax...@kernel.dk> wrote:
> On 4/17/18 3:42 PM, Kees Cook wrote:
>> Some elevators may not correctly check rq->rq_flags & RQF_ELVPRIV, and
>> may attempt to read rq->elv fields. When requests got reused, this
>> caus
On Tue, Apr 17, 2018 at 2:39 PM, Jens Axboe <ax...@kernel.dk> wrote:
> On 4/17/18 3:25 PM, Kees Cook wrote:
>> On Tue, Apr 17, 2018 at 1:46 PM, Kees Cook <keesc...@chromium.org> wrote:
>>> I see elv.priv[1] assignments made in a few places -- is it possible
>>&
orted-by: Oleksandr Natalenko <oleksa...@natalenko.name>
Fixes: bd166ef183c26 ("blk-mq-sched: add framework for MQ capable IO
schedulers")
Cc: sta...@vger.kernel.org
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
In theory, BFQ needs to also check the RQF_ELVPRIV flag, b
On Tue, Apr 17, 2018 at 1:46 PM, Kees Cook <keesc...@chromium.org> wrote:
> I see elv.priv[1] assignments made in a few places -- is it possible
> there is some kind of uninitialized-but-not-NULL state that can leak
> in there?
Got it. This fixes it for me:
diff --git a/block/b
bfq_insert_request() get called without bfq_prepare_request() being
called first?
-Kees
--
Kees Cook
Pixel Security
On Tue, Apr 17, 2018 at 1:20 PM, Kees Cook <keesc...@chromium.org> wrote:
> On Tue, Apr 17, 2018 at 1:03 PM, Kees Cook <keesc...@chromium.org> wrote:
>> The above bfq_dispatch_request+0x99/0xad0 is still
>> __bfq_dispatch_request at block/bfq-iosched.c:3902, just with KA
On Tue, Apr 17, 2018 at 1:03 PM, Kees Cook <keesc...@chromium.org> wrote:
> The above bfq_dispatch_request+0x99/0xad0 is still
> __bfq_dispatch_request at block/bfq-iosched.c:3902, just with KASAN
> removed. 0x99 is 153 decimal:
>
> (gdb) disass bfq_dispatch_request
>
On Mon, Apr 16, 2018 at 8:12 PM, Kees Cook <keesc...@chromium.org> wrote:
> With a hardware watchpoint, I've isolated the corruption to here:
>
> bfq_dispatch_request+0x2be/0x1610:
> __bfq_dispatch_request at block/bfq-iosched.c:3902
> 3900if (rq) {
> 3901
On Mon, Apr 16, 2018 at 8:12 PM, Kees Cook <keesc...@chromium.org> wrote:
> With a hardware watchpoint, I've isolated the corruption to here:
>
> bfq_dispatch_request+0x2be/0x1610:
> __bfq_dispatch_request at block/bfq-iosched.c:3902
> 3900if (rq) {
> 3901
On Tue, Apr 17, 2018 at 3:02 AM, James Bottomley
<j...@linux.vnet.ibm.com> wrote:
> On Mon, 2018-04-16 at 20:12 -0700, Kees Cook wrote:
>> I still haven't figured this out, though... any have a moment to look
>> at this?
>
> Just to let you know you're not alone ...
. Now that I have a
specific place to watch in the kernel for the corruption, though, that
might help. If I get stuck again today, I'll try it.
-Kees
--
Kees Cook
Pixel Security
On Mon, Apr 16, 2018 at 1:44 PM, Kees Cook <keesc...@chromium.org> wrote:
> On Thu, Apr 12, 2018 at 8:02 PM, Kees Cook <keesc...@chromium.org> wrote:
>> On Thu, Apr 12, 2018 at 3:47 PM, Kees Cook <keesc...@chromium.org> wrote:
>>> After fixing up some build is
On Thu, Apr 12, 2018 at 8:02 PM, Kees Cook <keesc...@chromium.org> wrote:
> On Thu, Apr 12, 2018 at 3:47 PM, Kees Cook <keesc...@chromium.org> wrote:
>> After fixing up some build issues in the middle of the 4.16 cycle, I
>> get an unhelpful bisect result of commit
On Thu, Apr 12, 2018 at 3:47 PM, Kees Cook <keesc...@chromium.org> wrote:
> After fixing up some build issues in the middle of the 4.16 cycle, I
> get an unhelpful bisect result of commit 0a4b6e2f80aa ("Merge branch
> 'for-4.16/block'"). Instead of letting the t
On Thu, Apr 12, 2018 at 3:01 PM, Kees Cook <keesc...@chromium.org> wrote:
> On Thu, Apr 12, 2018 at 12:04 PM, Oleksandr Natalenko
> <oleksa...@natalenko.name> wrote:
>> Hi.
>>
>> On čtvrtek 12. dubna 2018 20:44:37 CEST Kees Cook wrote:
>>> My fir
On Thu, Apr 12, 2018 at 12:04 PM, Oleksandr Natalenko
<oleksa...@natalenko.name> wrote:
> Hi.
>
> On čtvrtek 12. dubna 2018 20:44:37 CEST Kees Cook wrote:
>> My first bisect attempt gave me commit 5448aca41cd5 ("null_blk: wire
>> up timeouts"), which seems
On Wed, Apr 11, 2018 at 5:03 PM, Kees Cook <keesc...@chromium.org> wrote:
> On Wed, Apr 11, 2018 at 3:47 PM, Kees Cook <keesc...@chromium.org> wrote:
>> On Tue, Apr 10, 2018 at 8:13 PM, Kees Cook <keesc...@chromium.org> wrote:
>>> I'll see about booting with my
On Wed, Apr 11, 2018 at 3:47 PM, Kees Cook <keesc...@chromium.org> wrote:
> On Tue, Apr 10, 2018 at 8:13 PM, Kees Cook <keesc...@chromium.org> wrote:
>> I'll see about booting with my own kernels, etc, and try to narrow this
>> down. :)
>
> If I boot kernels I'
On Tue, Apr 10, 2018 at 8:13 PM, Kees Cook <keesc...@chromium.org> wrote:
> I'll see about booting with my own kernels, etc, and try to narrow this down.
> :)
If I boot kernels I've built, I no longer hit the bug in this VM
(though I'll keep trying). What compiler are you using?
-Ke
On Tue, Apr 10, 2018 at 10:16 AM, Oleksandr Natalenko
<oleksa...@natalenko.name> wrote:
> Hi, Kees, Paolo et al.
>
> 10.04.2018 08:53, Kees Cook wrote:
>>
>> Unfortunately I only had a single hang with no dumps. I haven't been
>> able to reproduce it since. :
uce it since. :(
-Kees
--
Kees Cook
Pixel Security
On Mon, Apr 9, 2018 at 1:30 PM, Kees Cook <keesc...@chromium.org> wrote:
> Ah! dm-crypt too. I'll see if I can get that added easily to my tests.
Quick update: I added dm-crypt (with XFS on top) and it hung my system
almost immediately. I got no warnings at all, though.
-Kees
--
/* need to finish all async __init code before freeing the memory */
async_synchronize_full();
--
Kees Cook
Pixel Security
; I successfully ran this test against the linux-dm.git
>>>> "for-4.17/dm-changes" tag that Linus merged after the block changes:
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git
>>>> tags/for-4.17/dm-change
On Mon, Apr 9, 2018 at 12:02 PM, Oleksandr Natalenko
<oleksa...@natalenko.name> wrote:
>
> Hi.
>
> (fancy details for linux-block and BFQ people go below)
>
> 09.04.2018 20:32, Kees Cook wrote:
>>
>> Ah, this detail I didn't have. I've c
eba1ab2cc9f45668735
The thing I can't figure out is how req->sense is slipping forward in
(and even beyond!) the allocation.
-Kees
--
Kees Cook
Pixel Security
In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.
Cc: Matias Bjorling <m...@lightnvm.io>
Cc: linux-block@vger.kernel.org
Signed-off-by: Kees Cook
On Fri, Oct 6, 2017 at 7:19 AM, Jens Axboe <ax...@kernel.dk> wrote:
> On 10/05/2017 05:13 PM, Kees Cook wrote:
>> In preparation for unconditionally passing the struct timer_list pointer to
>> all timer callbacks, switch to using the new timer_setup() and from_timer()
>>
linux-block@vger.kernel.org
Cc: linux...@kvack.org
Cc: Thomas Gleixner <t...@linutronix.de>
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
v2: Rebased to linux-block.git/for-4.15/timer
---
block/blk-core.c | 10 +-
include/linux/writeback.h | 2 +-
mm/page-wr
ock@vger.kernel.org
Cc: Thomas Gleixner <t...@linutronix.de>
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
v2: Rebased to linux-block.git/for-4.15/timer
---
drivers/block/aoe/aoecmd.c | 6 +++---
drivers/block/aoe/aoedev.c | 9 +++--
2 files changed, 6 insertions(+), 9 deleti
I'm
> assuming Kees will respin the writeback/laptop version and I can shove
> that in there too.
Thanks for setting this up! I'll respin and send it out again.
-Kees
--
Kees Cook
Pixel Security
her concerns.
-Kees
--
Kees Cook
Pixel Security
On Thu, Oct 5, 2017 at 7:56 AM, Jens Axboe <ax...@kernel.dk> wrote:
> On 10/04/2017 06:49 PM, Kees Cook wrote:
>> In preparation for unconditionally passing the struct timer_list pointer to
>> all timer callbacks, switch to using the new timer_setup() and from_timer()
>>
pulled those changes in? If the latter, please resend
> this when those changes are in, thanks.
It's in -next currently ("locking/refcount: Create unchecked atomic_t
implementation")
-Kees
--
Kees Cook
Pixel Security
On Fri, Apr 21, 2017 at 2:27 PM, James Bottomley
<james.bottom...@hansenpartnership.com> wrote:
> On Fri, 2017-04-21 at 13:22 -0700, Kees Cook wrote:
>> On Fri, Apr 21, 2017 at 12:55 PM, Eric Biggers <ebigge...@gmail.com>
>> wrote:
>> > > > Of course,
venting
> the security improvement from being adopted, which is unfortunate.
We've been trying to handle the conflicting desires of those wanting
very precise refcounting implementation and gaining the security
protections. Ultimately, the best way forward seemed to be to first
land the precise refcounting implementation, and start conversion
until we ran into concerns over performance. Now, since we're here, we
can move forward with getting a fast implementation that provides the
desired security protections without too greatly messing with the
refcount API.
-Kees
--
Kees Cook
Pixel Security
h implementations and CONFIG_FAST_REFCOUNT_T that trades
coverage for speed, and checks only the overflow condition. This gets
us the critical coverage without the changes in performance. This is
basically what PaX/grsecurity already did: there is a tiny change to
the atomic inc functions to detect the wrap.
-Kees
--
Kees Cook
Pixel Security
56 matches
Mail list logo
