On 22.03.2008 12:04, Stefan Reinauer wrote:
ron minnich wrote:
On Thu, Mar 20, 2008 at 9:27 AM, Peter Stuge peter@stuge.se wrote:
Currently v3 looks for segments until a segment cannot be found.
This is counterintuitive and potentially a security hole, I think
The potential security hole would be scribbling over unlocked flash space with a rogue segment which takes control. Please be aware that this attack is negligible right now because of another easier attack which will NOT be fixed by any suggested format change: Right now, any standard x86 boot with non-working NVRAM (or fallback flag in NVRAM) tries to run fallback/initram first, but any standard x86 build only provides normal/initram. That means if the attacker can add fallback/initram somewhere in flash, he has succeeded. Unless we manage to "fix" that (and it is really debatable whether we can actually lock out flash writes by software with any desktop mainboard (maybe except for some SMM trickery)), the whole issue is moot. Right now, at least the failure modes are very well understood. Once we make this half-secure, some security researcher is going to point out we failed to make it completely secure. Simply declare the whole issue as to-be-done or unfixable and kill any motivation of security researchers to point out the flaws because they are already documented.
we will fix it but so far I think everything works anyway.
Yes, an ELF binary in the filesystem should not become many binaries in the LAR file. We should take that pseudo-simple-elf-segment-only file format out of the LAR format itself. It has nothing to do with the original purpose of LAR.
I really had trouble understanding what you meant with "pseudo-simple-elf-segment-only file". AFAICS it about representing each parsed ELF segment as a separate file. The only proposed format change I have seen so far would have introduced additional code complexity for handling not-really-a-file segments in the LAR without removing any code from the main LAR walking loop.
I'm open to add another field to the header which specifies the number of segments as that would keep added complexity fairly low and increase speed at the same time, but other changes would really need to be well justified.
Regards, Carl-Daniel