From: Andrea Arcangeli <andrea@suse.de>
To: Alexander Viro <viro@math.psu.edu>
Cc: Linus Torvalds <torvalds@transmeta.com>,
Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Linux 2.4.10-pre11
Date: Fri, 21 Sep 2001 01:03:40 +0200 [thread overview]
Message-ID: <20010921010340.L729@athlon.random> (raw)
In-Reply-To: <20010921003136.H729@athlon.random> <Pine.GSO.4.21.0109201835320.5631-100000@weyl.math.psu.edu>
In-Reply-To: <Pine.GSO.4.21.0109201835320.5631-100000@weyl.math.psu.edu>; from viro@math.psu.edu on Thu, Sep 20, 2001 at 06:44:18PM -0400
On Thu, Sep 20, 2001 at 06:44:18PM -0400, Alexander Viro wrote:
>
>
> On Fri, 21 Sep 2001, Andrea Arcangeli wrote:
>
> > Of course, however if you want I can first fix initrd (I was just
> > looking into it in the last minutes), the security fix broke initrd
> > badly unfortunately [didn't tested initrd but just the ramdisks before
> > posting it] (not sure why initrd broke at the moment but I believe the
> > design of the fix was the right one, so it is probably an implementation
> > detail). So unless you need it urgently I will try to fix initrd first,
> > then I will send to you so you can go ahead without risk of future rejects.
>
> I'd suggest to stop treating initrd as block device. It has to keep
> S_IFBLK in mode bits, indeed, but I'd rather set ->f_op upon open() and
> stop worrying about it.
>
> We don't need buffer-cache access to it anyway - if you look carefully
> you will see that we actually copy its contents to normal ramdisk
> first. So just having ->read() (essentially copy_to_user()) is
> perfectly OK.
of course, we never used initrd blkdev, we just use the ramdisk always
from userspace. Initrd doesn't need to be a blockdev, we could just
copy the ram ourself and just call ->write on the ramdisk. userspace
just sees /dev/ram0, /dev/initrd is a kernel internal thing that doesn't
need to be visible, and if anybody uses /dev/initrd somehow that just
insane (and it doesn't even look possible to make anything useful out of
/dev/initrd anyways).
> Check how old code was dealing with it - it's really the best way to
> treat that sucker. We probably will be better off if we make it a
> character device at some point in 2.5 and move the thing to char/mem.c,
> but anyway, it had never been a proper block device (== one with
> requests queue, etc.) and there's no point in making it such now.
>
> Again, the proper way to treat it is to convert it into character
> device at some point. Userland won't actually care - after the
> boot it's gone. And kernel is using it only via ->read(), so
> there's no point trying to make it similar to real ramdisks.
1) I am tentated to fix the initrd bug by just killing initrd blkdev,
completly instead of going to mark PageSecure all the initrd pages.
2) Otherwise I can make a brute hack one liner approch with a global
field that ignores the PageSecure bit on reads until I finished to fill
in the /dev/ram0 :) (slowdown production paths for a boot thing but
doesn't matter, but ok we aren't writing proprietary software here and
this isn't the right thing ;)
3) I can just mark the initrd pages as PageSecure, then I can safely
forget about them.
What do you prefer for the next 2.4.10 mainline? I'd like to have this
fixed _fast_ and to be included in mainline, since the security problem
is ugly (not too bad though since /dev/ram0 is readable only by root by
default) and because people really needs initrd.
Suggestions are very welcome.
Andrea
next prev parent reply other threads:[~2001-09-20 23:03 UTC|newest]
Thread overview: 110+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-18 0:08 Linux 2.4.10-pre11 Linus Torvalds
2001-09-17 23:17 ` Marcelo Tosatti
2001-09-18 1:08 ` Marcelo Tosatti
2001-09-18 3:37 ` Andrea Arcangeli
2001-09-18 2:25 ` Marcelo Tosatti
2001-09-18 3:58 ` Andrea Arcangeli
2001-09-18 2:53 ` Marcelo Tosatti
2001-09-18 4:54 ` Andrea Arcangeli
2001-09-18 3:33 ` Marcelo Tosatti
2001-09-18 5:06 ` Andrea Arcangeli
2001-09-18 3:55 ` Marcelo Tosatti
2001-09-18 5:32 ` Andrea Arcangeli
2001-09-18 4:14 ` Marcelo Tosatti
2001-09-18 5:59 ` Andrea Arcangeli
2001-09-18 5:00 ` Marcelo Tosatti
[not found] ` <20010917211834.A31693@redhat.com>
[not found] ` <20010918035055.J698@athlon.random>
2001-09-18 2:02 ` Andrea Arcangeli
[not found] ` <20010917221653.B31693@redhat.com>
2001-09-18 2:27 ` Linus Torvalds
2001-09-18 3:14 ` Alan Cox
2001-09-18 3:26 ` Andrea Arcangeli
[not found] ` <20010918052201.N698@athlon.random>
2001-09-18 4:01 ` Benjamin LaHaise
2001-09-18 4:39 ` Andrea Arcangeli
2001-09-18 5:04 ` Alan Cox
2001-09-18 5:09 ` Andrea Arcangeli
2001-09-18 5:22 ` Benjamin LaHaise
2001-09-18 5:48 ` Andrea Arcangeli
2001-09-18 5:48 ` Andrew Morton
2001-09-18 6:11 ` Andrea Arcangeli
2001-09-18 5:02 ` Marcelo Tosatti
2001-09-18 6:40 ` Andrea Arcangeli
2001-09-18 16:06 ` Marcelo Tosatti
2001-09-18 19:18 ` Marcelo Tosatti
2001-09-18 21:05 ` Andrea Arcangeli
2001-09-19 13:57 ` Rik van Riel
2001-09-18 10:58 ` Martin Dalecki
2001-09-18 9:31 ` Alexander Viro
2001-09-18 9:39 ` Andrea Arcangeli
2001-09-18 9:44 ` Alexander Viro
2001-09-18 9:57 ` Andrea Arcangeli
2001-09-18 10:02 ` Alexander Viro
2001-09-18 10:17 ` Andrea Arcangeli
2001-09-18 10:28 ` Alexander Viro
2001-09-18 10:35 ` Andrea Arcangeli
2001-09-18 10:52 ` Alexander Viro
2001-09-18 11:05 ` Helge Hafting
2001-09-18 12:40 ` Andrea Arcangeli
2001-09-18 17:02 ` Linus Torvalds
2001-09-18 16:45 ` Linus Torvalds
2001-09-18 18:19 ` Alexander Viro
2001-09-18 18:27 ` Linus Torvalds
2001-09-18 19:14 ` Andreas Dilger
2001-09-18 19:41 ` Alexander Viro
2001-09-18 20:33 ` Richard Gooch
2001-09-18 20:53 ` Alexander Viro
2001-09-18 21:06 ` Richard Gooch
2001-09-18 21:27 ` Alexander Viro
2001-09-18 19:29 ` Benjamin LaHaise
2001-09-18 20:17 ` Stephan von Krawczynski
2001-09-18 20:33 ` Alan Cox
2001-09-19 13:42 ` Rik van Riel
2001-09-19 14:27 ` Alexander Viro
2001-09-19 2:59 ` Michael Peddemors
2001-09-19 16:11 ` Alexander Viro
2001-09-19 18:25 ` Andrea Arcangeli
2001-09-19 19:21 ` Alexander Viro
2001-09-19 20:55 ` Andrea Arcangeli
2001-09-19 21:17 ` Alexander Viro
2001-09-19 23:01 ` Andrea Arcangeli
2001-09-19 23:03 ` Andrea Arcangeli
2001-09-19 23:30 ` Alexander Viro
2001-09-19 23:40 ` Andrea Arcangeli
2001-09-20 13:56 ` Alexander Viro
2001-09-20 14:38 ` Chris Mason
2001-09-20 14:50 ` Alexander Viro
2001-09-20 15:44 ` Chris Mason
2001-09-20 16:43 ` Alexander Viro
2001-09-20 20:54 ` [PATCH] fs/block_dev.c cleanup Alexander Viro
2001-09-19 22:15 ` Linux 2.4.10-pre11 Richard Gooch
2001-09-20 2:34 ` Andrea Arcangeli
2001-09-20 10:52 ` Alexander Viro
2001-09-20 18:18 ` Andrea Arcangeli
2001-09-20 18:33 ` Alexander Viro
2001-09-20 18:59 ` Andrea Arcangeli
2001-09-20 20:41 ` Alexander Viro
2001-09-20 21:18 ` Andrea Arcangeli
2001-09-20 21:40 ` Alexander Viro
2001-09-20 22:13 ` Andrea Arcangeli
2001-09-20 22:20 ` Alexander Viro
2001-09-20 22:31 ` Andrea Arcangeli
2001-09-20 22:44 ` Alexander Viro
2001-09-20 23:03 ` Andrea Arcangeli [this message]
2001-09-20 23:11 ` Alexander Viro
2001-09-21 1:50 ` Alexander Viro
2001-09-21 2:42 ` Andrea Arcangeli
2001-09-21 3:47 ` Andrea Arcangeli
2001-09-21 4:00 ` Alexander Viro
2001-09-21 4:06 ` Andrea Arcangeli
2001-09-21 4:06 ` Andrea Arcangeli
2001-09-21 4:46 ` Andrea Arcangeli
2001-09-21 7:09 ` Andrea Arcangeli
2001-09-19 20:41 ` Richard Gooch
2001-09-19 13:38 ` Rik van Riel
2001-09-19 16:35 ` Andrea Arcangeli
2001-09-18 3:18 Ed Tomlinson
2001-09-18 2:31 ` Magnus Naeslund(f)
2001-09-18 2:49 ` David B. Stevens
2001-09-18 3:38 ` Ed Tomlinson
2001-09-18 3:15 ` Alan Cox
2001-09-18 4:41 ` H. Peter Anvin
2001-09-18 6:14 Alexei Podtelezhnikov
2001-09-18 13:51 ` Rik van Riel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010921010340.L729@athlon.random \
--to=andrea@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
--cc=viro@math.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).