lkml.org 
[lkml]   [2000]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: What's wrong with IDE patch and what proper solution should be (Re: disk-destroyer.c)
On Sun, 23 Jul 2000, Khimenko Victor wrote:

> 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 ?

What sort of command did you think it was - telepathic toaster controls?
It's a kernel service. It's the kernel's problem if anything's wrong with
it.

> >> 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.

I don't want the kernel allowing userspace to chuck arbitrary crap around.

> >> 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.

Unfortunately, hardware cannot do this reasonably: that's the OSs job.

> > 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.

No: I do not allow the electrician to come in with a nuke. Destroying my
house with a screwdriver and a pair of pliers would be quite a challenge.

> You trust him to do dangerous things so he can fulfill his(her) duties.

Exactly the point: I do NOT allow him to wire the bath taps up to the live
wire. He is allowed to replace a circuit breaker, or a broken light switch
or whatever, and that's ALL he is allowed to do. No nuclear weapons, no
plumbing tools, just access to the components he is permitted to service.

NOTHING should be permitted to get close to rewriting the firmware. If we
want a firmware rewrite facility, we'll provide one. If not, userspace
can't rewrite firmware.

> 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.

No - you do not give that power to anyone, because it is never actually
needed.

> >> 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 :-)

At which point, there is NO legitimate use for raw IDE commands from
userspace.

> >> 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.

If we are providing the correct API to userspace, and are given enough
information on the drive, there is no need for binary anything - just a
kernel firmware driver. Intel have supported this for their processors -
the HDD manufacturers will probably do the same.

> 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...

Once the bypass option is removed, their program no longer works without
changes. I don't have the low-level info on how to write this interface,
only Andre does - and I think he's busy writing FreeBSD code now :-)

However, if and when I get the information and other resources to write
such support, I will do so.

> > 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 ...

Yes - so we need another solution for 2.4. Block off the suicide calls,
leave the necessary functions with a big "This is DANGEROUS and will be
REMOVED in 2.5.0" or similar.

> > 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.

The crappy interface will be completely replaced in 2.5.0 anyway, crap and
all.

> > 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.

"Guess" is the wrong word. However, yes, I know it selectively blocks out
SOME userspace IDE commands. I would prefer to block them all out, but
that's not practical now, so we'll have to settle for second best - block
what we can.

> > Indeed - we need a kernel interface good enough for XFree86 & co to use
> > instead.
>
> This is not even 2.5 task I afraid.

It can be done already using the framebuffer support, although that costs
you hardware acceleration access. Long term, X itself needs a major
overhaul anyway...

> > 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 !

I never suggested it entailed "new OS design principles" - it's just a
matter of designing and coding a block to a dangerous API call, to serve
as a stop-gap until that API can be removed entirely.

> > 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.

It's a risk, yes. The current situation is complete shit, the proposed
stop-gap is pretty crap. Since you admit any more major improvement is
impossible, we should stick with "pretty crap" for the time being.

> > 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.

Andre's patch is far too big for what it is supposed to do. However, the
fundamental idea (block the API calls which shouldn't exist in the first
place) is fine.

> >> 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 :-)

No, MS just arms everyone to the teeth and hopes MAD will sort out any
problems.

> Disarment, on other hand, it great thing. But it's not
> what you want to do in hurry.

Agreed - it's not an option ATM.

> > 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 the sane replacement is actually needed, it will be written. Either
updating HDD firmware IS needed, in which case the support will be done,
or it isn't, in which case we leave a simple block in place. Neither route
leaves huge amounts of crap in the kernel. I don't know WTF was in Andre's
patch besides the block needed, but there's something BIG added...

> > 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.

The second part may not even be needed. One if statement is hardly the end
of the kernel.

> > 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.

Remove the "do arbitrary crap" API - it should never have existed. If some
other feature is needed, it will be added - that's another issue.

> > 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.

I'm not advocating a micro-kernel approach - quite the opposite, in fact.
I want the kernel to do all the hardware-related work, giving userspace a
nice, uniform, stable, secure platform to work on.

> > 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.

Remove the raw crap interface first. If someone needs a feature it used to
provide, implement that properly at a later date.

> > 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.

I doubt Netscape designed their browser with low-level diagnostics in
mind...


James.


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

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.106 / U:0.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site