On Thu, Jul 12, 2018 at 11:16:28PM -0700, Kees Cook wrote:
>
> Is this correct? It seems like you did the bulk of
> AHASH_REQUEST_ON_STACK conversions in 2016. Can shash grow an sg
> interface?
shash does not need to grow an sg interface. All users of
AHASH_REQUEST_ON_STACK set the CRYPTO_ALG_ASY
On Thu, Jul 12, 2018 at 5:40 PM, Herbert Xu wrote:
> On Thu, Jul 12, 2018 at 06:02:26PM +0200, Arnd Bergmann wrote:
>>
>> Looking through some of the drivers, I found this interesting one:
>
> As I said before these patches are fundamentally broken. Users
> of AHASH_REQUEST_ON_STACK can only use
On Thu, Jul 12, 2018 at 10:20 PM, Herbert Xu
wrote:
> On Thu, Jul 12, 2018 at 10:17:29PM -0700, Kees Cook wrote:
>>
>> Then why does the instrumented tcrypt output show the huge size? Is
>> tcrypt doing something incorrectly?
>
> tcrypt doesn't even use AHASH_REQUEST_ON_STACK so I don't understand
On Thu, Jul 12, 2018 at 10:17:29PM -0700, Kees Cook wrote:
>
> Then why does the instrumented tcrypt output show the huge size? Is
> tcrypt doing something incorrectly?
tcrypt doesn't even use AHASH_REQUEST_ON_STACK so I don't understand
your point.
> What is the correct value to use for AHASH_RE
On Thu, Jul 12, 2018 at 8:44 PM, Herbert Xu wrote:
> On Thu, Jul 12, 2018 at 08:33:24PM -0700, Kees Cook wrote:
>> On Thu, Jul 12, 2018 at 5:40 PM, Herbert Xu
>> wrote:
>> > On Thu, Jul 12, 2018 at 06:02:26PM +0200, Arnd Bergmann wrote:
>> >>
>> >> Looking through some of the drivers, I found th
On Thu, Jul 12, 2018 at 08:33:24PM -0700, Kees Cook wrote:
> On Thu, Jul 12, 2018 at 5:40 PM, Herbert Xu
> wrote:
> > On Thu, Jul 12, 2018 at 06:02:26PM +0200, Arnd Bergmann wrote:
> >>
> >> Looking through some of the drivers, I found this interesting one:
> >
> > As I said before these patches
On Thu, Jul 12, 2018 at 5:40 PM, Herbert Xu wrote:
> On Thu, Jul 12, 2018 at 06:02:26PM +0200, Arnd Bergmann wrote:
>>
>> Looking through some of the drivers, I found this interesting one:
>
> As I said before these patches are fundamentally broken. Users
> of AHASH_REQUEST_ON_STACK can only use
On Thu, Jul 12, 2018 at 06:02:26PM +0200, Arnd Bergmann wrote:
>
> Looking through some of the drivers, I found this interesting one:
As I said before these patches are fundamentally broken. Users
of AHASH_REQUEST_ON_STACK can only use sync algorithm providers
and therefore drivers are irrelevant
Arnd Bergmann wrote:
> From what I can tell, neither of the two are called in atomic context, so
> you should be able to use a GFP_KERNEL allocation.
You need to be careful doing that since the allocation might happen in the AFS
writeback path. I use GFP_NOIO or GFP_NOFS in rxkad.c and skb_cow_
From: Arnd Bergmann
Date: Wed, 11 Jul 2018 12:16:12 +0200
> Using get_seconds() for timestamps is deprecated since it can lead
> to overflows on 32-bit systems. While the interface generally doesn't
> overflow until year 2106, the specific implementation of the TCP PAWS
> algorithm breaks in 2038
On Thu, Jul 12, 2018 at 10:17 PM, Kees Cook wrote:
> On Thu, Jul 12, 2018 at 9:02 AM, Arnd Bergmann wrote:
>> On Wed, Jul 11, 2018 at 10:36 PM, Kees Cook wrote:
>>> Several uses of AHASH_REQUEST_ON_STACK() will trigger FRAME_WARN warnings
>>> (when less than 2048) once the VLA is no longer hidde
On Thu, Jul 12, 2018 at 2:15 PM, Arnd Bergmann wrote:
> On Thu, Jul 12, 2018 at 10:30 PM, Kees Cook wrote:
>> Actually, I think this can actually be adjusted to just re-use the
>> stack allocation, since rxkad_verify_packet() finishes one before
>> doing another in rxkad_verify_packet_1():
>
> Th
Hi David,
On Thu, Jul 12, 2018 at 2:28 PM, David Howells wrote:
> Can I get a cc on the original patch?
I'll add you to CC for future revisions. Here was the start of this thread:
https://lkml.kernel.org/r/20180711203619.1020-14-keesc...@chromium.org
-Kees
--
Kees Cook
Pixel Security
Can I get a cc on the original patch?
David
On Thu, Jul 12, 2018 at 10:30 PM, Kees Cook wrote:
> On Thu, Jul 12, 2018 at 1:23 PM, Kees Cook wrote:
>> On Thu, Jul 12, 2018 at 8:11 AM, Arnd Bergmann wrote:
>>> On Wed, Jul 11, 2018 at 10:36 PM, Kees Cook wrote:
Two uses of SKCIPHER_REQUEST_ON_STACK() will trigger FRAME_WARN warnings
>>
On Thu, Jul 12, 2018 at 1:23 PM, Kees Cook wrote:
> On Thu, Jul 12, 2018 at 8:11 AM, Arnd Bergmann wrote:
>> On Wed, Jul 11, 2018 at 10:36 PM, Kees Cook wrote:
>>> Two uses of SKCIPHER_REQUEST_ON_STACK() will trigger FRAME_WARN warnings
>>> (when less than 2048) once the VLA is no longer hidden
On Thu, Jul 12, 2018 at 8:11 AM, Arnd Bergmann wrote:
> On Wed, Jul 11, 2018 at 10:36 PM, Kees Cook wrote:
>> Two uses of SKCIPHER_REQUEST_ON_STACK() will trigger FRAME_WARN warnings
>> (when less than 2048) once the VLA is no longer hidden from the check:
>>
>> net/rxrpc/rxkad.c:398:1: warning:
On Thu, Jul 12, 2018 at 9:02 AM, Arnd Bergmann wrote:
> On Wed, Jul 11, 2018 at 10:36 PM, Kees Cook wrote:
>> Several uses of AHASH_REQUEST_ON_STACK() will trigger FRAME_WARN warnings
>> (when less than 2048) once the VLA is no longer hidden from the check:
>>
>> drivers/block/drbd/drbd_worker.c:
On Wed, Jul 11, 2018 at 10:36 PM, Kees Cook wrote:
> Several uses of AHASH_REQUEST_ON_STACK() will trigger FRAME_WARN warnings
> (when less than 2048) once the VLA is no longer hidden from the check:
>
> drivers/block/drbd/drbd_worker.c:325:1: warning: the frame size of 1112 bytes
> is larger tha
On Wed, Jul 11, 2018 at 10:36 PM, Kees Cook wrote:
> Two uses of SKCIPHER_REQUEST_ON_STACK() will trigger FRAME_WARN warnings
> (when less than 2048) once the VLA is no longer hidden from the check:
>
> net/rxrpc/rxkad.c:398:1: warning: the frame size of 1152 bytes is larger than
> 1024 bytes [-W
20 matches
Mail list logo
