AES encryption in CBC mode, in most cases, must be used with random
initialization vector. Using the same key and initialization vector several
times is weak and must be avoided.

Added iv parameter to the aes_cbc_encrypt_blocks and aes_cbc_decrypt_blocks
functions for passing initialization vector.

Command 'aes' now also require the initialization vector parameter.

Signed-off-by: Andrey Mozzhuhin <amozzhuhin@yandex.ru>

If 'bootefi hello' or 'bootefi selftest' can be executed depends on the
configuration.

If an invalid non-numeric 1st argument is passed to bootefi, e.g.
'bootefi hola', this string is converted to 0 and U-Boot jumps to
this typically invalid address.

With the patch the online help is shown instead.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>

EFI calls are usually defined as asmlinkage. That means we pass all parameters
to functions via the stack x86_32.

On x86_64 however, we need to also stick to the MS ABI calling conventions,
which the EFIAPI define conveniently handles for us. Most EFI functions were
also marked with EFIAPI, except for the entry call.

So this patch adjusts all entry calls to use EFIAPI instead of the manual
asmlinkage attribute.

While at it, we also change the prototype of the entry point to return
efi_status_t instead of ulong, as this is the correct prototype definition.

Signed-off-by: Alexander Graf <agraf@suse.de>

---

v1 -> v2:

  - Use efi_status_t in all occurences

CONFIG_WALNUT was dropped in June 2017 in:
commit 98f705c9cefdfd ("powerpc: remove 4xx support")

While at it, the related CONFIG_MACH_SPECIFIC and the have_of
and _machine variables are unused as well, so drop them too.

Signed-off-by: Tuomas Tynkkynen <tuomas@tuxera.com>

The nvedit command is the only user of env_driver_lookup_default outside of
the environment code itself, and it uses it only to print the environment
it's about to save to during env save.

As we're about to rework the environment to be able to handle multiple
environment sources, we might not have an idea of what environment backend
is going to be used before trying (and possibly failing for some).

Therefore, it makes sense to remove that message and move it to the
env_save function itself. As a side effect, we also can get rid of the call
to env_driver_lookup_default that is also about to get refactored.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

The sunXi arm64 build has overflown, leading to the main U-boot binary
overwriting the environment when flashing the new image, or even worse,
overwriting itself when we're calling saveenv.

Disable this command that is not critical until we can adress the issue
properly.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>

The sunXi arm64 build has overflown, leading to the main U-boot binary
overwriting the environment when flashing the new image, or even worse,
overwriting itself when we're calling saveenv.

Disable this command that is not critical until we can adress the issue
properly.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>

The sunXi arm64 build has overflown, leading to the main U-boot binary
overwriting the environment when flashing the new image, or even worse,
overwriting itself when we're calling saveenv.

Disable this command that is not critical until we can adress the issue
properly.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>

The sunXi arm64 build has overflown, leading to the main U-boot binary
overwriting the environment when flashing the new image, or even worse,
overwriting itself when we're calling saveenv.

Disable this command that is not critical until we can adress the issue
properly.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>