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
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
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
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
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
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
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
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.
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.
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
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
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
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
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
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
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
>> 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
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
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
19 matches
Mail list logo
