Subject: Re: [rddp] Re: security-draft : Stale Data

From: Michael Krause <[email-masked]>
Date: Wed, 25 Jun 2003 09:22:07 -0700

At 08:37 PM 6/24/2003 -0500, Caitlin Bestler wrote:
> >From 7.4.2 "Using RDMA Read to Access Stale Data"
>
> >   Because of this, it is RECOMMENDED that the Local Peer ensure that
> >   no stale data is contained in the buffer when remote read access
> >   rights are initially granted (this can be done by zeroing the
> >   contents of the memory, for example).
>
>This is only a concern if the buffer might contain data that originated
>outside of the current session. That could be done by zeroing the
>contents of memory at the beginning of the session, rather than
>before advertising the buffer.
>
>If a single buffer pool is used across multiple sessions, however,
>then the ULP should indeed obliterate any old contents before
>enabling it for remote read access.

While I agree in principle, it seems to me that anything enabled for remote 
read is nominally updated to contain new data that one desires the remote 
to read thus I would expect either the region / window to be updated prior 
to the advertisement either with new application data with anything that 
goes beyond the updated address space (one can always advertise more than 
the actual updated data such as array that is sequentially updated / read 
over time) to be zero / randomized prior to it initially being advertised.

Mike

_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Caitlin Bestler <[email-masked]>
Date: Wed, 25 Jun 2003 11:56:56 -0500

On Wednesday, June 25, 2003, [email-masked] wrote:

>While I agree in principle, it seems to me that anything
>enabled for remote read is nominally updated to contain new
>data that one desires the remote to read thus I would expect
>either the region / window to be updated prior to the
>advertisement either with new application data with anything
>that goes beyond the updated address space (one can always
>advertise more than the actual updated data such as array that
>is sequentially updated / read over time) to be zero /
>randomized prior to it initially being advertised.
>

But it may be advertised once, and then updated multiple times.
The ULP may have its own methods of knowing when the advertisement
is logically void. For example B might write to a buffer held by
A, then somehow let C and D know that it has been updated.