verifying kernel/root/etc. post boot ("verified dev-mode") - Chromium OS discuss

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion verifying kernel/root/etc. post boot ("verified dev-mode")
Received-SPF: pass (google.com: domain of vap...@google.com designates 209.85.215.172 as permitted sender) client-ip=209.85.215.172;
MIME-Version: 1.0
Sender: vap...@google.com
In-Reply-To: <dcd3f80b-24f6-4141-811b-7b4a35002...@chromium.org>
References: <b0a56442-f97f-4d74-a967-6b7fd939d...@chromium.org>
 <CALiw-2FJB5qJBC0vVCKKF=yQojwWy9RTr-=A10h-N0Bu+-r...@mail.gmail.com>
 <CAAbOScmQnDPg6T8UwBArBLu0weiQFmVxMTAdcHVwih9UCgm...@mail.gmail.com>
 <CALiw-2Fxequ4mEC0zp0hYMiW7hoCZPfO_qUUjdJ89Hs0dBm...@mail.gmail.com>
 <CAAbOScmjjJbVUn4r+niFhkNbuvZCZ8Jrw7U9hLzDMMz3d=t...@mail.gmail.com>
 <7b6beac2-e566-4313-9e33-09f792dcb...@chromium.org> <CAALoFEK70kDX-7CNsLySLW4X3v+iV298eFh-iQm8YZyHVAf...@mail.gmail.com>
 <324d3b8b-843c-494f-b7a6-098a819b6...@chromium.org> <86f457f6-d79d-4560-b646-1bd8b29be...@chromium.org>
 <CAAbOScnahvmc6_Pz0ZBRiH=6xhMdOjUVgygijRgeP6jAd2_...@mail.gmail.com>
 <CAByFD2_eEU3wSoved0u4mPznPnR3KKz1N8vqEShve1pLOBm...@mail.gmail.com>
 <CAAbOScmAaXFz4B=DLrkwHA2LC+JH=_CmRm0V+=-2CgB8W7F...@mail.gmail.com>
 <CABjBmK8-SbE1G-Wt1kcHLCnKUYMORvutto5Y+MQTSrc47g-...@mail.gmail.com>
 <a90d7087-b98c-4f3e-84c8-33c863b5f...@chromium.org> <2f19f3c3-2356-476d-ae70-f60f66b04...@chromium.org>
 <CAALoFEKHS+MXQ3v-3dsOVVg8q3Too_EF_Ke9vyGkfdEC9F-...@mail.gmail.com>
 <07987ac1-622b-4ed9-8754-89463ebf8...@chromium.org> <DA15D33D-7BAA-4210-A6C9-A843EDF16...@chromium.org>
 <2f5d7de1-a4c6-4fd8-9a51-44728e2fc...@chromium.org> <832B2F28-A9E4-42B5-B152-FAEB93D37...@chromium.org>
 <CAByFD2_xhwrN9-zaWS7NPjgcH0kmJjmN0PhMdL+TRsix3GH...@mail.gmail.com>
 <98A6F6FA-0399-4DA8-A794-6DEE35475...@chromium.org> <188b5c1b-2126-48a8-b87b-eea87c7df...@chromium.org>
 <0d6e3694-bcb2-4290-a0e2-aedaf34be...@chromium.org> <6c776b90-620b-46a2-8c88-3e9ef4142...@chromium.org>
 <c6daf073-2a2d-4775-b476-6edf62925...@chromium.org> <dcd3f80b-24f6-4141-811b-7b4a35002...@chromium.org>
