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

From: [email-masked]
Date: Wed, 25 Jun 2003 16:09:06 -0600

If it is advertised once and updated multiple times, then the ULP can meet the requirement by ensuring that data for the first Read has been put into the buffer (e.g. any stale data from another session) before it enables remote read access. Even if this involves extra operations to separately enable remote read access, this may be less of a burden then zeroing out the memory.

It would be reasonable to mention more than one alterntative for how the Local Peer can ensure that stale data is not exposed such as:
>> >   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, 
or by ensuring that appropriate data has been written into the buffer before remote read access is enabled.
>> >   for example).

Regards,
Pat

-----Original Message-----
From: Caitlin Bestler [mailto:[email-masked]]
Sent: Wednesday, June 25, 2003 9:57 AM
To: Michael Krause; [email-masked]
Subject: Re: [rddp] Re: security-draft : Stale Data

<snip>
>
>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.

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

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

---

From: Caitlin Bestler <[email-masked]>
Date: Wed, 25 Jun 2003 18:10:13 -0500

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

> If it is advertised once and updated multiple times, then the
> ULP can meet the requirement by ensuring that data for the
> first Read has been put into the buffer (e.g. any stale data
> from another session) before it enables remote read access.
> Even if this involves extra operations to separately enable
> remote read access, this may be less of a burden then zeroing
> out the memory.

How an application chooses to prepare a buffer that it has
enabled for read is a ULP issue. The tradeoffs between enabling/
disabling in the ULP versus doing so with the local interface
are really out of scope.

But it is not a *security* issue.

Obviously a ULP should ensure that a buffer is not read before
the contents are actually there. But if the wrong contents are
read that is a program error. It is no more a "security" issue
than any program error is. The section in question was dealing
with ensuring that the remote peer not gain access to unitialized
bytes that might contain data that was not supposed to be known
to them. If in fact the only risk is that the remote peer might
read *old* data that was *previously* offered to them, then
there really is no security issue.

My position is that ULP developers are looking for advice that
is specific to RDMA, not general tips on robust programming.
Initializing the buffer *before* it is enabled the *first*
time accomplishes this. There is no *security* reason why
it cannot remain enabled from that point forward even if
its contents are logically void. Just because one component
in a distributed system MUST NOT do X does not mean that
the system MUST, or even SHOULD, be actively configured
to detect/prevent it from doing so. This is especially
true if a violation put no other sessions at any risk.