linux-kernel - Re: [PATCH] sg_io: allow UNMAP and WRITE SAME without CAP_SYS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120911220218.GH7677@google.com>
Date:	Tue, 11 Sep 2012 15:02:18 -0700
From:	Tejun Heo <tj@...nel.org>
To:	Paolo Bonzini <pbonzini@...hat.com>
Cc:	linux-kernel@...r.kernel.org, axboe@...nel.dk,
	linux-scsi@...r.kernel.org,
	"James E.J. Bottomley" <JBottomley@...allels.com>,
	Kay Sievers <kay.sievers@...y.org>,
	Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH] sg_io: allow UNMAP and WRITE SAME without CAP_SYS_RAWIO

Hello, Paolo.

On Tue, Sep 11, 2012 at 11:50:38PM +0200, Paolo Bonzini wrote:
> > Either way, with or without virtualization, making detailed error
> > information to userland is a valid goal.  I *think* we're finally
> > getting there after years of talking via structured printk.  I don't
> > know much about the details but heard about exposing sense data via
> > printk.
> 
> Wait wait, there is already a perfectly 1:1 solution for this, and it's
> SG_IO.
> 
> I think error processing falls roughly in two categories: "I need each
> command's precise state" and "I need to know if/when something bad
> happens".  Luckily, I/O also falls roughly in the same two categories:
> "I need precise control of each commands" and "I just care of getting
> this to disk".  The former can use SG_IO, the latter can use logs.

SG_IO itself is a bypassing interface.  It bypasses most of block
layer and the kernel doesn't have any idea (apart from the adhoc
filtering) about what's going on.  The problem can be approached from
both directions (make use of OS IO layer improving it as needed or add
more intelligence to the bypass thing) and I'm not sure at all adding
more capability to the adhoc filtering is the better direction.

So, what I wanna say is that if you can get by with the adhoc thing we
already have in place for cd/dvd, that's great; otherwise, it's not
clear at all whether expanding that adhoc filtering is a good idea.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/