Packet Size Mismatches

[Patrick Venture]

On Wed, Jan 9, 2019 at 9:10 AM Patrick Venture <venture at google.com> wrote:
>
> Per the maximum response size patch
> (https://gerrit.openbmc-project.xyz/15743), the goal is to know how
> many bytes can be returned by the channel.  This can vary by channel,
> per the comments, and other related changes.  However, presently,
> we're seeing a memory corruption over kcs which has a limit of 256.
> So, we're copying way too much data onto the response.  The code
> itself has no idea how many bytes it can send.
>
> https://github.com/openbmc/phosphor-host-ipmid/blob/master/ipmid.cpp#L409
> is a 64-byte buffer, but the ipmi message could ask for data beyond
> that, and leads to a blind memcpy situation.
>
> If I'm reading that patchset (not yet merged) correctly
> (https://gerrit.openbmc-project.xyz/16285) it lets the IPMI client
> request channel information to know the maximum it can request.
> However, what lets the code running ask that question?  How does my
> library know it's responding to a legal request?  Or is the idea that
> with the reworking that's underway it'll only be able to provide legal
> responses automatically for the channel on which the request came?

It looks like that method is in an installed header, and should be
accessible from downstream callers, however, how does a downstream
caller know the channel through which their request came?

>
> (Also, unrelated, but at some point is the goal still to have one
> daemon handle all ipmi traffic, including network ipmi traffic, via a
> bridge similar to kcsbridge and btbridge?)
>
> Patrick