Re: setting up CDB filters in udev (was Re: [PATCH v2 0/3] block: add queue-private command filter, editable via sysfs)

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

> So, my first response was whether you mean to add arbitrary range
> filtering for standard read/writes too.  If you're not gonna do that

Thats relevant for /dev/sd but not /dev/sg. Now it might be the sane
thing to do is to support BPF filters on /dev/sg only ?

> But we should't add features for the ones which haven't been
> considered.  Unless you can actually justify with actual use cases,
> it's just hand waving.

The CD writer one isn't but you tried to dismiss that too. 

> The suggested mechanism is just having a switch to allow all SG_IO
> commands and pass it to the hypervisor.  There's no filtering in
> kernel at all.

That requires you have a very trusted hypervisor, that to me is a
weaker model because it increases the probability that a hack on a
guest of a cloud becomes a hack of the cloud itself at least in terms of
quiet data theft from other guests. It's still a minor risk because
you've got to break the guest then break the hypervisor from guest
virtual ring 0, but the hypervisor is a large target,

For a lot of cases being able to do the filtering in the hypervisor makes
sense and I don't have a problem with that except that you do need to
enforce CAP_SYS_RAWIO on the process setting the flags or you break the
kernel capability model. For a hypervisor guest flipping flags at boot
thats not a big deal.

> > We have filtering because it is necessary. All you are doing is putting
> > off the inevitable by adding more kernel hack "one true kernel enforced
> > religion" policy and putting off the inevitable while adding APIs you'll
> > then have to maintain until the job is done right.
> > 
> > Ultimately policy has to be user space driven, adding more temporary
> > hacks is just a waste.
> 
> Exactly, let's provide a turn-off switch for in-kernel filtering and
> let userland drive any appropriate access policy on it.  Let's please
> stay away from doing deep packet inspecting on SG_IO commands.

And you've left stuff like CD burning broken still despite people pointing
out for years that sorting out the filtering would fix it.

> I don't think we're disagreeing on the principle.  It's just that
> we're drawing different where the line lies between mechanisms and
> policies.

On the CD burning case and on generality I think we are disagreeing in
principle. Which isn't to say there is a right answer and one of us is an
idiot, just that there are things to consider carefully here.

IMHO you are hacking kernel policy by a magic flag to support a specific
problem case, not fixing the problem. The question is whether the problem
needs fixing 8)

Alan