On 08/25/14 21:19, Ard Biesheuvel wrote:
> This series adds a platform config to support QEMU based virtual machines,
> either in TCG or KVM mode. These virtual machines declare their platform
> configuration by passing a device tree which needs to be parsed by Tianocore
> rather than relying on hardcoded peripherals.
>
> Currently, the only assumptions made with respect to the platform config are:
> - at least 1 MB of DRAM at 0x4000_0000
> - NOR flash at 0x0
I'll strive to find the time to review this great series.
But, in advance, can we put the flash somewhere else, like at 0x8 or
0x10? Every time we treat NULL as a valid pointer to a firmware volume
*in C*, the fabric of the universe comes a bit more unstitched.
For one, if a standards-conformant compiler manages to deduce that your
FV pointer is a null pointer, and then you dereference that pointer, the
compiler will have carte blanche to do whatever it pleases (undefined
behavior). We should not base this patchset on undefined behavior.
Using a zero physical address might be fine in assembly, but it isn't
fine in C, for two reasons:
- On this specific implementation, the bit pattern for the zero
address, and the bit pattern for null pointers, coincide.
- Per the C99 standard, 6.3.2.3 Pointers,
3 An integer constant expression with the value 0, or such an
expression cast to type void *, is called a null pointer constant.
[...]
(As soon as the NOR flash's base address appears in the source code, in
the form of an integer constant, and it's 0, we have big trouble. Not
sure if this case ever occurs, but we shouldn't tempt it.)
Again -- this would be perfectly fine in assembly, but given the C
standard, it is not fine in C.
Thanks
Laszlo
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
