Re: Interrupt handling

[Richard B. Johnson]

On Thu, 16 Oct 2003, Maciej Zenczykowski wrote:

> On Thu, 16 Oct 2003, Richard B. Johnson wrote:
>
> > The memory-map idea has security problems, though.
> > If the area ever gets unmapped (the user exits), a
> > fatal error could occur in kernel mode within the
> > ISR. In general, it's always best to allocate an
> > interrupt-safe buffer within the driver (module),
> > that is guaranteed to persist as long as the driver
> > is installed. This ultimately means that a copy
> > operation is necessary.
> >
> > Memory-to-memory copy is real fast now days. The
> > copy_to_user() is just memcpy() with a trap mechanism
> > that can save the kernel from a user-induced seg-fault.
> > The actual trap is hardware-induced in ix86 machines
> > and therefore adds no overhead to the normal copy operation.
>
> Is there any reason why we couldn't via kernel routine let user space
> access read-only certain pages of kernel memory?  I.e. having the
> userspace function call the driver to map into it's (user) address space a
> read-only mapping of the drivers (kernel) private r/w area?
> If I'm not mistaken this is doable on x86 hardware isn't it?
>
> Cheers,
> MaZe.
>
No reason. From user-space, using mmap, you can read the screen-memory
at 0xb8000, for instance, ........
-d b8000
000B8000  63 09 64 09 72 09 6F 09-6D 09 20 07 20 07 20 07   c.d.r.o.m. . . .
000B8010  20 07 20 07 20 07 20 07-20 07 20 07 20 07 20 07    . . . . . . . .
[SNIPPED]

You can look access many kernel areas that way. The probem is:

(1) When are new data available, and how much.
(2) How do you keep it from being overwritten by the next interrupt
    before it's been read.

These, and other, problems are why there are 'standard' ways of doing
things.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/