mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@redhat.com>
To: scrosby@cs.rice.edu
Cc: linux-kernel@vger.kernel.org
Subject: Re: Algoritmic Complexity Attacks and 2.4.20 the dcache code
Date: Thu, 29 May 2003 23:56:00 -0700 (PDT)	[thread overview]
Message-ID: <20030529.235600.88007251.davem@redhat.com> (raw)
In-Reply-To: <oydof1l2aq3.fsf@bert.cs.rice.edu>

   From: Scott A Crosby <scrosby@cs.rice.edu>
   Date: 30 May 2003 01:46:12 -0500
   
   Its not safe to do anything like

One thing that helps here is that we don't need to provide
protection outside the realm of a single name.

This is because the hash function takes the pointer of the dentry of
the directory it is in (the parent), and contributes this into
the hash.

Back to the basic problem, using jenkins for hashing names.  You could
simply shuffle the bytes into a set of 3 32-bit words, every time
you've contributed 12 bytes (the 3 words are full) or you've finished
the string, you run a __jhash_mix(a,b,c) pass.  And you can make
init_name_hash() insert the initial random value (choosen using
get_random_bytes() right before we mount root).

After all, a string is just a variable number of u32 words.

Actually, since we can say something about the alignment of the string
pointer in the dentry case, we can simply feed this as a u32 pointer
straight into the jenkins hash.  We know the length of the string so
this is pretty easy.  Actually, the most generic version "jhash()"
handles arbitrary byte lengths and alignments.

  reply	other threads:[~2003-05-30  6:43 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-29 20:42 Scott A Crosby
2003-05-30  3:57 ` David S. Miller
2003-05-30  4:29   ` Ingo Molnar
2003-05-30 18:16     ` Timothy Miller
2003-05-30 18:53       ` Scott A Crosby
2003-05-30  5:04   ` Scott A Crosby
2003-05-30  6:24     ` David S. Miller
2003-05-30  6:46       ` Scott A Crosby
2003-05-30  6:56         ` David S. Miller [this message]
2003-05-30  8:59       ` Alex Riesen
2003-05-30  9:00         ` David S. Miller
2003-05-30 15:05           ` Scott A Crosby
2003-05-31  6:18             ` David S. Miller
2003-05-31  8:02               ` Willy TARREAU
2003-05-31  8:12                 ` David S. Miller
2003-05-31  8:56                   ` Willy Tarreau
2003-05-31  8:58                     ` David S. Miller
2003-05-31  8:58                   ` David Schwartz
2003-05-31  9:01                     ` David S. Miller
2003-05-31  6:30           ` William Lee Irwin III
2003-05-31  6:33             ` David S. Miller
2003-05-31  6:41               ` William Lee Irwin III
2003-05-31  6:45                 ` David S. Miller
2003-05-31 18:40                   ` Aaron Lehmann
2003-05-30  4:02 ` Ingo Molnar
2003-05-30  4:42   ` Scott A Crosby
2003-05-30  5:01     ` David S. Miller
2003-05-30 13:48 ` Nikita Danilov
2003-06-01  1:15 ` Daniel Phillips

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030529.235600.88007251.davem@redhat.com \
    --to=davem@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=scrosby@cs.rice.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®