In <Pine.LNX.4.10.10007231202420.7958-100000@dax.joh.cam.ac.uk> James Sutherland (jas88@cam.ac.uk) wrote:
> On Sun, 23 Jul 2000, Khimenko Victor wrote:
>> JS> We need the extra pair of capable() calls, yes. We should also have sanity
>> JS> checking in the kernel: usermode shouldn't be given this sort of power
>> JS> directly, it should go through a proper, sanity-checked API. Just look at
>> JS> the flak MS took for not sanity-checking all the WIN32K.SYS functions...
>>
>> Not exactly. We NEED sanity checking in kernel and we HAVE it. Just
>> HDIO_DRIVE_CMD is NOT kernel command.
> Wrong.
Hmm. Why ?
>> It's mere interface to IDE bus so you can send ANY commands to IDE
>> bus.
> That's better: it's a kernel facility to send arbitrary crap around.
If you want.
>> Checking in this case DOES NOT belong to kernel - it's HDD duty.
> Good idea. How about deciding the HDD should handle partition tables, too?
When someone has access to HDIO_DRIVE_CMD he ALREADY got credits from kernel
to kill every partition table in system and destroy every filesystem (even
without two-lines patch). He got acess to destroy and rewrite kernel inself
(in memory and on disk - this is with two-lines patch). He got access to raw
hardware. At this stage THE ONLY thing not allowed for such person is to
destroy hardware physically. And it's hardware duty to protect itself.
> How about filesystems?
See above.
> Better still, abandon IDE and SCSI: just define all storage devices to come
> as DIMMs and implement a hardware mmap()...
Do not make itself rudiculous. Electrician can destroy your house with easy.
You trust him to do dangerous things so he can fulfill his(her) duties.
The same is for program with CAP_SYS_RAW: you give such program IMMENSE power
and hope it'll be used for good, not for bad.
>> Do we need such dangerous interface in kernel
> No - it should be an internal facility only.
See below.
>> and do we need it to be used for trivial tasks like putting drive in
>> sleep ?
> Again no, there should be a legitimate kernel interface for "put drive to
> sleep" which userspace then uses.
With this part I agree :-)
>> IMHO no for second question and yes for first one (firmware upgrades
>> can be needed not only for crackers, you know).
> Firmware upgrades should be done via the firmware upgrade interface from
> the kernel, NOT via a "do arbitrary crap" interface.
In perfect world - yes. We do not live in ivory tower, sadly :-( For now the
only hope is to get binary program for that from vendor. And it's MUCH safer
to use binary program, then binary module. Perhaps I'll not use such program
anyway, but there are enough peoples who will.
>> But if we think it's too dangerous interface to leave it in kernel at
>> all then Al Viro is right:
>> -- cut --
>> Umm... Which may very well mean that
>> a) set of commands provided by protocol is misdesigned
> Not really - it just shouldn't be exported to userspace.
>> b) we would be better off if we had reasonable set of commands
>> (preferably the text ones) that could be written to /proc/ide/hd<x>/cmd,
>> so that hdparm would become an equivalent of echo [commands] >/proc...
> Yep.
>> c) ->write() for that file doing all needed locking.
> Yep: keep all the implementation details abstracted into the device
> driver.
>> -- cut --
>> If we found that we have bad [dangerous] design to serve some tasks we
>> SHOULD NOT try to add band-iads over bad-aids (THIS is Microsoft's style
>> indeed).
> Indeed. Long term aim: kill this sort of crap entirely, providing an API
> with proper facilities for "put drive to sleep", "upgrade drive firmware"
> etc.
Do you volunteer to do so ? Do YOU volunteer to WRITE this sane interaface
and then PUSH (real hard!) all program writers to use this sane interaface
while "our programs works just fine without any changes - go away" is most
common responce ? Hmm...
>> We should remove it from kernel completely (may be have code
>> ifdef'ed but NOT turnable via make *config) and replace it with sane
>> interface. Most tuning can be done with commands like
>> echo unmaskirq:1 > /proc/ide/hda/options
>> SO why not extend this interface slightly to cover also standby mode and
>> xfer rate ? Then set of commands in NOT unknown (we designed it!) and
>> we can sanity check arguments, try to prevent destructive operations, etc.
> Agreed - that was my long term aim all along. It's just too late to make
> this switch for 2.4.0, I suspect.
And this is my point :-) It's too late to make this switch in 2.4.0, let alone
to backport it to 2.2.x and 2.0.x ...
>> JS> Potentially dangerous hardware-dependent things should be done by/via the
>> JS> driver for that hardware, NOT by handing userspace a nuke and pointing it
>> JS> at the target!
>>
>> I'm not so sure. What about CD-R, scanners, video and so on ? Do we REALLY
>> need drivers for all this stuff in kernel ? Perhaps. But IF it's true then
>> proper way to fix problem is to REMOVE "raw IDE I/O" and "raw SCSI I/O"
>> interfaces from kernel and replace it with drivers for ALL possible IDE
>> and SCSI device. EVEN if it's "way to go(tm)" (I'm not so sure it is) we
>> can not do it for 2.4 anyway.
> 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.
I know what we SHOULD NOT do: we SHOULD NOT add crap to kernel. Once crap is in
kernel it's VERY hard to remove it from there. While crappy interface is still
available program developers WILL NOT rewrite program to use new, sane one.
>> >> JS> We NEED to block this function somehow.
>> >>
>> >> We can not.
>>
>> JS> Why not? All the uses you mention should be done through a proper kernel
>> JS> API - NOT by userspace things on a "trust me, I'm being run by root"
>> JS> basis.
>>
>> It is done on this basis now. It's big paradigm shift. MAY BE (just may be)
>> we need such a shift. But Andre's patch is not even step in this direction.
>> Quite an opposite.
> How so? If it blocks out some of the direct arbitrary crap, it's a step in
> the right direction.
HAVE YOU LOOKED ON PATCH ? It takes this IDE command ORIGINATED IN USERSPACE
and then it tries to guess if it's safe to push this command on IDE bus. THAT
is the patch you are advocating.
>> >> JS> Nope - /dev/kmem is gone.
>> >>
>> >> How so ? You are not using XFree86, right ? Then you can remove CAP_SYS_RAW
>> >> from system and be happy.
>>
>> JS> So it has gone. That's my point.
>>
>> You can do this on your router and perhaps even on your web-server.
>> You can not do this on desktop workstation. Not while such access is
>> needed by XFree86.
> Indeed - we need a kernel interface good enough for XFree86 & co to use
> instead.
This is not even 2.5 task I afraid.
>> JS> The proposed patch was deleted from zeus shortly after upload, so I can't
>> JS> look at it. I'm not interested in what that specific patch actually does -
>> JS> it's the *design* that matters, and THAT is what is being discussed.
>>
>> How you can discuss design if you not even looked on it ?
> Very easily. Design != source. Design precedes source, unless you're on a
> doomed project. Design the product BEFORE you start building it, not
> after!
Grrr. Then you are an IDIOT. Really. We are NOT discussing "new OS design
principles". We are discussing some VERY specific part of EXISTING, WRITTEN
AND DISTRIBUTED project and talk about ways to fix this situation. To discuss
THIS without looking in code you must be an IDIOT indeed. We CAN NOT "design
product BEFOERE you start building it". It's WAY TO LATE: this product ALREADY
DESIGNED, WRITTEN and DISTRUBUTED for MILLIONS of comuters out there. Wake
up !
>> Gosh. Design of proposed patch is simple: leave this dangerous
>> "straight to hadrware" interface in place. Do not replace it with
>> proper interface. Just try to filter commands send to IDE bus and
>> allow only "good ones". Not a way to go IMO.
> If we divide use of the direct API into two categories, legit and
> non-legit, it seems clearer. We need to block out both; the former needs
> to be replaced by a proper API, the latter can just disappear. Andre is
> trying to delete the latter category; we can deal with the former at a
> later date.
It's way called "add crappy solution for now and develop sane way to handle
situation later". It was tried MANY TIMES. 99% the end result is "add crappy
solution for now and forget about this". So the end product is just pile
of crap added to fix something in hurry and stucked forever.
>> JS> Yep - Linux would be fscking broken otherwise.
>>
>> Not at all. If there are exist bad arguments for open(2) call (in 2.2.15 there
>> WERE such arguments: you can open(2) a socket and then get nasty problems with
>> kernel) then open(3) call should be fixed, NOT fopen(3) function in GLibC.
>> If ability to push ANY packet to network is dangerous then protect it with
>> capability and give sane interface for normally used (TCP/IP) packets.
>> That's how kernel is designed. If you want band-aids to avoid the "obvious"
>> holes... you know where to find it.
> I want a nice sane API, which provides proper services. A function of "do
> arbitrary crap with chunks of binary data" doesn't fall into this
> category.
It's not argument to add more crap in kernel. Really.
>> JS> No, this sort of direct access is not legitimate. It should be done
>> JS> through a proper sanity-checked API. The "give userspace a nuke and pray"
>> JS> approach belongs in Redmond-born OSs, not Linux.
>>
>> Not exactly. Userspace has beed give MANY nukes in Linux.
> Time for a disarmament treaty, then. Or SDI :-)
SDI is vetoed by Linus. You do not like it - go to Microsoft camp. There are
SDI is thriving :-) Disarment, on other hand, it great thing. But it's not
what you want to do in hurry.
>> Especially for root. But it's just stupid to give userspace nuke and
>> THEN try to prevent misuse of that nuke. THIS is Microsoft way indeed.
> Yes - so take the nuke away. Andre is taking part of the nuke away with
> his patch; the rest can follow later.
No. This was was tried MANY TIMES. Rest will NEVER follow. Unfortunate but
true. Peoples who can develop sane solution will think "ok, it's somehow
handled so better to spend our energy for other projects". Linus knows this
VERY well. THAT's why such patches are rejected UNLESS threat if REAL big.
Looks like you are NEVER worked for big project.
>> If this nuke with full power is not needed in userspace then why to
>> give it in first place ?
> Because SOME of the power IS needed, some of the time, ATM. Take away as
> much of it as possible now, then replace the remainder with conventional
> weapons and remove the rest.
The same history all the time: first part can be done. But if you'll do this
you'll lost [almost] all hope to do second.
>> If (when) it is NEEDED in userspace in full glory and uglyness (when
>> you want to upgrade firmware for real :-)
> You do NOT need a "do arbitrary crap" interface to upgrade firmware. You
> need an "upgrade firmware" interface.
See above. In indeal world - yes. In real world - no.
>> it's needed there and we should not try to second-guess if it's needed
>> there for real.
> It is NEVER needed, unless the API we are currently providing is
> inadequate - in which case, fix the API. Don't hand out nukes on the door.
This is GREAT theory. As ny great theory it [almost] NEVER works on practice.
Micro-kernel is GREAT in theory. Still in real world micro-kernel based OSes
are SUCKS.
>> JS> This is exactly the sort of hardware-dependent detail which the kernel
>> JS> driver should handle, NOT leave up to userspace.
>>
>> 1. GENERIC kernel drive can not handle it.
> Nor can a generic userspace app. So what?
>> 2. We are allowing "raw I/O IDE bus" or refusing it. Filtering is just wrong
>> approach. If you need some things to be done with IDE device (change in xfer
>> mode, standby/sleep, Seagate auto-standby regulation, etc) driver should
>> provide sane interafaces for such needs (BTW it can check is you are trying
>> to disable auto-standby with Seagate-specific command on Seagate and not
>> on WD :-)
> If the kernel is providing an adequate API, we no longer need ANY aspect
> of the "raw crap" interface. In the mean time, we need SOME aspects - but
> should block the rest.
See above. If you'll do this now you will NEVER got to the point where you
do not need "raw crap" interface.
>> >> (think about things like Western Digital's activeX app to do low-level
>> >> disk diagnostics).
>>
>> JS> Oh, yes - very useful. I really want a piece of WWW page to be able to do
>> JS> low-level things to my hardware. If you think that's a genuine feature, go
>> JS> back to Redmond and resume patching QDOS derivatives.
>>
>> It IS genuine feature. If we need such feature or not is other question
>> entirely.
> I don't want to do low-level hardware stuff via a WWW page. Netscape is
> NOT a system level diagnostic tool, so do NOT try to give it low-level
> access like that!
It's only your opinion.
-
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