[Xen-devel] Re: [PATCH 5/6] trace: fix security issues

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Thu, Jul 1, 2010 at 9:49 AM, Jan Beulich <JBeulich@xxxxxxxxxx> wrote:
> Ordering isn't a problem here, but enforcing the read-once
> requirement can be done either way afaict.

I see.  Yeah, I agree with Keir; memory barriers are the right way to
solve this problem.

Can you work up a patch add in the appropriate memory barriers?

 -George

>
>> At least one specific example where volatile helps would be appreciated.
>
> static inline struct t_rec *next_record(const struct t_buf *buf)
> {
>    u32 x = buf->prod;
> *** no read at all ***
>
>    if ( !tb_init_done || bogus(x, buf->cons) )
> *** read buf->prod ***
>        return NULL;
>
>    if ( x >= data_size )
> *** read buf->prod again ***
>        x -= data_size;
> *** x = buf->prod - data_size; (reading buf->prod a third time) ***
> *** else ***
> *** x = buf->prod; ***
>
>    ASSERT(x < data_size);
>
>    return (struct t_rec *)&this_cpu(t_data)[x];
> }
>
> Jan
>
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel