[PATCH weston 7/9] compositor-drm: fix uninitialized bytes on modeinfo

[Pekka Paalanen]

On Mon, 12 Feb 2018 13:15:45 +0000
Daniel Stone <daniel at fooishbar.org> wrote:

> Hi Pekka,
> 
> On 12 February 2018 at 13:11, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > On Mon, 12 Feb 2018 12:59:22 +0000 Daniel Stone <daniel at fooishbar.org> wrote:  
> >> On 12 February 2018 at 12:51, Pekka Paalanen <ppaalanen at gmail.com> wrote:  
> >> > I believe nothing is depending on the values of implicit padding bytes
> >> > in structs anyway, if such happen to exist and if compiler would happen
> >> > to leave them uninitialized.  
> >>
> >> Hmm. On the other hand, if the ={} form only zeroes bytes accessible
> >> via members, might this caveat not defeat the purpose of the patch?
> >> IOW, if there is implicit padding not cleared by this assignment form,
> >> but something is copying the entire size of the struct, that may be
> >> treated as a read from uninitialised memory.  
> >
> > True. The same caveat applies to anything we initialize without a full
> > memset. I'd think it to be so common though that tools like Valgrind
> > might have special-casing there.  
> 
> Part of the point of the Valgrind warning is to avoid information
> leaks. If you transmit uninitialised bytes somewhere - e.g. from
> compositor to client - then you could be disclosing information you
> shouldn't. It's harmless in this case, but Valgrind can't know that.
> In the general case though, it seems better to be totally sure, if
> that guarantee isn't made by the C standard.

Yes, that warning happens on syscall. I was thinking about
memcpy'ing stuff around otherwise.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180212/d4a12450/attachment.sig>