Date: Tue, 10 Jul 2018 13:53:02 -0700 From: Jann Horn <jannh@...gle.com> To: Christoph Hellwig <hch@...radead.org> Cc: axboe@...nel.dk, Douglas Gilbert <dgilbert@...erlog.com>, Al Viro <viro@...iv.linux.org.uk>, fujita.tomonori@....ntt.co.jp, jejb@...ux.vnet.ibm.com, martin.petersen@...cle.com, linux-block@...r.kernel.org, linux-scsi@...r.kernel.org, kernel list <linux-kernel@...r.kernel.org>, Kernel Hardening <kernel-hardening@...ts.openwall.com>, security@...nel.org Subject: Re: [PATCH] sg, bsg: mitigate read/write abuse, block uaccess in release On Sun, Jul 8, 2018 at 7:58 AM Christoph Hellwig <hch@...radead.org> wrote: > > On Thu, Jun 21, 2018 at 08:07:23AM -0600, Jens Axboe wrote: > > I'd be fine with that, if we knew that nobody uses it. But that's > > really hard to figure out. I did see Jann's source code scan, which > > even if non-exhaustive, still shows at least one user of it. > > One is an example, and the other looks very close to an example, > as far as I can tell it was Nic doing a bsg read/write WIP for a > tgt module without anyone every picking up on it. I did add the tgt > list to Cc and no one seemed to care about the bsg read/write support. > Adding the tgt list back, but I doubt anyone ever actually used it. > > > How about we just make the write interface sync? Then any copy can > > happen while the we block the task, and the read side is just > > copying the header info back, or dumping it if the task didn't > > read it before it went away. > > How is that going to work? As far as I can tell each I/O using > bsg read/write needs a write and a read, so they need to pair > and thus can't be a purely sync interface. > > It also doesn't help with the issue that bsg_write may possible > write to user memory, which is highly unusal and asking for security > issues itself. > > Either way, we should probably at very least apply a respun version > of the patch from Jann to 4.18-rc and -stable while we keep discussing > this. > > Jann, can you respin the bsg patch with the same changes as the now > included sg one? With the error messages like in my sg patch or like with Linus' proposed patch (https://lore.kernel.org/lkml/CA+55aFwg-2GP4ASTdd1pusmZkF7c8AN9febVDCaioDxzYJSLfw@mail.gmail.com/) applied?
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