In <Pine.LNX.4.10.10007261155410.17041-100000@dax.joh.cam.ac.uk> James Sutherland (jas88@cam.ac.uk) wrote:
> On 25 Jul 2000, Krzysztof Halasa wrote:
>> James Sutherland <jas88@cam.ac.uk> writes:
>>
>> > On Tue, 25 Jul 2000, Stuart MacDonald wrote:
>> >
>> > > Which is exactly the point. The hard drives should be checking for
>> > > invalid ATA commands in hardware, right in the drive, preventing
>> > > damage from bad commands. Putting a filter into the kernel is not
>> > > the right fix.
>> >
>> > As with some of the Intel CPU bugs, the problem is NOT "invalid ATA
>> > commands" - it's a matter of VALID commands which are dangerous. FDIV on
>> > early Pentiums isn't an invalid instruction - it just produces the wrong
>> > results at times. So the SOFTWARE must do something to avoid this - either
>> > that, or you need to replace the hardware, which isn't desirable. You do
>> > something in the OS to prevent these problem commands being used.
>>
>> So what does the kernel (can) do to prevent this problem on defective
>> pentiums?
> Trap the defective instructions, and implement a replacement instruction
> in software. On later Intel CPUs, you can sometimes use a microcode update
> to fix it - this also requires OS intervention.
> Either way, essentially you tell the OS to block the duff instructions,
> and it does so.
Exactly. You are ONLY blocking "duff instructions" to workaround bug in
hardware. You are not trying to standardtize life.
Why not add filters in fs/exec.c so only "good commands" can be executed ?
And when new program is developed you "only" need to get approval in
"linux-programs committee": kernel only need to know that it's now safe
to execute gcj - it's safe "GNU Java Compiler", not some malicious code.
What's the difference ? There are exist "standard" commands (see POSIX)
and there are conutless "vendor-specific extensions". Why not limit itself
to standard commands and to not change standard when new program is wanted ?
You can destroy not only HDD but a lot more with malicious or buggy setuid
program in typical system.
-
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 : Mon Jul 31 2000 - 21:00:21 EST