James Sutherland <jas88@cam.ac.uk> writes:
> > Not exactly. We NEED sanity checking in kernel and we HAVE it. Just
> > HDIO_DRIVE_CMD is NOT kernel command.
>
> Wrong.
What's exactly wrong?
> Again no, there should be a legitimate kernel interface for "put drive to
> sleep" which userspace then uses.
Right.
> Firmware upgrades should be done via the firmware upgrade interface from
> the kernel, NOT via a "do arbitrary crap" interface.
There are different drives and different drive manufacturers, all of them
using different upgrade methods. Most of the info is not publicly
available. While I can imagine driver manufacturers make disk utils
(which use raw ioctl interface) available, I don't think it's possible
they soon start to write any necessary kernel modules.
> Agreed on both counts - so what DO we do for 2.4 in the mean time? IMO, we
> should block as much of the "arbitrary screwing with hardware" API as
> possible for now, and block the rest out later once we have a proper
> replacement.
Should we block firmware updating or not? The patch blocked it.
Without blocking it, you gain exactly nothing.
> How so? If it blocks out some of the direct arbitrary crap, it's a step in
> the right direction.
Does firmware updating count as this crap, and thus it should be
impossible? If you have interface for updating the firmware, you
have a way to destroy the HDD - just use incorrect firmware.
> Indeed - we need a kernel interface good enough for XFree86 & co to use
> instead.
Right.
> If we divide use of the direct API into two categories, legit and
> non-legit, it seems clearer.
Does flash update command fall into legit category or not?
> Yes - so take the nuke away. Andre is taking part of the nuke away with
> his patch; the rest can follow later.
As well as he's taking flash updates away.
Well, let's compare:
current (+CAP_RAW bug fixed) interface:
+ smaller kernel size
+ all IDE commands (incl. proprietary ones) are handled allowing
for simple diagnostics tools from hw makers
+ disabling raw caps you disable access at hardware level.
- otherwise rogue root can erase drive firmware
No raw ioctl + all-in-kernel interface:
- larger kernel size
- every diagnostics tool need special kernel module from hw maker
- rogue root can still damage the drive using flash update
(or any other suitable) interface.
The original patch:
- larger kernel size
- no possibility to use any diagnostics tools
- rogue root can still damage the drive using any suitable interface
probably unless raw caps are revoked.
Of course I agree there should be better way to, for example, put
a drive into sleep, and it probably shouldn't require raw caps
(could a drive be destroyed be using this?). This is a minor thing
anyway (and a patch which adds such interface would be 10 lines long).
-- Krzysztof Halasa Network Administrator- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:20 EST