Re: [openssl-project] FW: April Crypto Bulletin from Cryptosense

2018-04-07 Thread Richard Levitte
In message <20180406170540.gk80...@mit.edu> on Fri, 6 Apr 2018 12:05:43 -0500, 
Benjamin Kaduk  said:

kaduk> On Fri, Apr 06, 2018 at 04:23:02PM +0200, Andy Polyakov wrote:
kaduk> > > This is one reason why keeping around old assembly code can have a 
cost. :(
kaduk> > > 
kaduk> > > https://github.com/openssl/openssl/pull/5320
kaduk> > 
kaduk> > There is nothing I can add to what I've already said. To quote myself.
kaduk> > "None of what I say means that everything *has to* be kept, but as
kaduk> > already said, some of them serve meaningful purpose..."
kaduk> > 
kaduk> > Well, I also said that "I'm *not* saying that bit-rot is not a concern,
kaduk> > only that it's not really assembly-specific." And I can probably add
kaduk> > something here, in addition to already mentioned example of legacy code
kaduk> > relying on formally undefined or implementation-specific behaviour. 
It's
kaduk> > not actually that uncommon that *new* C code is committed[!!!]
kaduk> > "bit-rotten". So one can *just as well* say that supporting another
kaduk> > operating system has a cost, and so does using another compiler... Why
kaduk> > not get "angry" about that? What's the difference really? Relevant
kaduk> 
kaduk> Yes, supporting another operating system has a cost!
kaduk> At risk of drawing Richard's ire, if we did not intend to support
kaduk> (e.g.) VMS, we might have been able to get away with not writing our
kaduk> own custom build system in favor of some "industry standard".
kaduk> Supporting non-POSIX systems (e.g., Windows) also adds overhead in
kaduk> how we implement many of our interfaces (file handling, thread
kaduk> handling, locking, randomness, etc.).

I can channel my ire, thank you ;-)

But speaking of these things, I somewhat understand where you're
coming from, and somehow, this makes me think of the way the OpenBSD
folks do things, starting with something that's purely and entirely
for OpenBSD, and then expanding it with platform ports, and that's
actually a line of thought I could live with... BUT, and yeah, that's
a bit BUT...  our layering principles currently suck enormously, and
that also adds to the total cost of maintaining stuff.  Basically, we
have a number of platform specific stuff injected in the code a little
here and there, when we really should make the effort of putting
together an architecture independent layer that anyone would much more
easily write an implementation of for whatever new platform that comes
around, and could even come as a separate porting package that someone
else provides.

In a way, the new build system that I put together is exactly meant to
be a thing that makes it easier to port to other platforms, and at
least try to make it so that port could be delivered as a separate
package.  That was always my goal, and that was also the reason I
decided to write it in perl, 'cause that language is already ported to
all kinds of platforms like no other scripting language.  Not even
python, which is actually quite well ported, reaches as far.
(auto* tools are an abomination to try to port to anything that
doesn't look like a POSIX environment.  I tried, about 20 years ago.
Cmake, which was otherwise a strong candidate i my book, has presented
some challenges to port to VMS as well...  others have tried.  I don't
know so many others that have become popular enough to be considered
"industry standards")

But going back to what I said higher up, I very much wish we had an
actual consistent architecture agnostic layer.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] FW: April Crypto Bulletin from Cryptosense

2018-04-06 Thread Benjamin Kaduk
On Fri, Apr 06, 2018 at 04:23:02PM +0200, Andy Polyakov wrote:
> > This is one reason why keeping around old assembly code can have a cost. :(
> > 
> > https://github.com/openssl/openssl/pull/5320
> 
> There is nothing I can add to what I've already said. To quote myself.
> "None of what I say means that everything *has to* be kept, but as
> already said, some of them serve meaningful purpose..."
> 
> Well, I also said that "I'm *not* saying that bit-rot is not a concern,
> only that it's not really assembly-specific." And I can probably add
> something here, in addition to already mentioned example of legacy code
> relying on formally undefined or implementation-specific behaviour. It's
> not actually that uncommon that *new* C code is committed[!!!]
> "bit-rotten". So one can *just as well* say that supporting another
> operating system has a cost, and so does using another compiler... Why
> not get "angry" about that? What's the difference really? Relevant

Yes, supporting another operating system has a cost!
At risk of drawing Richard's ire, if we did not intend to support
(e.g.) VMS, we might have been able to get away with not writing our
own custom build system in favor of some "industry standard".
Supporting non-POSIX systems (e.g., Windows) also adds overhead in
how we implement many of our interfaces (file handling, thread
handling, locking, randomness, etc.).

I personally prefer a more conservative/restrictive approach than
the historical trend, and probably also more conservative than the
average of the team.  This is presumably shaped by my personal
experiences and career trajectory, and I understand that others'
path are different and so they will have different, but still valid,
preferences.  We as a team are charged with weighing the tradeoff of
supporting an additional platform against the burden of supporting
it and the risks against our ability to continue supporting it.  For
example, in this modern world where properly supporting a platform
basically does require some assembly code, for crypto-relevant
timing considerations, if only one person understands and will
support that assembly code, that is a risk.  Perhaps it's enough of
a risk to make officially supporting that platform a bad idea;
perhaps not -- it's just one factor that we must, as a whole, weigh
and consider.
Removing platform-specific assembly when not needed for security
would seem to reduce the risk, and presumably improve the
maintainability of the software as a whole.  But I don't see a good
way to not have these decisions all be made on a case-by-case basis.

-Ben
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] FW: April Crypto Bulletin from Cryptosense

