Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 13 Feb 2017 15:24:13 -0500
From:      Eric McCorkle <eric@metricspace.net>
To:        freebsd-hackers@FreeBSD.org
Cc:        freebsd-amd64@freebsd.org, Allan Jude <allanjude@FreeBSD.org>
Subject:   GELI BIOS weirdness
Message-ID:  <6874308d-8892-2f03-d125-418949fd472c@metricspace.net>

next in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--r4IX03A8AEMamVkTv0I1hnsQjQwkID24j
Content-Type: multipart/mixed; boundary="7StHMtTjFo29XVR1XxTd1TwwNJTgx2Aps";
 protected-headers="v1"
From: Eric McCorkle <eric@metricspace.net>
To: freebsd-hackers@FreeBSD.org
Cc: freebsd-amd64@freebsd.org, Allan Jude <allanjude@FreeBSD.org>
Message-ID: <6874308d-8892-2f03-d125-418949fd472c@metricspace.net>
Subject: GELI BIOS weirdness

--7StHMtTjFo29XVR1XxTd1TwwNJTgx2Aps
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hello everyone,

I ran into an apparent bug while trying to test a patch related to some
GELI boot work.  This particular patch involves *BIOS* GELI-on-root (not
EFI).

I created an image for qemu with a single gpt disk having a freebsd-boot
and freebsd-ufs partition, with the freebsd-ufs partition actually
having a GELI volume.

The gptboot phase crashes with an illegal instruction.  I tracked this
down to eli_metadata_softc (defined in sys/geom/eli/g_eli.h),
specifically to the mod operation near the end.  Code here:

> if (!(sc->sc_flags & G_ELI_FLAG_AUTH))
>         sc->sc_mediasize -=3D (sc->sc_mediasize % sc->sc_sectorsize);
> else {

This crash also occurs on a build from master.

The crash dump shows eip pointing to the following code:

66 0f 38 f6 f0 31 c6 8b - 4d 14 89 cf c1 ff 1f 8b

The the first 5 bytes of this looks like it's supposed to be an extended
DIV instruction, which is what I would expect, except the opcode is
wrong (it's adc instead), which doesn't end up corresponding to any
valid form of an extended instruction (the 66 prefix).  Examination of
the disassembly confirms this, and the surrounding instructions match
what you would expect from the C code.


Unless I'm missing something, this would seem to indicate a compiler
bug.  More importantly, it would seem to indicate that anyone building
GELI-enabled gptboot from master will end up with a nonfunctional binary.=



Can someone else please confirm this, and if so, I think it's probably
time to file a bug report.


--7StHMtTjFo29XVR1XxTd1TwwNJTgx2Aps--

--r4IX03A8AEMamVkTv0I1hnsQjQwkID24j
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQRELMWN3SgpoYkrmidWwohAqoAEjQUCWKIV7QAKCRBWwohAqoAE
jQxYAPwJRJ+ETq5kIJ7ka9T5AdtHYvi/u6vom6PXkELFc34rswD+JApVKiXNP54N
tXY/yRTlQCi8kNSkF31eBrc0xdZOQww=
=YAfm
-----END PGP SIGNATURE-----

--r4IX03A8AEMamVkTv0I1hnsQjQwkID24j--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6874308d-8892-2f03-d125-418949fd472c>