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

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: <50979E3C.7030309@redhat.com>
Date:	Mon, 05 Nov 2012 12:08:44 +0100
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	Tejun Heo <tj@...nel.org>, Ric Wheeler <rwheeler@...hat.com>,
	Petr Matousek <pmatouse@...hat.com>,
	Kay Sievers <kay@...hat.com>, Jens Axboe <axboe@...nel.dk>,
	linux-kernel@...r.kernel.org,
	"James E.J. Bottomley" <James.Bottomley@...senPartnership.com>
Subject: Re: setting up CDB filters in udev (was Re: [PATCH v2 0/3] block:
 add queue-private command filter, editable via sysfs)

Il 03/11/2012 15:50, Alan Cox ha scritto:
>>> It's not really about the lines of code.  It adds a new userland
>>> visible interface.  As for the "long" list of commands, it depends on
>>> how you write it but even if it's textually long it's still very
>>> simple in terms of actual complexity.
>>
>> Sure, but its place is not the kernel.
>>
>> As to implementing the ioctl, it's all but trivial.  For one thing, you
>> have to make the block device ioctl op take a "struct file".  I have
>> been asking Al Viro about it for 6 months and I haven't got any answer yet.
> 
> Just do it - if Al cared he'd have replied about it.

Yeah, so far I chickened out because---for the usecases I know, at
least---a sysfs knob would be simpler to use.

>> I proposed a way to implement the ultimately flexible solution (BPF) and
>> you shot it down because it was too complex.  Alan is showing you with
>> multiple examples of why the flexibility would be useful (perhaps nobody
>> would use it, but the use cases _are_ there), and you are mostly
>> ignoring them.
> 
> My feeling too - It feels to me like Tejun is trying to railroad a broken
> non-solution into the system

Thanks for spelling it out. :)

> without regards for anyone else and by
> simply dismissing any other input.

My main worry about the BPF implementation is that I need to do CDB
inspection, which is similar to packet inspection but doesn't have an
sk_buff.  The seccomp guys worked around it by using an ANC opcode to
access syscall arguments, but here I really need LD.  This means for
example that it wouldn't be so easy to use the JIT.

These are the usecases that really require BPF:

> - giving people access to parts of disks

This is quite obvious, but I'm not sure why you would that (other than
just because).  It feels a bit strange to give access to part of a disk
with "absolute" LBAs rather than relative.

For people needing access to partitions of LVs, what we really need is
better access to block device features.  We just got BLKZEROOUT, but
access to block devices via fallocate() or lseek(SEEK_HOLE/SEEK_DATA)
would be a more interesting and useful thing to do.

> - giving end users minimal access to things like SMART but only on drives
>   where it is safe

I'm actually in agreement with Tejun that this is handled more than
decently by udisks.  And the reason this needs BPF, is because the ATA
command set is incredibly complicated.  If there were request, SMART
access could be moved to the kernel/libata and use sysfs+uevents.  This
is similar to how media change is in the kernel, and SCSI disks allow
limited access to mode pages via sysfs.

These uses instead are fine with a bitmap:

> - giving a user a SCSI disk or partition to play with but preventing them
>   issuing weird ass commands that can disrupt other devices in the fabric
>   (like drive to drive transfers, some kinds of resets, management
>   commands)
> - allowing access to specific vendor specific commands on certain
>   non-standard CD and DVD drives so they can be used for burning but you
>   can't trash them
> - minimising the ability of a VM to do damage if compromised while
>   maximising its raw access to a device

(I'm obviously trying to champion my own patches, but I'll try to be
open minded about it). :)

Paolo
--
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/