Messages in this thread |  | | Date | Fri, 21 Sep 2001 01:03:40 +0200 | From | Andrea Arcangeli <> | Subject | Re: Linux 2.4.10-pre11 |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |