> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/