[rtems commit] New fstest to cover RFS bitmaps - fsrfsbitmap01

Krzysztof Mięsowicz krzysztof.miesowicz at gmail.com
Mon Oct 22 09:54:56 UTC 2012


Hi


> Chris will need to be final ruler on this but if the code is written to
> assume that it is always passed a valid pointer, then you have to
> honor this in the testing.  You can add a debug-enabled consistency
> check that the control pointer is NULL. But you shouldn't pass it in
> if it is not checked in a production build.
>

I'm looking into RFS source and I think you are right. Most of this
functions I tested with null control pointer is used in functions where
bitmap control pointer is correct because it is initialized with
bitmap_open function and there is check if it is successful. I invoked this
functions with null control pointer to cause rtems_rfs_bitmap_load_map to
fail. It can fail when control.buffer is null or when buffer handle request
fail.

Do anyone know how could I cause rtems_rfs_buffer_handle_request to fail? :)


> The question is.. is this code comparable to the score core
> which is only invoked by trusted layers? If so, it doesn't need to
> check for NULL and you shouldn't pass in a "control = NULL"
>
> I think this code is comparable to score core. I check in RFS source where
these functions are used and if there is possibility to pass bad pointer to
these functions and below are results of my quick research:

bitmap_set
1. used in write_group. First there is opened buffer handle which is next
passed to the rfs_bitmap_open and there are checks for both operations. So
bitmap control pointer can't be null and is correct.

bitmap_map_clear
1. used in group_bitmap_free. bitmap control pointer is taken from
fs->groups[group].(inode/block)_bitmap
So if fs pointer is correct bitmap control is also correct.

bitmap_map_clear_all
1. used in write group. Like map_set bitmap control pointer is always
correct.

bitmap_map_test
1. used in group_bitmap_test. bitmap control pointer is taken from
filesystem. So I think it is correct.

bitmap_create_search
1. used in bitmap_open. If bad buffer handle pointer would be passed to the
function it could go bad path.

bitmap_map_alloc
1. used in group_bitmap_alloc. bitmap control pointer is taken from
filesystem. I think I would have to corrupt filesystem structure to pass
earlier checks and then it can break rfs_bitmap_map_Alloc.

>From what I understand users don't invoke these functions. They would
rather make use of posix functions like open(), write() etc. and these
bitmap functions are the lowest layer of whole RFS.

Krzysztof Miesowicz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20121022/06a753e1/attachment-0001.html>


More information about the devel mailing list