Bug 176124 - Use reserveInitialCapacity for Persistent and Argument decoders
Summary: Use reserveInitialCapacity for Persistent and Argument decoders
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: youenn fablet
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-08-30 14:09 PDT by youenn fablet
Modified: 2021-04-23 08:19 PDT (History)
9 users (show)

See Also:

Attachments
Patch (2.80 KB, patch)
2017-08-30 14:13 PDT, youenn fablet 		no flags Details | Formatted Diff | Diff
Patch (2.44 KB, patch)
2017-08-30 14:23 PDT, youenn fablet 		no flags Details | Formatted Diff | Diff
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description youenn fablet 2017-08-30 14:09:29 PDT 
Small optimization.
Comment 1 youenn fablet 2017-08-30 14:13:07 PDT 
Created attachment 319398 [details]
Patch
Comment 2 youenn fablet 2017-08-30 14:13:50 PDT 
This is usually a win.
I wonder though whether we want this in case of corrupted data.
We might end-up allocating very large memory chunks for nothing.
Comment 3 Chris Dumez 2017-08-30 14:16:18 PDT 
Comment on attachment 319398 [details]
Patch

Not OK for IPC for security reasons. This has been discussed in the past.
Comment 4 youenn fablet 2017-08-30 14:23:32 PDT 
Created attachment 319400 [details]
Patch
Comment 5 Saam Barati 2017-08-30 15:05:58 PDT 
(In reply to Chris Dumez from comment #3)
> Comment on attachment 319398 [details]
> Patch
> 
> Not OK for IPC for security reasons. This has been discussed in the past.

Can you elaborate more or link me to discussion of this, I’m curious. Is this just to defend against large sized things?
Comment 6 Chris Dumez 2017-08-30 15:08:32 PDT 
(In reply to Saam Barati from comment #5)
> (In reply to Chris Dumez from comment #3)
> > Comment on attachment 319398 [details]
> > Patch
> > 
> > Not OK for IPC for security reasons. This has been discussed in the past.
> 
> Can you elaborate more or link me to discussion of this, I’m curious. Is
> this just to defend against large sized things?

It is because you cannot trust the input data (In the case of IPC, the message may come from a compromised process. In the case of persistence, the file on disk may have been compromised/modified). Therefore, you cannot trust that the |size| value matches the number of items encoded. It is therefore unsafe to use uncheckedAppend(). Using reserveInitialCapacity() (as in the latest iteration), is fine AFAIK.
Comment 7 Chris Dumez 2017-08-30 15:10:31 PDT 
(In reply to Chris Dumez from comment #6)
> (In reply to Saam Barati from comment #5)
> > (In reply to Chris Dumez from comment #3)
> > > Comment on attachment 319398 [details]
> > > Patch
> > > 
> > > Not OK for IPC for security reasons. This has been discussed in the past.
> > 
> > Can you elaborate more or link me to discussion of this, I’m curious. Is
> > this just to defend against large sized things?
> 
> It is because you cannot trust the input data (In the case of IPC, the
> message may come from a compromised process. In the case of persistence, the
> file on disk may have been compromised/modified). Therefore, you cannot
> trust that the |size| value matches the number of items encoded. It is
> therefore unsafe to use uncheckedAppend(). Using reserveInitialCapacity()
> (as in the latest iteration), is fine AFAIK.

I tried to find the bugzilla where this was previously discussed but could not find it.  I remember it was my patch and Anders explained to me why this wasn't OK though.
Comment 8 Darin Adler 2021-04-23 08:19:16 PDT 
We have decided not do to this, as Chris says.