2018-04-06 Thread Andy Polyakov
> This is one reason why keeping around old assembly code can have a cost. :(
> 
> https://github.com/openssl/openssl/pull/5320

There is nothing I can add to what I've already said. To quote myself.
"None of what I say means that everything *has to* be kept, but as
already said, some of them serve meaningful purpose..."

Well, I also said that "I'm *not* saying that bit-rot is not a concern,
only that it's not really assembly-specific." And I can probably add
something here, in addition to already mentioned example of legacy code
relying on formally undefined or implementation-specific behaviour. It's
not actually that uncommon that *new* C code is committed[!!!]
"bit-rotten". So one can *just as well* say that supporting another
operating system has a cost, and so does using another compiler... Why
not get "angry" about that? What's the difference really? Relevant
question is what's more expensive, supporting multiple compilers?
multiple OSes? multiple assembly? To give a "tangible" example in the
context of forwarded message [that mentions PA-RISC assembly code.] How
long time did it take me to figure out what's wrong and verify that
problem is resolved? Couple of hours (mostly because old systems are
slw and it takes time to compile our stuff). How long time did it
take me to resolve HP-UX problems triggered by report on 20th of March?
I'm presumably[!] done by about now... To summarize, one can make same
argument about multiple things, yet we do them. Why? Because it works to
our advantage [directly or indirectly]...
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] FW: April Crypto Bulletin from Cryptosense

2018-04-03 Thread Tim Hudson
I'm less concerned about that access in this specific instance - as if we
had a test in place for that function then make test on the platform would
have picked up the issue trivially.
I don't know that we asked the reporter of the issue as to *how* it was
found - that would be interesting information.

Noting which platforms are supported to which level and what level of test
coverage we have are the more important items in my view.

Tim.


On Wed, Apr 4, 2018 at 1:39 AM, Richard Levitte  wrote:

> While I totally agree with the direction Tim is taking on this, we
> need to remember that there's another condition as well: access to the
> platform in question, either directly by one of us, or through someone
> in the community.  Otherwise, we can have as many tests as we want, it
> still won't test *that* code (be it assembler or something else)
>
> In message  w...@mail.gmail.com> on Tue, 03 Apr 2018 15:36:15 +, Tim Hudson <
> t...@cryptsoft.com> said:
>
> tjh> And it should have a test - which has nothing to do with ASM and
> everything to do with improving
> tjh> test coverage.
> tjh>
> tjh> Bugs are bugs - and any form of meaningful test would have caught
> this.
> tjh>
> tjh> For the majority of the ASM code - the algorithm implementations we
> have tests that cover things
> tjh> in a decent manner.
> tjh>
> tjh> Improving tests is the solution - not whacking ASM code. Tests will
> catch issues across *all*
> tjh> implementations.
> tjh>
> tjh> Tim.
> tjh>
> tjh> On Tue, 3 Apr. 2018, 8:29 am Salz, Rich,  wrote:
> tjh>
> tjh>  On 03/04/18 15:55, Salz, Rich wrote:
> tjh>  > This is one reason why keeping around old assembly code can have a
> cost. :(
> tjh>
> tjh>  Although in this case the code is <2 years old:
> tjh>
> tjh>  So? It's code that we do not test, and have not tested in years. And
> guess what? Critical CVE.
> tjh>
> tjh>  ___
> tjh>  openssl-project mailing list
> tjh>  openssl-project@openssl.org
> tjh>  https://mta.openssl.org/mailman/listinfo/openssl-project
> tjh>
> ___
> openssl-project mailing list
> openssl-project@openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] FW: April Crypto Bulletin from Cryptosense

2018-04-03 Thread Matt Caswell


On 03/04/18 15:55, Salz, Rich wrote:
> This is one reason why keeping around old assembly code can have a cost. :(

Although in this case the code is <2 years old:

commit e33826f01bd78af76e0135c8dfab3387927a82bb
Author: Andy Polyakov 
AuthorDate: Sun May 15 17:01:15 2016 +0200
Commit: Andy Polyakov 
CommitDate: Thu May 19 22:33:00 2016 +0200

Add assembly CRYPTO_memcmp.

GH: #102

Reviewed-by: Richard Levitte 


Matt
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project