On Wed, Jan 16, 2008 at 05:25:13PM +0100, svn(a)coreboot.org wrote:
> Property changes on: trunk/coreboot-v1
> ___________________________________________________________________
> Name: svn:ignore
> + COPYING
> INSTALL
> install-sh
> missing
> mkinstalldirs
> aclocal.m4
> Makefile.in
> configure
> config.log
> config.cache
> config.status
> Makefile
How did this stuff sneak in? I don't think we have any of those files
in v1, correct?
Uwe.
--
http://www.hermann-uwe.de | http://www.holsham-traders.dehttp://www.crazy-hacks.org | http://www.unmaintained-free-software.org
Marc Jones wrote:
> Carl-Daniel Hailfinger wrote:
>> Hi Marc,
>>
>> On 31.01.2008 18:04, Marc Jones wrote:
>>
>>> Geode LX/CS5536 VSA has been updated. The source and binary are
>>> attached. With this release we have changed how the binary is
>>> packaged. Previously it was posted alread compressed with nrv2b and
>>> padded to size. Going forward it is GZipd and will need to be
>>> compressed and padded by hand or by buildrom.
>>>
>>> The following changes were made:
>>> Remove int15 callbacks removed. CPU and memory are calculated by VSA.
>>> VSA no longer takes all the MFGPTs. Two are now available for OS use.
>>>
>>
>> Thank you very much for updating the VSA! Especially the int 15 callback
>> removal reduces interaction complexity quite a bit.
>>
>> Are there any remaining BIOSINT callbacks in the new VSA or can we
>> remove BIOSINT emulation altogether from the Coreboot VSA handler?
>>
>>
>> Regards,
>> Carl-Daniel
>>
>>
>>
> There are no BIOSINTs in VSA now. I have patches for that once we get
> buildrom pulling the new vsa. I don't want to break anyone.
> Marc
>
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:Marc.Jones@amd.com
http://www.amd.com/embeddedprocessors
Author: rminnich
Date: 2008-01-31 15:01:23 +0100 (Thu, 31 Jan 2008)
New Revision: 570
Modified:
coreboot-v3/arch/x86/Makefile
Log:
Move the text to 0x2000, so there is room for the IDT for vm86
emulation.
Signed-off-by: Ronald G. Minnich <rminnich(a)gmail.com>
Acked-by: Marc Jones <marc.jones(a)amd.com>
Modified: coreboot-v3/arch/x86/Makefile
===================================================================
--- coreboot-v3/arch/x86/Makefile 2008-01-31 03:08:32 UTC (rev 569)
+++ coreboot-v3/arch/x86/Makefile 2008-01-31 14:01:23 UTC (rev 570)
@@ -206,7 +206,7 @@
$(obj)/coreboot.stage2 $(obj)/coreboot.stage2.map: $(obj)/stage0.init $(STAGE2_OBJ_NEEDED)
$(Q)# leave a .o with full symbols in it for debugging.
$(Q)printf " LD $(subst $(shell pwd)/,,$(@))\n"
- $(Q)$(LD) -R $(obj)/stage0.o -Ttext 0x1000 --entry=stage2 \
+ $(Q)$(LD) -R $(obj)/stage0.o -Ttext 0x2000 --entry=stage2 \
-o $(obj)/coreboot.stage2 $(STAGE2_OBJ_NEEDED)
$(Q)$(NM) $(obj)/coreboot.stage2 | sort -u > $(obj)/coreboot.stage2.map
Hello everybody!
First I have to admit that while I occasionally followed the
progress of LinuxBIOS I don't really know that much about it,
so please forgive me if that discussion is already over and
done with.
My question is this. I'd like to secure machines against the
people that should work with them [1].
In most BIOSes I can set the boot order to "harddisk only".
(coreboot too, right?). That doesn't help if someone has
access to the machine and can reset the CMOS.
Encrypting the harddisk is another way, but if someone installs
a trojan/keylogger or uses
Now my idea was:
- Set the boot order and a BIOS password
- Encrypt the harddisk, (print the key and store it somewhere safe),
and derive the key from some passphrase (and/or smartcard, etc.)
*and* CMOS data.
As soon as I get, say, 128bit of entropy there, eg. by the
salted MD5 hash of the BIOS password, it's suddenly a great bit
harder to get into the machine. If the machine has an intrusion
detection, the better; and if the BIOS overwrites the password
as soon as a changed harddisk (by serial number and SHA1 of
bootsector?) is detected, it is a really good solution.
The only possible way to attack that'd be left is on the order
of cutting holes in the case, and using a logic analyser to get
the CMOS values of the motherboards' bus and similar ... and
that is likely to raise questions.
Ad 1: I know that that's impossible to achieve fully, like DRM.
But if there is some easy way to set the bar higher - then why not?
Thank you for all remarks, ideas and answers!
Happy weekend!
Phil
#35: Make it possible to boot Windows using LinuxBIOS
----------------------------+-----------------------------------------------
Reporter: uwe | Owner: somebody
Type: enhancement | Status: new
Priority: critical | Milestone: Going mainstream
Component: code | Version: v2
Resolution: | Keywords:
Dependencies: | Patchstatus: there is no patch
----------------------------+-----------------------------------------------
Comment (by navaraf):
FreeLDR can now boot Windows NT4/2000/XP/2003 directly without using
Microsoft loader. It would probably make sense to make it work as a
coreboot payload.
--
Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/35#comment:6>
coreboot <http://www.coreboot.org/>