On Tue, May 09, 2017 at 08:24:18AM +0100, David Howells wrote:
> Eric Biggers wrote:
>
> > It probably would be easier to kmalloc() this struct and store a pointer to
> > it in key->payload.data[0]
>
> Yeah, but it's a waste of resources if you don't have to do it.
>
> David
Yes, but it seems
On Tue, May 9, 2017 at 1:11 AM, David Howells wrote:
> Kees Cook wrote:
>
>> This doesn't protect you against changes in struct path size,
>> though... the existing code (and this proposal) will break if that
>> ever happens...
>
> True - in which case you should kmalloc() it as Eric suggests.
>
Kees Cook wrote:
> This doesn't protect you against changes in struct path size,
> though... the existing code (and this proposal) will break if that
> ever happens...
True - in which case you should kmalloc() it as Eric suggests.
> What's the problem with defining the types at the top level? T
Eric Biggers wrote:
> It probably would be easier to kmalloc() this struct and store a pointer to
> it in key->payload.data[0]
Yeah, but it's a waste of resources if you don't have to do it.
David
On Mon, May 8, 2017 at 3:00 PM, David Howells wrote:
> Kees Cook wrote:
>
>> There is a lot of needless casting happening in the big_key data payload.
>> This is harder to trivially verify by static analysis and specifically
>> the randstruct GCC plugin (which was unhappy about casting a struct
>
On Mon, May 08, 2017 at 11:00:56PM +0100, David Howells wrote:
> Kees Cook wrote:
>
> > There is a lot of needless casting happening in the big_key data payload.
> > This is harder to trivially verify by static analysis and specifically
> > the randstruct GCC plugin (which was unhappy about casti
Kees Cook wrote:
> There is a lot of needless casting happening in the big_key data payload.
> This is harder to trivially verify by static analysis and specifically
> the randstruct GCC plugin (which was unhappy about casting a struct
> path across two entries of a void * array). This converts t
7 matches
Mail list logo