linux-kernel - Re: [PATCH V3 RFC 00/16] EFI stub for ARM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 12 Aug 2013 10:02:40 -0400
From:	Mark Salter <msalter@...hat.com>
To:	Roy Franz <roy.franz@...aro.org>
Cc:	linux-kernel@...r.kernel.org, linux-efi@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, matt.fleming@...el.com,
	linux@....linux.org.uk, leif.lindholm@...aro.org,
	dave.martin@....com
Subject: Re: [PATCH V3 RFC 00/16]  EFI stub for ARM

On Fri, 2013-08-09 at 16:26 -0700, Roy Franz wrote:
> * Change FDT memory allocation to retry with a larger allocation if
>   first educated guess is inadequate.

With this change, it looks like you no longer free the original cmdline
and fdt memory. The current flow looks like:

  retry:
     allocate_memory_for_expanded_fdt
     get_memory_map
     if (update_fdt() fails) {
        free new_fdt and memory_map
        goto retry
     }

So, this keeps the original fdt around and uses it as a starting point
for newly allocated expanded fdt. You don't know if the new fdt is big
enough until update_fdt() succeeds. But at that point, you already wrote
the efi-runtime-mmap property with the memory_map still having the
original cmdline and fdt in it.

I think you should be able to have an expand_fdt() function which bumps
the fdt size and uses the current fdt as the starting point instead of
the original fdt. That way you can free the original fdt on the first
iteration and free the original cmdline as soon as it is successfully
written. Then the last thing you do if get the memory_map and write it.

--Mark

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/