what's relationship between VFS inode and ext3_inode?

[Zhang Shukun]

thanks! your reply it's very useful to me!!

yes, it' security purposes! i just trust dom0 , but not trust domU. i want
to save the blocks of improtant files of domU into dom0, when write
operation happend in domU, domU will send the request struct , which contain
the sectors need to write, to dom0, next, in dom0 compare the sector number.
if the sector numbers is which i want to protect, the write operation will
be stoped by dom0. even if intruder  get the root privilege in domU, he
can't change the file (for example :files in /bin dir) which i protected.

now, another question confused me:

in the request struct , there are two group of sector info. and i don't know
what's the diff between them. and how to get the all sector numbers of a
request for a file?

    sector_t sector;        /* next sector to submit */
    unsigned long nr_sectors;    /* no. of sectors left to submit */
    /* no. of sectors left to submit in the current segment */
    unsigned int current_nr_sectors;
/***************************************************************************************************/
    sector_t hard_sector;        /* next sector to complete */
    unsigned long hard_nr_sectors;    /* no. of sectors left to complete */
    /* no. of sectors left to complete in the current segment */
    unsigned int hard_cur_sectors;

Thanks very much!

2009/6/2 Theodore Tso <tytso at mit.edu>

> On Tue, Jun 02, 2009 at 08:05:48PM +0800, Zhang Shukun wrote:
> > thanks for your answer!
> >
> > my goal is : in kernel space , get the specific disk block numbers(or
> sector
> > number) of a file(such as /bin/ls).
> >
> > because i want to use the block number in DomU, which is a VM in xen.
> when i
> > read or write a file in DomU, front end driver will send the block number
> to
> > back-end driver Dom0 , and then in dom0 i can check if the block could be
> > write or not.
>
> The filesystem does that already (send the block number to the
> back-end driver) when it wants to read or write the block form the
> filesystem.  If the goal is to do this for security purposes, you
> should be calculating the inode->block mapping in dom0, *not* in domU.
> After all, if you don't trust the domU to enforce the normal security
> restrictions which the kernel enforces, why would you trust domU to
> give you the correct inode->block mapping so that dom0 can do some
> kind of security access check?
>
> In any case, to answer your specific question, to convert from a
> struct inode to a struct ext3_inode_info, *if* you know that a
> particular struct inode from an ext3 filesystem (as opposed to an ext2
> filesystem, ext4 filesystem, FAT filesystem, a networking socket,
> etc.) you can use the EXT3_I function to get from an struct inode to
> struct ext3_inode_info:
>
> static inline struct ext3_inode_info *EXT3_I(struct inode *inode)
> {
>        return container_of(inode, struct ext3_inode_info, vfs_inode);
> }
>
> What happens here is that the struct inode is actually embedded inside
> the ext3_inode_info structure, and what is cached is the
> ext3_inode_info structure.  So container_of() basically takes a
> pointer to the struct inode, and substracts the offset from the
> beginning of ext3_inode_info and the vfs_inode element in
> ext3_inode_info, to get a pointer to the struct ext3_inode_info.
>
> If this isn't an ext3 inode, though, your kernel code will likely
> crash from the nonsense it will get when it tries to interpret data
> that isn't a struct ext3_inode_info.  In general, the *only* place
> where well-written, maintainable, kernel code should try to use EXT3_I
> is inside fs/ext3/*.c.
>
>                                        - Ted
>



-- 
Best regards,
张树坤
北京理工大学，计算机科学技术学院
Sucan
Computer Department,Beijing Institute of Technology,China
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/ext3-users/attachments/20090602/2f5917e9/attachment.htm>