From: Mike Frysinger <vap...@chromium.org>
Date: Tue, 13 Nov 2012 18:35:37 -0500
Message-ID: <CAAbOScmPzStDxsDK8WmkvTLKJUysbyKRXbvyHdWsP1x9SMA...@mail.gmail.com>
Subject: Re: [cros-discuss] verifying kernel/root/etc. post boot ("verified dev-mode")
To: Trever Nightingale <trr...@gmail.com>
Cc: Chromium OS discuss <chromium-os-disc...@chromium.org>
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Nov 8, 2012 at 2:52 AM, Trever <trr...@gmail.com> wrote:
> Under normal stock firmware conditions (no reprogramming), is it impossible
> for any portion of the firmware to be replaced with something unsigned by
> Google and stay out of Recovery mode?  I'm wondering if it is impossible to
> break the verification until you get to the kernel (dev mode, verified boot
> off).   In other words impossible to break the verification between what was
> once described as the RO firmware and the RW firmware (I gather things are
> unified now)?

the RO firmware is RO because a hardware pin is being latched.  as
long as that pin is latched, it should not be possible for software to
write to the flash where the RO firmware lives.

i don't have a schematic, but i suspect the jumper on the ARM
chromebook sits directly on the SPI flash's Write Protect line (WP).
since that's a physical line, the SPI flash itself rejects write
attempts even if the software were compromised and attempted it.

> Another way of putting it is whether it is possible under stock hardware
> configuration in dev mode for the BIOS to lie about whether a verified boot
> is in progess... i.e. we're booting in dev mode, we see that
> dev_boot_signed_only=1 by hitting TAB, and we know that can't lie?  Do you
> know it's a verified boot if you see the correct settings there because you
> know the firmware can be trusted assuming it hasn't been royally hacked
> (i.e. reflashed)?

obviously no one can make a claim such as "it is impossible to break
the software chain of trust".  the only thing we can do is point you
to the docs that show how the system is designed and then point to the
source where we've attempted to implement that design.  in our
opinion, when you have the RO firmware locked down and the dev mode
switch disabled, the chromebooks are pretty much state of the art when
it comes to the security system and being able to trust them,
especially for a consumer device.

note that in many places, the security of the system is multi-layered
and not just relying on a single link.  examples of the top of my
head:
 - the rootfs is hashed & cryptographically verified & mounted read-only
 - the kernel does not allow the rootfs to be mounted read-write
 - set*id applications are minimized if not completely thrown out
 - all applications are compiled as PIEs with SSP (stack protection)
and fortified source defines as well as other "hardening" measures
(such as runtime ASLR)
 - this is just what we do w/ChromeOS -- it doesn't cover all the
security layers that Chrome itself implements

certainly we welcome researchers to analyze our designs and
implementations and point out issues so that we can adjust and make
people even more secure.

> Another question is whether the firmware can be flashed/reprogrammed from
> Chrome OS userland (a) ordinarily and/or (b) if you've physically opened the
> case and changed a switch/jumper alluded to above in current Chrome devices.
> This question is because I'm wondering how to install my own keys, but also
> about security limitations or strengths of the design.

the system design is geared towards making physical access
annoying/time consuming so as to prevent/discourage "drive by"
attacks.  it is not geared towards preventing people who have physical
access and lots of time (as measured in hours/days) from taking the
machine apart, flashing their own code, and then buttoning it back up
so that the runtime "looks" like ChromeOS but isn't really.  anything
that makes that harder also makes it harder for legitimate users --
people who bought the hardware and so deserve to completely own it and
do as they see fit.  if you want a locked down proprietary platform,
i'm sure there are plenty of other companies out there willing to take
your money (i'll refrain from naming any for obvious reasons).

once the hardware jumper has been disabled and the RO firmware is no
longer RO, simply enabling dev mode gets you access to programming the
firmware.  on most (all?) devices, we use flashrom, and the ARM
chromebook is no exception.  you can use it to dump the RO firmware
via /dev/spidev1.0 or, if the jumper is disabled, program something
else in there.  note that dumping (reading) can be done simply with
the dev mode switch toggled.

the SPI flash (a Winbond W24Q32DW iirc) here is a pretty common
embedded paradigm.

HTH
-mike
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
