I am just a grub.efi user/tester/enthusiast.
I don't know the Xserve but some previous reports in this list of people
getting grub.efi to boot on Xserve, and if so it will boot hd/usb linux on
other Apple intel Macs with varying results .
There are some grub.efi 64/32 bit test packages on ub
On Friday 20 February 2009, BandiPat wrote:
>
> Anyway, the writer of the script ask me a question I have not been able
> to find anything about, so I thought I would come straight to you guys!
> I already know that Grub2 will work with XFS and will write to the
> MBR, but he is asking about Supe
>> The hard part is initializing the hardware without the use of the
>> original BIOS - the specifics of initializing various chips are not
>> public, and probably depend on companion hardware and/or trace length
>> on the particular board as well.
>It's not actually needed. If one can nop tpm code
T>his paranoid security talk is growing some big pink elephants which are
>being conveniently ignored: you people are trying to protect a HD within
>a computer that could be stolen, but you trust that the BIOS chip (in
>ROM and whatever you want), which performs the systems initialization
>(includi
El vie, 20-02-2009 a las 20:02 -0500, Isaac Dupree escribió:
> Jan Alsenz wrote:
> > Yes, that was my point. You need a trusted first step.
> > But the only thing besides a TPM, that can be used for this is the BIOS,
> > which can be flashed.
> > And even, if we assume, that we can construct a BIOS
Jan Alsenz wrote:
> Yes, that was my point. You need a trusted first step.
> But the only thing besides a TPM, that can be used for this is the BIOS,
> which can be flashed.
> And even, if we assume, that we can construct a BIOS that only boots if the
> MBR hash matches and can not be flashed prior
phcoder wrote:
>> It's not complete SHA-1, but the rest should be just a constant offset.
> I already said how it differs from standard one. If you feed padded
> byteswapped data to it and then byteswap the rsult back you obtain
> exactly normal SHA-1. But as I said if size is fixed it's compeletel
Hello
Jan Alsenz wrote:
Hi!
Wow, cool work!
Thanks
It's not complete SHA-1, but the rest should be just a constant offset.
I already said how it differs from standard one. If you feed padded
byteswapped data to it and then byteswap the rsult back you obtain
exactly normal SHA-1. But as I sai
Hi!
Wow, cool work!
It's not complete SHA-1, but the rest should be just a constant offset.
But I'm still not sure, what you are trying to do here, is the MBR your root of
trust?
If not, who checks the MBR?
Greets,
Jan
phcoder wrote:
> Hello, as promised I wrote an mbr which performs SHA-1. T
Hello. For SHA-1 verified boot first sector needs to check the rest of
core.img. It will need heavy modifications. On the same time I would
like to avoid changes to current boot process so that both alternatives
are available (SHA-1 and plain boot). In the same time even in current
design the f
Hello, as promised I wrote an mbr which performs SHA-1. To squeeze the
code I had to remove chs and to change the bootdrive installer will have
to overwrite corresponding instruction. SHA-1 implemented in it is
little-endian and without padding. Standard version is big-endian and
with padding.
Vesa Jääskeläinen wrote:
> In case it will get some day in. I would propose that you make own MBR
> code like that gets compiled to own img file like tpmboot.img (512
> bytes). Then you can just provide img file for tool chain. You are
> probably throwing code away anyway from normal mbr boot code.
Quickly getting the devs of Zenwalk convinced to move over to Grub2 it
seems. They are now busy working on a script that will help the user
set up Grub2 when installing Zenwalk! Let me just say I'm very pleased
with their enthusiasm over converting from Lilo to Grub2.
Anyway, the writer of t
Jan Alsenz wrote:
> I agree too!
>
> Multiple methods are interesting and everything that can be, should be placed
> in
> modules.
> But some parts of a trusted boot chain need to be in the MBR, etc. which is
> mainline code (regardless of how how you build it).
>
> The way I have implemented m
I agree too!
Multiple methods are interesting and everything that can be, should be placed in
modules.
But some parts of a trusted boot chain need to be in the MBR, etc. which is
mainline code (regardless of how how you build it).
The way I have implemented my version of the MBR right now is wit
Hi Peter / phcoder / all other grub gurus,
I've joined the grub-devel mail list while attempting to get MacIntel
Xserves to boot linux. I work with a 3d Movie Effects company that has
25 MacIntel Xserves that are becoming close to as useful as
paperweights because they can't run Maya at 64b
Tested the patch applied to rev 1996 for grub.efi 64 bit and 32 bit, on
Imac81 (4GB ram), MacBookPro41 (4GB and 2GB ram) MacBook21 (i386)
with Macosx 10.4 10.5, ubuntu810.
All good.
64bit Macs have other ongoing EFI problems with linux kernel initializtion
and keyboard.
On Fri, Feb 20, 2009 at
On Friday 20 February 2009 13:27:28 phcoder wrote:
> Free software is about freedom of choice. I think we should have
> possibility to have multiple authentication and key sources. Then one
> could e.g. not save password as md5 somewhere in configfile or embedded
> in module but check that this pas
Free software is about freedom of choice. I think we should have
possibility to have multiple authentication and key sources. Then one
could e.g. not save password as md5 somewhere in configfile or embedded
in module but check that this password opens luks. Or that it's a
password of somebody i
19 matches
Mail list logo
