Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 11 Jan 2013 10:26:14 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: New plugin load order magic

On 11 Jan, 2013, at 10:13 , Solar Designer <solar@...nwall.com> wrote:
> On Fri, Jan 11, 2013 at 09:27:51AM +0100, magnum wrote:
>> On 11 Jan, 2013, at 8:58 , Solar Designer <solar@...nwall.com> wrote:
>>> On Fri, Jan 11, 2013 at 08:26:40AM +0100, magnum wrote:
>>>> I was just considering reverting my patch for now.
>>> 
>>> Yes, I think you should.
>> 
>> I reverted it now but we need to fix this somehow. For the horribly slow iterated formats that are getting common now, we just can't default to CPU formats on a GPU build.
> 
> Well, maybe we can have ldr_split_line() skip calling fmt_init() if
> source is non-NULL and the format is a GPU one.

Then we'd need the FMT_GPU flag as discussed earlier. If we are to add flags, we could just as well add a FMT_BINARY_NEEDS_INIT flag instead, with pros and cons.

>>> We may want to eliminate the need to call binary() for --show, but this
>>> may have non-trivial consequences (some desirable, some maybe not).
>> 
>> So we would compare the ascii representations after prepare() and split(), instead of the binaries. Could there be different representations of same binary? When?
> 
> Upper/lowercase variations of hex encodings is an obvious example, but
> we should be taking care of them anyway.

But as long as FMT_SPLIT_UNIFIES_CASE, split() and valid() are correct, that problem is solved, right?

> IIRC, the uses of binary representations in --show are primarily to make
> use of binary_hash*(), but there are also uses of source representations
> and a corresponding hash function anyway.

Anyway, this solution would mean invasive changes to loader I guess.

magnum

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