All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: Locking down U-Boot env with ENV_WRITEABLE_LIST
Date: Sat, 3 Apr 2021 12:24:58 +0200	[thread overview]
Message-ID: <d1d5aef0-7648-42b6-8b6c-b8b726fd6e33@denx.de> (raw)
In-Reply-To: <CAJ+vNU1TdTxtoRACLtsL10ftY12u=00BRQm2ZoDRhSzip6FQog@mail.gmail.com>

On 4/3/21 4:21 AM, Tim Harvey wrote:
> On Fri, Mar 26, 2021 at 11:34 AM Marek Vasut <marex@denx.de> wrote:
>>
>> On 3/26/21 7:15 PM, Tim Harvey wrote:
>>> Greetings,
>>
>> Hi,
>>
>>> I'm trying to understand best how to lock down a U-Boot environment
>>> using ENV_WRITEABLE_LIST=y.
>>>
>>> My understanding is that I should define all vars that I wish to be
>>> able to be loaded from a FLASH env in CONFIG_ENV_FLAGS_LIST_DEFAULT. I
>>> would think this would be something in Kconfig but it's not so I
>>> wonder if I'm misunderstanding something or if I truly need to patch a
>>> config.h when using this feature.
>>
>> You do need to patch board config in include/configs/ , since the flags
>> were note converted to Kconfig. And make sure you only use integer or
>> bool vars, since strings might contain scripts, which you want to avoid.
>>
>>> What is the best way to actively see your static U-Boot env that gets
>>> linked into U-Boot? I can see it with a hexdump but there must be a
>>> better way by looking at an include file?
>>
>>   From running u-boot, => env print
>>
>>> What is the best way to set the list of vars that you wish to be
>>> allowed to be imported from a FLASH env?
>>
>> Ideally none, and if you really want to make sure something can be
>> pulled in from external env, then:
>> #define CONFIG_ENV_FLAGS_LIST_STATIC "var1:dw,var2:dw"
> 
> Marek,
> 
> I can't seem to understand CONFIG_ENV_FLAGS_LIST_STATIC vs
> CONFIG_ENF_FLAGS_LIST_DEFAULT. The code seems convoluted and
> experimentally I am just as confused.
> 
> It seems that as soon as you define CONFIG_ENV_WRITEABLE_LIST=y then
> all variables defined elsewhere (ie CONFIG_EXTRA_ENV_SETTINGS
> CONFIG_BOOTCOMMAND) can no longer be imported from an env (they are
> present if you clobber your flash env but not if anything is written
> to it).
> 
> I quite simply want only the following environment:
> kernel_addr_r=0x02000000
> mmcbootpart=4
> ustate=1
> bootcmd setenv bootargs root=/dev/mmcblk0p${mmcbootpart} rootwait rw;
> load mmc 0:${mmcbootpart} ${kernel_addr_r} boot/kernel.itb && bootm
> ${kernel_addr_r} - ${fdtcontroladdr}

This script is gonna be a problem, since it is something some external 
entity can overwrite and implant random script into your env. That's why 
I wrote you want minimal set of vars imported from external env and they 
should be boolean or integer.

> and the only variables with flags I want to be able to be overridden
> from MMC_ENV are:
> mmcbootpart:dw
> usate:dw
> 
> It is too bad this can't be done via defconfig - perhaps when I
> finally understand it I can submit a patch to move it to Kconfig.
> 
>>
>> And those config options I had enabled in u-boot defconfig:
>>
>> CONFIG_CMD_ENV_CALLBACK=y
>> CONFIG_CMD_ENV_FLAGS=y
>> CONFIG_ENV_IS_NOWHERE=y
>> CONFIG_ENV_IS_IN_MMC=y
>> CONFIG_ENV_APPEND=y
>> CONFIG_ENV_WRITEABLE_LIST=y
>> CONFIG_ENV_ACCESS_IGNORE_FORCE=y
> 
> Do you really define both ENV_IS_NOWHERE and ENV_IS_IN_MMC? From what
> I see if you define ENV_IS_NOWHERE none of the others will be used.

Yes, having two ENV drivers is mandatory. One provides the base env (the 
nowhere) and the other is used to import the filtered extras from 
external env.

  reply	other threads:[~2021-04-03 10:24 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-26 18:15 Locking down U-Boot env with ENV_WRITEABLE_LIST Tim Harvey
2021-03-26 18:34 ` Marek Vasut
2021-03-26 20:41   ` Stefano Babic
2021-04-03  2:21   ` Tim Harvey
2021-04-03 10:24     ` Marek Vasut [this message]
2021-04-03 16:43       ` Tim Harvey
2021-04-03 19:09         ` Marek Vasut
2021-04-05 16:27           ` Tim Harvey
2021-04-05 17:36             ` Marek Vasut
2021-04-06 19:52               ` Tim Harvey
2021-04-06 20:10                 ` Marek Vasut
2021-04-06 21:54                   ` Sean Anderson
2021-04-06 22:39                     ` Joel Peshkin
2021-04-06 23:23                     ` Tim Harvey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d1d5aef0-7648-42b6-8b6c-b8b726fd6e33@denx.de \
    --to=marex@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.