<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 3, 2021 at 3:10 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 24/02/2021 18:30, Gedare Bloom wrote:<br>
<br>
> On Wed, Feb 24, 2021 at 9:58 AM Sebastian Huber<br>
> <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>>  wrote:<br>
>> On 24/02/2021 17:54, Gedare Bloom wrote:<br>
>><br>
>>> On Wed, Feb 24, 2021 at 2:52 AM Sebastian Huber<br>
>>> <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>>   wrote:<br>
>>>> On 16/02/2021 06:51, Sebastian Huber wrote:<br>
>>>><br>
>>>>> The issue can be fixed in two ways.<br>
>>>>><br>
>>>>> 1. We change the API, so that the error condition can happen also on<br>
>>>>> 64-bit architectures (current patch).<br>
>>>>><br>
>>>>> 2. We change the specification and implementation, so that this error<br>
>>>>> condition is removed on 64-bit architectures. In the implementation,<br>
>>>>> this is easy. In the specification, this is a bit more difficult since<br>
>>>>> I would have to introduce a new option which enables or disables parts<br>
>>>>> of the specification based on the word size of the architecture<br>
>>>>> (similar to RTEMS_SMP). This is the main reason why I didn't fix the<br>
>>>>> issue immediately<br>
>>>> How do we want to address this issue? Change the API or the<br>
>>>> specification, etc.?<br>
>>>><br>
>>> I'd lean toward 1, except without digging in the details I think the<br>
>>> proposed patch is wrong to use size_t, and the implementation check of<br>
>>> SIZE_MAX. We shouldn't use size_t for a counting variable, that is<br>
>>> wrong. size_t has an implied type of number of bytes. The check should<br>
>>> be against UINT32_MAX if the variable type is uint32_t.<br>
>> This is exactly the problem. Internally, this uint32_t variable is used<br>
>> to compute the allocation size in size_t, which is uint64_t on 64-bit<br>
>> architectures and an overflow cannot happen.<br>
>><br>
> These limits are ridiculous, even on a 32-bit machine no one is going<br>
> to be allocated a 4 GiB message.<br>
><br>
> We should consider specifying the API more tightly. The maximum<br>
> message sizes are currently only constrained by the Workspace Size or<br>
> (for Global) the MPCI message limits. Maybe we should make the<br>
> maximum_pending_messages as uint16_t or even uint8_t, then the<br>
> overflow can't happen on 32-bit machine either.<br>
<br>
The message size is already size_t. The problem is the <br>
maximum_pending_messages. I think that limiting the maximum for the <br>
pending messages to 65535 would be a bit too restrictive.<br></blockquote><div><br></div><div>I know of one satellite that used a message queue to enqueue all data to</div><div>be downlinked when it was out of site of a ground station. It only was visible</div><div>to the ground station 6 hours a day and the queue could get over 100K </div><div>messages.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I will fix the error condition in the specification and adjust the <br>
implementation accordingly without changing the API.<br></blockquote><div><br></div><div>Can the calculation of allocated size be done in terms of uint64_t and </div><div>then we can easily check if the allocation is to exceed UINT32_MAX.</div><div><br></div><div>Then there are no changes to the API and the code doing this should </div><div>be a lot simpler and less prone to error.</div><div><br></div><div>--joel </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
><br>
-- <br>
embedded brains GmbH<br>
Herr Sebastian HUBER<br>
Dornierstr. 4<br>
82178 Puchheim<br>
Germany<br>
email: <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
phone: +49-89-18 94 741 - 16<br>
fax:   +49-89-18 94 741 - 08<br>
<br>
Registergericht: Amtsgericht München<br>
Registernummer: HRB 157899<br>
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler<br>
Unsere Datenschutzerklärung finden Sie hier:<br>
<a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div>