Hi,
True we don't have any grub.efi Apple intel Xserve hardware tests so far, at
the apple intel ubuntu forum, but the grub-efi test packages there could be
used to test.
Seems you will need to get some current grub.efi test result to point to
problems specific to the Xserve, sufficient to attract
Thanks for your interest in helping Peter. At first look, the ubuntu
forum looks like we're seeing xserver info, but no one using MacIntel
Xserve hardware to test grub. If you know anyone who could help us
push thru what is causing the Xserve to not work like the MacIntel Mac
Pro Desktops,
Robert Millan wrote:
> On Sat, Feb 21, 2009 at 05:29:34PM +0200, Michael Gorven wrote:
> > On Saturday 21 February 2009 15:51:42 Robert Millan wrote:
> > > On Fri, Feb 20, 2009 at 09:45:28AM +0200, Michael Gorven wrote:
> > > > TPM can be used for good or for bad, but this is the case for
> > > > e
FWIW - This patch has been used in the AROS build of grub for the best
part of the last year - without it SFS doesnt work.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Robert Millan wrote ..
>I'm not sure this is garanteed to work unless it's defined before any
>header is included. Did it compile without warnings?
Compiles perfectly with the patch here.
Without the patch grub fails to compile when configured with
"--enable-grub-emu --enable-grub-fstest"
Robert Millan wrote:
It's exactly what I want to do (minus the 'coercing' part). I want to
ensure that devices run only my unmodified software (which I consider
secure) and only in this case provide decryption keys for sensitive
data. Of course, it done not for DRM purposes, but rather to protect
Robert Millan wrote:
Making sure, that noone can override it, can be awfully difficult, especially
under a physical attacker. A hardware that is at least a bit designed to
withstand such an attack can help a lot.
I'm not sure why is physical security so awfully difficult for you (can't you
use l
Jan Alsenz wrote:
Yeah, but an attacker could patch that out too.
Not if we first measure the MBR. It can be done without any
TPM-specific code in the MBR if I'm not very mistaken.
Could you elaborate on that?
E.g. where do you measure the MBR from?
MBR is automatically measured by the TPM modu
Robert Millan wrote:
Private part of the endorsement key _never_ leaves the device (if
manufacturer uses the recommended TPM_CreateEndorsementKeyPair
method). Even device manufacturer doesn't know it.
Even if that is true (which I doubt), it's merely incidental, because...
It's not really incide
Hi,
The problem with elf64 in our multiboot loader is that it duplicates a lot
of code from elf32 and this eventually leads to bitrot.
In fact, grub_multiboot_load_elf32 and grub_multiboot_load_elf64 are supposed
to be almost identical, and only differ in s/32/64/ references.
It'd be fairly sim
Robert Millan wrote:
On Sat, Feb 21, 2009 at 11:07:22AM -0500, BandiPat wrote:
Robert Millan wrote:
I'd keep it a bit less technical. Something like "rescue mode" or
"recovery mode".
Suggestions?
--
I think either of those may work better. Either better describes the
le
On Sun, Feb 15, 2009 at 07:49:38PM +0100, Felix Zielcke wrote:
> --- util/misc.c (revision 1996)
> +++ util/misc.c (working copy)
> @@ -27,6 +27,9 @@
> #include
> #include
>
> +#define _POSIX_C_SOURCE 199309L
> +#include
I'm not sure this is garanteed to work unless it's defined
On Sat, Feb 21, 2009 at 10:57:50PM +0100, Jan Alsenz wrote:
> >
> > You took the least relevant part of my argument, and assumed this is the
> > reason
> > I object to TPMs. Please check the rest of my previous mail.
>
> I didn't assume that. And I picked this argument because it is the only on
Robert Millan wrote:
> On Sat, Feb 21, 2009 at 10:17:02PM +0100, Jan Alsenz wrote:
>>> First of all, I think it's a poor approach, because there's no way to
>>> garantee
>>> the TPM is doing what it's supposed to (can you read its source code? how
>>> do
>>> you know for sure there are no backdo
On Sat, Feb 21, 2009 at 10:17:02PM +0100, Jan Alsenz wrote:
> >
> > First of all, I think it's a poor approach, because there's no way to
> > garantee
> > the TPM is doing what it's supposed to (can you read its source code? how
> > do
> > you know for sure there are no backdoors?).
>
> As I s
On Sat, Feb 21, 2009 at 10:04:22PM +0100, Jan Alsenz wrote:
> Hi!
>
> I don't want to be picky here, but you know that remote attestation is simply
> sending signed hash values?
Sure. The tricky part is that your computer generates those, but you're not
really in control of them. You need to as
As I said before: you can make the very same argument for every single part of
your PC.
Why do you trust Intel or AMD with your CPU? They are also involved in the TCG!
We can't verify that it doesn't do such things. Unfortunately we also
don't have resources to build alternative chips. However
Robert Millan wrote:
> On Sat, Feb 21, 2009 at 10:43:16PM +0200, Michael Gorven wrote:
Just to clarify, are you objecting to the use of TPM on principle and
because you don't want to encourage use of it, or because you think this
specific use (trusted boot path) is dangerous?
>>> I c
On Sat, Feb 21, 2009 at 09:10:15PM +0100, martin f krafft wrote:
> also sprach Robert Millan [2009.02.21.2049 +0100]:
> > Martin, our problem is that "single-user mode" is very confusing for those
> > not experienced with Un*x. They tend to think this is the normal mode of
> > operation since the
Hi!
I don't want to be picky here, but you know that remote attestation is simply
sending signed hash values?
The important thing is that the receiver has trust in the protection of the
private key.
So if you build me a coreboot/GRUB version with a trusted boot chain I can
happily implement a rem
On Sat, Feb 21, 2009 at 10:43:16PM +0200, Michael Gorven wrote:
> > > Just to clarify, are you objecting to the use of TPM on principle and
> > > because you don't want to encourage use of it, or because you think this
> > > specific use (trusted boot path) is dangerous?
> >
> > I can't reply to th
On Sat, Feb 21, 2009 at 09:38:39PM +0100, Christian Franke wrote:
>>
>> But if the firmware already did, wouldn't this be a waste of boot time?
>>
>>
>
> Yes, it would. Most BIOS perform both health check and security freeze,
> but some don't. For coreboot, it is not a waste of boot time.
>
>
On Sat, Feb 21, 2009 at 06:58:58PM +0200, Alex Besogonov wrote:
> On Sat, Feb 21, 2009 at 3:51 PM, Robert Millan wrote:
> > - An override button that's physically accessible from the chip can be
> >used to disable "hostile mode" and make the TPM sign everything. From
> >that point physic
On Saturday 21 February 2009 22:31:36 Robert Millan wrote:
> On Sat, Feb 21, 2009 at 05:29:34PM +0200, Michael Gorven wrote:
> > On Saturday 21 February 2009 15:51:42 Robert Millan wrote:
> > > On Fri, Feb 20, 2009 at 09:45:28AM +0200, Michael Gorven wrote:
> > > > TPM can be used for good or for b
On Sat, Feb 21, 2009 at 06:48:50PM +0200, Alex Besogonov wrote:
> On Sat, Feb 21, 2009 at 3:51 PM, Robert Millan wrote:
> > I don't agree with this analogy. Unlike cryptography, TPMs have been
> > designed
> > from the ground up to serve an evil purpose. They *could* have designed
> > them with
Robert Millan wrote:
On Sat, Feb 21, 2009 at 07:00:06PM +0100, Christian Franke wrote:
Very interesting. Do you think any of these features could be useful as a
default option in grub-mkconfig?
At least the --health check and --security-freeze are IMO recommended
for each disk.
On Sat, Feb 21, 2009 at 05:29:34PM +0200, Michael Gorven wrote:
> On Saturday 21 February 2009 15:51:42 Robert Millan wrote:
> > On Fri, Feb 20, 2009 at 09:45:28AM +0200, Michael Gorven wrote:
> > > TPM can be used for good or for bad, but this is the case for everything
> > > involving cryptograph
On Sat, Feb 21, 2009 at 06:03:30PM +0100, phcoder wrote:
>
> The only thing that tpm offers over other possibilities is a claim to
> achieve something that is theoretically impossible. Such claims are
> often the case in computer industry. I call it "marketing security".
And I have to admit, t
On Sat, Feb 21, 2009 at 06:29:01PM +0200, Alex Besogonov wrote:
> On Sat, Feb 21, 2009 at 3:46 PM, Robert Millan wrote:
> >> Yes, I'm trying to do remote attestation.
> > You're confusing things. I think you simply want to ensure data integrity,
> > and
> > the TPM doesn't even do that: it simpl
On Sat, Feb 21, 2009 at 04:00:30PM +0100, Jan Alsenz wrote:
> > If you just want to ensure noone is tampering your box, simply make your box
> > tamper-proof. You don't need a protocol to allow third parties to check
> > anything.
>
> Ok, but if you have such a protocol, only use it for yourself
On Sat, Feb 21, 2009 at 07:00:06PM +0100, Christian Franke wrote:
>>
>> Very interesting. Do you think any of these features could be useful as a
>> default option in grub-mkconfig?
>>
>>
>
> At least the --health check and --security-freeze are IMO recommended
> for each disk. Both is also d
On Sat, Feb 21, 2009 at 11:07:22AM -0500, BandiPat wrote:
> Robert Millan wrote:
>
>> I'd keep it a bit less technical. Something like "rescue mode" or
>> "recovery mode".
>>
>> Suggestions?
>>
> --
>
> I think either of those may work better. Either better describes the
> level
Hello. Here is a version 0.0 of efiemu patch. First couple of words
about how efi works
first efi works in boot services mode
then booter calls EfiExitBootServices
after it only small number of calls called efi runtime is available
after then. Only these functions are emulated by this patch. Thi
Robert Millan wrote:
On Sat, Feb 14, 2009 at 03:13:31PM +0100, Christian Franke wrote:
insmod ata_pthru
(note that module dependencies should make this unnecessary)
This insmod is necessary for now. hdparm.mod does not directly call
ata_pthru.mod, it uses kern/disk.c::grub_disk_
First of all you can write anything in specifications. Real chips don't
necessary follow specifications. It's even said that it's "optional".
Secondly this certificate makes regenerating worthless. Companies
coercing you into using they software may challenge you to use signed
public key. Then
Well I don't understand you. When someone speaks about an attack on tpm
you always consider it not-applicable in your environment. Most of them
actually are. Like power analysis is able to recover keys in $1000
margin. With firewire attack you can do it with $10. You can't seriously
assume an a
On Sat, Feb 21, 2009 at 3:51 PM, Robert Millan wrote:
> - An override button that's physically accessible from the chip can be
>used to disable "hostile mode" and make the TPM sign everything. From
>that point physical access can be managed with traditional methods (e.g.
>locks).
> B
On Sat, Feb 21, 2009 at 3:51 PM, Robert Millan wrote:
> I don't agree with this analogy. Unlike cryptography, TPMs have been designed
> from the ground up to serve an evil purpose. They *could* have designed
> them with good intent, for example either of these could apply:
> - Buyer gets a prin
On Sat, Feb 21, 2009 at 3:46 PM, Robert Millan wrote:
>> Yes, I'm trying to do remote attestation.
> You're confusing things. I think you simply want to ensure data integrity,
> and
> the TPM doesn't even do that: it simply puts the problem in hands of a third
> party.
No, I'm not confusing anyt
Robert Millan wrote:
I'd keep it a bit less technical. Something like "rescue mode" or
"recovery mode".
Suggestions?
--
I think either of those may work better. Either better describes the
level the machine boots to, yet will be less confusing to the user as to
why it's i
Robert Millan wrote:
> On Tue, Feb 10, 2009 at 07:02:56PM +0100, Jan Alsenz wrote:
>> Hello!
>>
>> I just noticed, that the pc linux loader (loader/i386/pc/linux.c) always
>> truncates the kernel command line to less than 256 characters.
>> Well since I needed a longer command line, I fixed this pr
On Saturday 21 February 2009 15:51:42 Robert Millan wrote:
> On Fri, Feb 20, 2009 at 09:45:28AM +0200, Michael Gorven wrote:
> > TPM can be used for good or for bad, but this is the case for everything
> > involving cryptography. We don't refuse to use encryption algorithms
> > because they could b
Robert Millan wrote:
> On Sat, Feb 21, 2009 at 03:20:39PM +0100, Jan Alsenz wrote:
>>> "remote attestation" is only useful when you want to coerce others into
>>> running your (generaly proprietary) software. I hope this is not what you
>>> want to do.
>> Yes, this is exactly what he tries do to:
On Tue, Feb 10, 2009 at 07:02:56PM +0100, Jan Alsenz wrote:
> Hello!
>
> I just noticed, that the pc linux loader (loader/i386/pc/linux.c) always
> truncates the kernel command line to less than 256 characters.
> Well since I needed a longer command line, I fixed this problem.
Hi,
Thanks for you
On Sun, Feb 08, 2009 at 08:53:23PM +0100, Robert Millan wrote:
>
> Hi,
>
> This patch implements USB keyboard support. It is based on work by Marco
> Gerards, to which I made some adjustments, synced with trunk, and fixed a
> pair of bugs.
Committed.
--
Robert Millan
The DRM opt-in fallacy
On Sat, Feb 21, 2009 at 03:20:39PM +0100, Jan Alsenz wrote:
> >
> > "remote attestation" is only useful when you want to coerce others into
> > running your (generaly proprietary) software. I hope this is not what you
> > want to do.
> Yes, this is exactly what he tries do to: convince his keyser
Robert Millan wrote:
> On Fri, Feb 20, 2009 at 03:03:04AM +0200, Alex Besogonov wrote:
>> On Fri, Feb 20, 2009 at 2:29 AM, Jan Alsenz
>> wrote:
>> [skip]
>>>The TPM can proof to another party, that the PCRs have certain
>>> values (of
>>> course the communication needs to be established
BTW some BIOSes have an option "boot virus protection" which checks the
mbr and doesn't need tpm. Then password-protecting BIOS and storing key
in flash and cutting write wire will achieve greater security that tpm
Regards
Vladimir 'phcoder' Serbinenko
On Fri, Feb 20, 2009 at 11:12:25PM +0100, phcoder wrote:
> 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 (S
On Fri, Feb 20, 2009 at 02:30:58PM -0500, 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
Robert Millan wrote:
> On Thu, Feb 19, 2009 at 07:38:36AM -0800, Colin D Bennett wrote:
>> While TPM may open a door for corporations to prevent machine owners
>> from having control over their machines, in this instance I do not see
>> another way to solve Alex's problem.
>
> There's an easy way
On Fri, Feb 20, 2009 at 02:12:01PM +0200, Michael Gorven wrote:
>
> Yes, I agree that there should be multiple methods, but I don't see why the
> TPM module shouldn't be in the main trunk. It wouldn't be forced on GRUB
> users in any way -- we would just be giving them the option to use it.
GRU
On Fri, Feb 20, 2009 at 09:45:28AM +0200, Michael Gorven wrote:
>
> TPM can be used for good or for bad, but this is the case for everything
> involving cryptography. We don't refuse to use encryption algorithms because
> they could be used for DRM, so why should we refuse to use TPM?
I don't a
On Fri, Feb 20, 2009 at 03:03:04AM +0200, Alex Besogonov wrote:
> On Fri, Feb 20, 2009 at 2:29 AM, Jan Alsenz wrote:
> [skip]
> >The TPM can proof to another party, that the PCRs have certain
> > values (of
> > course the communication needs to be established by normal software running
>
And in this scenario the encryption key would also be in flash. Since
you can't boot unchecked software and normal linux security wouldn't
allow you to read flash unless you have the root password you can't
recover the key
Regards
Vladimir 'phcoder' Serbinenko
Robert Millan wrote:
On Thu, Feb
On Thu, Feb 19, 2009 at 07:38:36AM -0800, Colin D Bennett wrote:
>
> While TPM may open a door for corporations to prevent machine owners
> from having control over their machines, in this instance I do not see
> another way to solve Alex's problem.
There's an easy way out of this. Simply verify
On Fri, Feb 20, 2009 at 01:29:50AM +0100, Jan Alsenz wrote:
> First of all a TPM is not just some kind of secure memory only accessible from
> early BIOS, it basically is a small computer.
The thing is, we have many of these "small computers" in any standard PC.
Many of them are technically capabl
I consider the way how memory is protected or how integrity of mbr is
ensured out of scope of grub2. It simply can do nothing against it. So
my goals is just making verfication chain secure. Then I hope that
someone more knowledge in chipsets will find a way to build a secure
system on the top
On Wed, Feb 18, 2009 at 11:10:22AM +0200, Alex Besogonov wrote:
> I know that TPM has been mentioned several times on this list. With
> absolutely inadequate knee-jerk reactions from GRUB developers :(
As far as I can recall, I think all my replies explaining why TPMs are a
serious threat to our f
On Tue, Feb 10, 2009 at 12:44:14PM +0100, Javier Martín wrote:
> >
> You're welcome. I see that nevertheless the "0 != " comparisons were
> substituted for standard C int-to-bool-conversion-based comparisons.
> Maybe people should know the signature _and_ semantic contract of
> strncmp, but freque
On Mon, Feb 09, 2009 at 03:06:39PM -0500, Bandan wrote:
> This description is wrt grub-legacy and I
> will soon follow up with my observations with grub2.
Hi,
Please try with GRUB 2 first. GRUB Legacy is not maintained anymore.
In particular, the problem you describe is unlikely to affect the
On Sat, Feb 14, 2009 at 03:13:31PM +0100, Christian Franke wrote:
> insmod ata_pthru
(note that module dependencies should make this unnecessary)
> insmod hdparm
>
> # Make sure disks cannot be locked by an ATA password
> hdparm --quiet --security-freeze (ata4)
> hdparm --quiet --security-freeze
On Mon, Feb 09, 2009 at 08:58:10PM -0500, BandiPat wrote:
> Robert Millan wrote:
>
>>> +#: util/grub.d/10_linux.in:148
>>> +#, sh-format
>>> +msgid "${OS}, linux ${version} (single-user mode)"
>>> +msgstr "${OS}, linux ${version} (mode mono-usuari)"
>>
>> I wonder if we should replace the original
On Wed, Feb 11, 2009 at 10:24:57AM +0100, Michel Dänzer wrote:
> > So if the table is basicaly storing values that enumerate something, why are
> > we using hex to represent them? Hex gives the impression they're an opaque
> > sort of thing, like code, bitmasks or magic numbers.
>
> Your guess is
On Tue, Feb 10, 2009 at 11:50:18AM +0100, Jordi Mallach wrote:
> On Tue, Feb 10, 2009 at 10:54:55AM +0100, Michel Dänzer wrote:
> > > > Could you be more specific about what the table contents mean?
> > BTW, let me point out again that this table including comment is a
> > verbatim copy from the Li
I agree that these measures aren't here to protect against serious
cryptanalyst. Actually there is a way which is even in my reach to crack
it. I would buy:
pci firewire card $10
Then I would download firewire debug tools and put pci card into target
computer then wait that it boots and dump th
>>> If not, who checks the MBR?
>> This can't be done by grub because it happens before any part of grub is
>> loaded. to verify grub you need to rely on vendor/platform-specific
>> mechanisms.
>> I personally find "tpm without tpm" more attractive because it can be
>> easily reused on another plat
67 matches
Mail list logo
