Date: Sun, 22 Feb 2015 09:50:13 -0800 From: John-Mark Gurney <jmg@funkthat.com> To: Daisuke Aoyama <aoyama@peach.ne.jp> Cc: freebsd-arm@freebsd.org, Brenden Bartelt <brenden.bartelt@gmail.com>, Pawel Jakub Dawidek <pjd@freebsd.org> Subject: Re: "geli: Wrong key" unable to attach in RPi/ARM environment Message-ID: <20150222175013.GH46794@funkthat.com> In-Reply-To: <640B1015D2984FE0A5FB69DBA9ECD23E@ad.peach.ne.jp> References: <CANUxo4omL1m0EkSnmad8qyZqRWbuZ5zJ29nzCA0%2BgSyCAyU9dw@mail.gmail.com> <54DB7B07.4080704@ceetonetechnology.com> <CANUxo4ooMHMeEBPBFH89nsHvrkt-nNmSt2xf-1TTSN6M4htxVg@mail.gmail.com> <640B1015D2984FE0A5FB69DBA9ECD23E@ad.peach.ne.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
Daisuke Aoyama wrote this message on Mon, Feb 23, 2015 at 00:56 +0900:
> It seems openssl(/usr/src/crypto/openssl/crypto/evp) doesn't like unaligned buffer.
We should fix OpenSSL... I just checked the docs for EVP_CipherUpdate,
and there is no documented alignment requirements... and the fact
that the parameters are of type char, tells the compiler that there
are no requirements...
Could you check to see if this is fixed in a more recent version of
OpenSSL (say, from ports)? And if it isn't work w/ OpenSSL to fix
this bug?
> We use it from g_eli_key.c. decrypt() is called with tmpmkey located stack but encrypt() is
> called with the value passed to the function.
> According to definition in g_eli.h, md_mkeys is located odd address due to "uint8_t md_keys".
> So encrypt() is called with odd address! In armv6, it's a bad thing of course. armv6 can't
> handle unaligned data by some op.
I thought we faulted on this issue? or maybe we don't have the registers
for armv6 programmer properly? Could someone who knows out port of
armv6 well comment on this?
> Fixing is very simple, don't pass mkey directly to openssl.
>
> Please try the patch attached this mail. (usage is bottom of this mail)
> I've only checked "geli init". If it does not work in other place, please follow up this mail.
If this patch does work, then we definately need to get OpenSSL to fix
their code... If we don't, other parts of our tree could fail due to
this too..
Thanks for tracking this down!
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150222175013.GH46794>