Re: Bug in loadfile_elf32.c?

[Erik Fair <fair%netbsd.org@localhost>]

Independent of the C language definition issue is both a system hardware state and security issue: ECC RAM needs to be initialized at some point (write all of it at least once, eventually) to prevent false positive ECC exceptions, and the kernel should not be handing out dirty pages from other processes which may contain sensitive data - otherwise a spy process could simply malloc everything it’s allowed in a system and paw through it for “interesting” bits from other nominally independent processes (one man’s trash (garbage, collected) is another man’s treasure).

	Erik Fair


> On Sep 1, 2016, at 10:40, Eduardo Horvath <eeh%NetBSD.org@localhost> wrote:
> 
> On Wed, 31 Aug 2016, Erik Fair wrote:
> 
>> The OpenBoot firmware (IEEE 1275) on SPARCs & UltraSPARCs only initializes as much RAM as the NVRAM parameter variables specify, not all RAM that is detected. It tends to be a tradeoff - zeroing all RAM when you’ve got gigabytes “takes a long time” and some places want fast (re)booting, so “do just enough for the kernel” has long been common practice.
>> 
>> In principle, once the OS kernel is booted (whatever it is), all parity/ECC RAM should be initialized (if there’s random bits in a RAM location, reading it might raise an exception), but it can be done by “lazy evaluation” (as needed) rather than all-at-once in a blocking fashion.
> 
> Be that as is may, it's not really a 1275 issue, it's buggy C code.  The C 
> language does not specify automatic variables are initialized, so the 
> original code was buggy.  It's a miracle it ever worked at all.  Stack use 
> by any other functions in the boot loader could also have left garbage on 
> the stack which would cause random behavior.
> 
> The marks array either needs to be explicitly initialized before calling 
> load_file, or switched to a static variable which would be initialized as 
> part of zeroing out the BSS segment.
> 
> Eduardo