What does GHASH really do? I try to understand the GCM-MODE used in TLS.
The problem I have had is described below.

1:textbook describes how GHASH works:


2:
I get some debuginfo from openssl code that contain enc_key(32 bytes) and ADD(13 bytes).

I try to simulate the GCM MUL by coding like this:


static unsigned char buf[16]={0};
static unsigned char ctr[16]={0};
static unsigned char ectr[16];

static int poly[]={128, 7, 2, 1, 0, -1};
BN_GF2m_arr2poly(poly, p);

AES_set_encrypt_key(gcm_key, 256, &ghash_key);//gcm_key is derived from debug info
AES_encrypt(ctr, ectr, &ghash_key);

BN_bin2bn(ectr, 16, k);//construct K
memcpy(buf, gcm_add, sizeof(gcm_add));//gcm_add is a 13 bytes data derived form debug info
BN_bin2bn(buf, 16, a);//construct ADD
BN_GF2m_mod_mul(r, a, k, p, bnctx);//compute  (add · K) as first part of computing tag


But the result r is different from the result in openssl code(The code use GCM_MUL).
I confirm that the gcm_add and gcm_key are correct and even the ectr encrypted by gcm_key is also correct compared to debug info from code.
The problem is probably in the usage of BN_bin2bn to construct K (H in the picture) and ADD. GCM specifies that a 16-byte buffer should be transformed into a binary polynomial in little-endian format, but in each byte, it considers the bits in reversed order. Yes, it's confusing. So for example:


The byte array 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 represents the polynomial $1$ (e.g. with a poly = {0} when using BN_GF2m_arr2poly
The byte array 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 represents the polynomial $z^7$ (poly = {7})
The byte array 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 represents the polynomial $z^{127}$ (poly = {127})


So, before using BN_bin2bn, you need to reverse the bytes, and then reverse the bits in each byte. Maybe there is something already implemented in OpenSSL, but I didn't check it.