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 platform or any
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
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 as
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 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 frequently
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
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 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 capable
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 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
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.
GRUB
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 out of
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
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
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
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 janals...@student.ethz.ch
wrote:
[skip]
The TPM can proof to another party, that the PCRs have certain
values (of
course the communication needs to be
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 keyserver, that
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 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 your
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: convince his
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 be used
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 problem.
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 in
On Sat, Feb 21, 2009 at 3:46 PM, Robert Millan r...@aybabtu.com 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
On Sat, Feb 21, 2009 at 3:51 PM, Robert Millan r...@aybabtu.com 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.
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
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
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.
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 the machine boots
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 done by a
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 and do
On Sat, Feb 21, 2009 at 06:29:01PM +0200, Alex Besogonov wrote:
On Sat, Feb 21, 2009 at 3:46 PM, Robert Millan r...@aybabtu.com 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:
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, they
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 cryptography. We
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 06:48:50PM +0200, Alex Besogonov wrote:
On Sat, Feb 21, 2009 at 3:51 PM, Robert Millan r...@aybabtu.com 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
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 bad, but
On Sat, Feb 21, 2009 at 06:58:58PM +0200, Alex Besogonov wrote:
On Sat, Feb 21, 2009 at 3:51 PM, Robert Millan r...@aybabtu.com 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
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.
So if this
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 this question,
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
On Sat, Feb 21, 2009 at 09:10:15PM +0100, martin f krafft wrote:
also sprach Robert Millan r...@aybabtu.com [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
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 can't reply to
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.
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 ask
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 said before:
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 backdoors?).
As I
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 one I
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 sys/time.h
#include unistd.h
+#define _POSIX_C_SOURCE 199309L
+#include time.h
I'm not sure this is garanteed to work
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
level
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
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
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
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
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
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
bump
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:
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
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,
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
60 matches
Mail list logo
