Bug 1283585 – Fix Intel's AES-GCM code to not depend on AVX | Hacker News Reader

Bug 1283585 – Fix Intel's AES-GCM code to not depend on AVX

bugzilla.mozilla.org

27 pointsyuhong26 comments

Can someone give a bit of the why on this one? Is there something wrong with AVX or is this a run on other chips thing? I'm at a bit of a loss on the history.

AVX is normally 256-bit, but it also allows 128-bit instructions with a VEX prefix. Benefits of that include three operands and unaligned access, as well as higher performance when mixed with 256-bit instructions. Of course, you need a AVX-capable CPU and an OS that support AVX XSAVE to be able to use them.

Why don't you write that information in the bug you filed?

Sooo… why move away from AVX? What CPUs support AESNI, but not AVX, and actually matter?

According to Wikipedia, most Celerons and Pentiums lack AVX but have the AES instructions.

Westmere

The issue might be due to not all intel chips have AVX support. That said, many have hardware AES support so.... alternate code path?

AES-NI and AVX were proposed by AMD and Intel at the same time, and were introduced in the same generation of CPUs. I have a strong feeling that they are interconnected.

Why is this on HN?

You get automatic upvotes if you mention crypto and performance?

And Firefox.

The bug report has way too less information for folks of other disciplines ( inside CS ) to understand.

Could someone please provide a context?

The x86 architecture has a large number of optional instruction sets. One of these, AES-NI, provides accelerated AES instructions. Another one, AVX, is a collection of general-purpose vector instructions. These were announced at the same time, but it seems like a large number of Intel's low-end CPUs (Celerons & Pentiums) only implement AES-NI.

Firefox's current implementation of the AES-GCM encryption mode uses AVX instructions. The bug report is a submission of a modified implementation that avoids them.

I really should also submit this to OpenSSL at some point.

Benchmarks?

None that I know of, but performance penalty should be minimal. The main difference is extra movdqu instructions to deal with unaligned access.

It seems weird that mozilla doesn't have something like phabricator so I can view a pretty diff of this easily.

Mozilla does have something like Phabricator, it's called Bugzilla and it's what this thread links to… The only reason you didn't see a pretty diff is because the bug doesn't have a patch attached to it.

I know bugzilla has this feature but IIRC it requires much more explicit actions on the part of the user. Like in this case, the user did not upload a patch and mark it as a patch.

Phab, IIRC, kind of forces you to upload a patch and not some random file. Could be remembering wrong, though.

Well, Bugzilla uses the same namespace for bugs and patches. The submitter didn't upload patches at all, just asm text files, so from Bugzilla's point of view this is a bug. Not really sure there's anything to "fix" here.

Mozilla set its stuff up before Facebook (2004) even existed, let alone Phabricator.

Bugzilla (1998) predates Phabricator (2010) by about 12 years. It was written in Perl, which was the popular language at the time (similar to PHP around when Facebook happened, or JavaScript now). The first versions of Firefox (2002) predate Phabricator by about 8 years.

And Bugzilla is still the best bug management system decades later.

Fwiw I was using Bugzilla in 1996. Perhaps it was open sourced in 1998?

The 1998 release announcement says it was rewritten. https://groups.google.com/forum/#!topic/netscape.public.mozi...

If you think bugzilla is better than everything that came after (e.g. trac, jira, redline, phabricator etc) it would be interesting to know why.

I feel it's functional but not great.

JIRA is not free, and its main appeals are geared towards enterprise bean counters. Not to mention it is written in Java and as a result has quite heavy requirements on the CPU and RAM.

Upside: it is extremely flexible in ticket workflow design.

(Source: maintaining a 300-user JIRA/Confluence instance at work)

AVX is a standardized x86 ISE proposed by both Intel and AMD. Intel implemented AVX support with Ivy Bridge, AMD has implemented it with Bulldozer these 2 platforms are nearly 6 years old, is there an actual reason to drop support for AVX?

Reply on news.ycombinator.com