> Famous last words, after a few hours of debugging mixed with vm patches
> and emails, I finally got around finding the real bug. The fact is that
> the secure-ramdisk logic was totally broken, not just for initrd, oh
> well, so please don't apply such patch (code in mainline has the
> security issue if you allow an luser to read from /dev/ram0, but it
> isn't buggy). and the issue is quite unfixable with just a PageSecure
> set inside rd.c. The fact is that I cannot just clear-around the
> written "bh", around there could be the source for the next block to
> write and I cannot zero it out. It is getting harder to fix this one
> just inside the ->make_request callback... Hints?
Well, taking a file on ramfs and doing losetup on it should be equivalent
to ramdisk. Turning relevant pieces into a driver shouldn't be too hard.
It won't be pretty, though - you'll probably want different
address_space_operations, so that read()/write() wouldn't bother with
requests at all.
-
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/