Re: SHA-1 MBR
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 alternative to tpm (perhaps anybody here or coreboot folks will come up with something). Additionally it workarounds many bios and tpm bugs. I will continue working on sha-1 boot. My goal is to load core.img checked. After that point there is much more space and any signature based solution can be used. 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 to this point, there are still two points missing: - After the system has started, the BIOS could be flashed. This is a very possible scenario in a multi user environment. Ok, I revoke that statement! This is most likely equivalent to being able to just read out the disk encryption keys from memory, which we considered out of scope. So if you can get the BIOS right, this might actually work for our scenario! Greets, Jan signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: SHA-1 MBR
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 the whole memory (a bug in many firewire implementations allows to do it). Then the key can be easily found in this dump. However the first question of security is -What are the threats faced? (Bruce Schneier Beyond Fear) Classical cryptography works under some assumptions and this scheme is totally unsecure under these assumptions. However I recognise that it can be useful in some cases. Regards Vladimir 'phcoder' Serbinenko Javier Martín wrote: 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 that only boots if the MBR hash matches and can not be flashed prior to this point, there are still two points missing: - After the system has started, the BIOS could be flashed. This is a very possible scenario in a multi user environment. - They could take out the disk and put it in another machine, tamper with the boot code and switch it on. And all your protection is gone. Ok, you could try to put a needed key in the BIOS too, but then we're back to problem one - and the BIOS can not check if a request for the key is valid. I'm not even sure, if something in the BIOS can be read protected. BIOS could be in ROM, un-flashable, including hash/keys and all! Refuse to boot if the hash doesn't match! Admittedly this poses some limitations on whether the system can be upgraded, depending how sophisticated you want to be. This 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 (including RAM and the TPM) cannot be tampered with or even replaced. When someone pointed the key-in-RAM problem the answer was I'll just glue it with epoxy resin! For crying out loud! Without taking into account that most epoxy resins take weeks to solidify under 100 ºC, if the computer is physically stolen it could be subjected to EM-field analysis. What will be the next madness? Will you wrap every RAM module in tinfoil, a-la Faraday cage? Will you build a plasma shield around them? This is going way out of proportion: with non-interactive key initialization, if the computer is stolen, you are screwed period, because you have a Mallory-on-steroids-holding-Alice-ransom instead of a tame Eve. It does not take a rocket scientist (what I'm studying) nor a cryptographer (one of my hobbies) to notice! ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: hfs patch (Re: State of GRUB on PowerPC)
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 good as mine. [...] We'd also need to know what are these 'casefold' and 'order' tables from ARDI's code, and what exactly means this is a composition of them. Your guess is as good as mine. My impression so far is that this is a confusing mess (which can probably be fixed with a little effort), that this situation doesn't bother you at all, and that you want to make it clear to us how all of this is irrelevant to you. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] hdparm.mod - get/set ATA disk parameters
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 (ata6)
menuentry Boot {
# Check health
if hdparm --quiet --health (ata4) ; then echo -n ; else
echo Warning: SMART status check failed
read
fi
# Set boot disk to fast, disable spin down
hdparm --quiet --aam=254 --standby-timeout=0 (ata4)
# Set other disk to quiet, spin down after 5min inactivity
hdparm --quiet --aam=128 --standby-timeout=60 (ata6)
# Boot ...
}
menuentry Memory Test {
# Spin down both disks after 10min
hdparm --quiet --standby-timeout=120 (ata4)
hdparm --quiet --standby-timeout=120 (ata6)
# Load memtest ...
}
Very interesting. Do you think any of these features could be useful as a
default option in grub-mkconfig?
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] r1986 broke FAT detection
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 they don't (I had to look it up in the handbook), and while the code that was committed may look like an obvious error to a wanderer (because, of course, comparison functions should return a semantic-bool, shouldn't they?), the version with the explicit 0 != checks at least looks like it was written like that _on purpose_ (and the actual binary cost should be zero with any sensible compiler), thus making future developers on bug-fixing quests at least scratch their heads before proposing the change to the if (!strncmp) error. So, keeping the coding style consistent is important, but I think a balance with readability is in order. Thus, you are the maintainers and you know what you're doing, but I think it's not worth to keep the coding style so strict as to become confusing. I think you're confusing things. C has no boolean type. I know strcmp gives more info than just a semantic boolean, but in this case it's not interesting to us. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
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 freedom were polite and respectful. Please think twice before labeling a reply you disagree with as inadequate knee-jerk reaction, or it will be impossible to have a reasonable discussion over this issue. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: SHA-1 MBR
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 of it. I do only as much as I can and never claim to achieve something which is theoretically impossible Regards Vladimir 'phcoder' Serbinenko Jan Alsenz wrote: 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 alternative to tpm (perhaps anybody here or coreboot folks will come up with something). Additionally it workarounds many bios and tpm bugs. I will continue working on sha-1 boot. My goal is to load core.img checked. After that point there is much more space and any signature based solution can be used. 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 to this point, there are still two points missing: - After the system has started, the BIOS could be flashed. This is a very possible scenario in a multi user environment. Ok, I revoke that statement! This is most likely equivalent to being able to just read out the disk encryption keys from memory, which we considered out of scope. So if you can get the BIOS right, this might actually work for our scenario! Greets, Jan ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
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 of performing crypto checks and validating your memory. What makes the TPM different is not what it is, but what is _designed for_. When you get one, it comes with an hostile setup. If this computer was a crypto card, this would be no trouble, since the crypto card can't coerce you into using proprietary software. However, the TPM device is capable of deciding for you when your computer is clean and when it isn't. This empowers third parties to figure out if you're clean or not. To get the picture, imagine this situation: - Youtube demands you run approved version of Adobe Flash. - You don't want to use Adobe's proprietary program, you'd rather use Gnash instead. - Youtube can challenge you to use your TPM to prove you're running Flash. Then you're forced into either bowing to your TPM or not watching any videos. Such kind of submission to a small piece of silicon is not acceptable. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
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 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 data integrity from the flash chip, and make sure nobody can write to the flash chip. You can archieve the first by e.g. installing coreboot/GRUB there and add some crypto support to it. You can archieve the second by cutting the WE wire, or by dumping lots of concrete over your board. Yes, this is a gazillon times more secure than a TPM. TPMs are vulnerable to reverse engineering. The evil part of TPM seems to be when a person buys a computer but the computer is locked down with a key not provided to the buyer. Precisely. If it came with a key that is known to the buyer (e.g. printed on paper), or with an override mechanism that is only accessible to its legitimate buyer, there would be no problem with it. But AFAICT there are no TPMs that do this. It probably even violates the spec. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
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 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 printed copy of the TPM's private key when they buy a board. - 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). But they didn't. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
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 is free software. You can do anything you want with it. We can't really force our users to either use TPMs or not to use them. However, we can choose not to endorse a feature if we think it's ill-intended. We can also try to raise awareness of the problem, which is what I'm doing right now. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
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 this. Simply verify data integrity from the flash chip, and make sure nobody can write to the flash chip. You can archieve the first by e.g. installing coreboot/GRUB there and add some crypto support to it. You can archieve the second by cutting the WE wire, or by dumping lots of concrete over your board. Yes, this is a gazillon times more secure than a TPM. TPMs are vulnerable to reverse engineering. Everything is vulnerable to reverse engineering. The problem with a TPM is not, that it uses bad/proprietary crypto, but as you state, that you can't own it completely. The evil part of TPM seems to be when a person buys a computer but the computer is locked down with a key not provided to the buyer. Precisely. If it came with a key that is known to the buyer (e.g. printed on paper), or with an override mechanism that is only accessible to its legitimate buyer, there would be no problem with it. But AFAICT there are no TPMs that do this. It probably even violates the spec. I also haven't seen a TPM that does it, but it is in the specs - called a revocable endorsement key - as an optional feature... Greets, Jan signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Writing to superblock?
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 asking about Superblocks also when using XFS. Will it? Any special instructions needed to do that? I hope I am asking the right question. Just let me know if you need more clarification. This is highly discouraged and won't work at all in some cases (I think XFS is one of those). Just install to MBR instead. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Design: first sector of core.img
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 (SHA-1 and plain boot). In the same time even in current design the first sector plays a special role. So I propose first sector to be moved to a separate file and then at install time grub-mkimage or grub-setup can take care of choosing right one depending on options supplied by user (plain or SHA-1 boot) Have you looked at how the boot process works when using coreboot/GRUB ? By getting rid of the legacy stuff, things get much more flexible. Check the grub.cfg example in: http://grub.enbug.org/CoreBoot to see what I mean. Most pieces are there already. When we merge crypto support, it'll be possible for GRUB-in-chip to verify GRUB-in-disk. Then the chip becomes your root of trust, which is what you're pursuing, if I understood correctly. But if I was serious about security, I wouldn't make a BIOS blob my root of trust, GRUB is a much better option ;-) -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: SHA-1 MBR
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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
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 established by normal software running on the machine) 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. 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 the requesting server runs, what it's supposed to. Which is exactly remote attestation, just in this case he controls both sides, which I think makes it an interesting use of the technology. First, I don't think it's possible to implement SHA-1 hashing in MBR - there's probably just not enough space left in 512-byte code segment for that. I am very sure of that. Well, I spoke phcoder on Jabber - there might be a way to do this. He's going to investigate it. This is unnecessary. Once GRUB supports crypto, it can simply load itself from an encrypted filesystem on disk. An image can be of arbitrary size. Ok, but where does it get the key from? And how can wherever the key comes from be sure that it's talking to GRUB? Greets, Jan signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
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 the requesting server runs, what it's supposed to. Which is exactly remote attestation, just in this case he controls both sides, which I think makes it an interesting use of the technology. That would be like trying to rob yourself by threatening yourself with a gun, instead of simply drawing money from your wallet. 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. This is unnecessary. Once GRUB supports crypto, it can simply load itself from an encrypted filesystem on disk. An image can be of arbitrary size. Ok, but where does it get the key from? The public key (or just a hash) can be embedded in GRUB itself. In the instance of GRUB that goes to the flash chip, that is. And how can wherever the key comes from be sure that it's talking to GRUB? Because you put it there, and made sure noone can overwrite it afterwards. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] USB keyboard
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: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Long linux kernel command lines
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 effort, but note that this can't be changed carelessly. It's possible we have this limit for backward compatibility. If newer versions of Linux allow a longer cmdline, our code should check for that instead. Also, would be cool if you can check whether loader/i386/linux.c also has this problem. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
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 keyserver, that the requesting server runs, what it's supposed to. Which is exactly remote attestation, just in this case he controls both sides, which I think makes it an interesting use of the technology. That would be like trying to rob yourself by threatening yourself with a gun, instead of simply drawing money from your wallet. Sorry, I don't get that analogy... 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 trust the manufacturer, you only have to secure one of your boxes instead of them all, which is usually much easier. This is unnecessary. Once GRUB supports crypto, it can simply load itself from an encrypted filesystem on disk. An image can be of arbitrary size. Ok, but where does it get the key from? The public key (or just a hash) can be embedded in GRUB itself. In the instance of GRUB that goes to the flash chip, that is. And how can wherever the key comes from be sure that it's talking to GRUB? Because you put it there, and made sure noone can overwrite it afterwards. 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. Greets, Jan signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
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 for DRM, so why should we refuse to use TPM? 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 printed copy of the TPM's private key when they buy a board. - 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). But they didn't. 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? Michael -- http://michael.gorven.za.net PGP Key ID 6612FE85 S/MIME Key ID AAF09E0E signature.asc Description: This is a digitally signed message part. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Long linux kernel command lines
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. Hi, Thanks for your effort, but note that this can't be changed carelessly. It's possible we have this limit for backward compatibility. If newer versions of Linux allow a longer cmdline, our code should check for that instead. If you look at the patch I send on Feb 11, I think it does all the necessary checks. Also, would be cool if you can check whether loader/i386/linux.c also has this problem. Well, it uses a fixed 4k command-line area. But I don't know, if this is a problem there. Greets, Jan signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: single-user mode string (Re: gettext patch (beta))
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 the list. -- Pat ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
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 confusing anything. 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. 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 sensitive data from theft (real theft, not copyright infringement). Well, I spoke phcoder on Jabber - there might be a way to do this. He's going to investigate it. This is unnecessary. Once GRUB supports crypto, it can simply load itself from an encrypted filesystem on disk. An image can be of arbitrary size. Nope. Still no way to test system integrity. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
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. locks). But they didn't. And actually, they did. New flexibility in EKs. In the 1.1b specification, endorsement keys were fixed in the chip at manufacture. This allowed a certificate to be provided by the manufacturer for the key. However, some privacy advocates are worried about the EK becoming a nonchangeable identifier (in spite of all the privacy controls around it, which would make doing this very difficult). ***As a result, the specification allows a manufacturer to allow the key to be removed by the end user and regenerated.*** Of course the certificate at that point would become worthless, and it could be very expensive for the end user to get a new certificate. https://www.trustedcomputinggroup.org/specs/TSS/TSS_1_2_Errata_A-final.pdf ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
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 you still have a choice to regenerate your key but it's simply equivalent to but nobody's threatening your freedom: we still allow you to remove your data and not access it at all.. It's equivalent to just smashing your tpm. Regards Vladimir 'phcoder' Serbinenko 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 point physical access can be managed with traditional methods (e.g. locks). But they didn't. And actually, they did. New flexibility in EKs. In the 1.1b specification, endorsement keys were fixed in the chip at manufacture. This allowed a certificate to be provided by the manufacturer for the key. However, some privacy advocates are worried about the EK becoming a nonchangeable identifier (in spite of all the privacy controls around it, which would make doing this very difficult). ***As a result, the specification allows a manufacturer to allow the key to be removed by the end user and regenerated.*** Of course the certificate at that point would become worthless, and it could be very expensive for the end user to get a new certificate. https://www.trustedcomputinggroup.org/specs/TSS/TSS_1_2_Errata_A-final.pdf ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] hdparm.mod - get/set ATA disk parameters
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_ata_pass_through function
pointer instead. Otherwise, using other future ata_pass_through
functions (e.g. from some ahci.mod :-) would not be possible.
Another drawback of a hdparm-ata_pthru dependency would be that 'help'
or 'hdparm -h' would load ata.mod which disables e.g. biosdisk.mod.
insmod hdparm
# Make sure disks cannot be locked by an ATA password
hdparm --quiet --security-freeze (ata4)
hdparm --quiet --security-freeze (ata6)
menuentry Boot {
# Check health
if hdparm --quiet --health (ata4) ; then echo -n ; else
echo Warning: SMART status check failed
read
fi
# Set boot disk to fast, disable spin down
hdparm --quiet --aam=254 --standby-timeout=0 (ata4)
# Set other disk to quiet, spin down after 5min inactivity
hdparm --quiet --aam=128 --standby-timeout=60 (ata6)
# Boot ...
}
menuentry Memory Test {
# Spin down both disks after 10min
hdparm --quiet --standby-timeout=120 (ata4)
hdparm --quiet --standby-timeout=120 (ata6)
# Load memtest ...
}
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 typical PC BIOS. AAM and standby
settings are more user specific. The problem is that this relies on
native ATA support which is now only available for controllers supported
by ata.mod.
At least for the boot disk, such hdparm calls could be added by e.g.
extending 'prepare_grub_to_access_device'.
Christian
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] efi_emu
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. This is the difference with tianocore. Usage cases: -look how OS works in EFI environments. Debugging. Debugging ACPI -launch darwin on non-EFI machine without usage of unmaintained buggy kernel patches (I already have xnu loading, it works but I have to fix few things) -future port of coreboot to mac without losing ability to launch Mac OS X Usage: First compile grub2 with this patch and efiemu runtime (in archive) Then on grub prompt efiemu_loadcore efiemu runtime efiemu_pnvram variables file efiemu_acpi [-x tables to delete] tables to add if any efiemu_prepare linux_efiemu normal linux initrd_efiemu initrd Soon I'll also submit xnu patch which uses efiemu on non-EFI platforms Programming note: To keep compact I use defered allocation of all objects Drawbacks and TODOs (I'm working on it but help is much appreciated): -no way to hide standard bios functions -time functions aren't implemented yet -reset function isn't implemented yet -only 32-bit is supported for now -efiemu runtime is now has to be compiled separately Regards Vladimir 'phcoder' Serbinenko efiemu.tgz Description: application/compressed-tar ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: single-user mode string (Re: gettext patch (beta))
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 to, yet will be less confusing to the user as to why it's in the list. Uhm the current single-user mode string is inspired by the one in debian's original update-grub script, which used to be recovery mode but was changed in 2006: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=370110 I guess it'd be polite to ask Martin about it before switching to recovery mode or rescue mode. 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 they are (usually) a single user. Any comments? -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] hdparm.mod - get/set ATA disk parameters
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 typical PC BIOS. AAM and standby settings are more user specific. The problem is that this relies on native ATA support which is now only available for controllers supported by ata.mod. At least for the boot disk, such hdparm calls could be added by e.g. extending 'prepare_grub_to_access_device'. But if the firmware already did, wouldn't this be a waste of boot time? -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
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 trust the manufacturer, you only have to secure one of your boxes instead of them all, which is usually much easier. You only have to secure those boxes you need to be secure. The method you use to secure them is irrelevant to that. And how can wherever the key comes from be sure that it's talking to GRUB? Because you put it there, and made sure noone can overwrite it afterwards. 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 locks, tamper-proof seals, cameras and alarms?), but most people who're in the bussiness of protecting physical goods manage to sort it out. In any case, if your attacker is that much determined to archieve their goal, reverse engineering a small chip isn't going to stop them. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
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: it simply puts the problem in hands of a third party. No, I'm not confusing anything. 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. 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 sensitive data from theft (real theft, not copyright infringement). There's no fundamental difference between hardening a device and using that as your root of trust and using someone else's hardened device and using that as your root of trust. The only differences are: - One more link in the trust chain (irrelevant). - Because it's _someone else's_ computer (the TPM), you're irrationally assuming that its security is flawless. - Because it's someone else's computer, this helps them get their foot in your door. Next time you notice, each PC will be verified by one of these, and then you can kiss all your freedom goodbye. Well, I spoke phcoder on Jabber - there might be a way to do this. He's going to investigate it. This is unnecessary. Once GRUB supports crypto, it can simply load itself from an encrypted filesystem on disk. An image can be of arbitrary size. Nope. Still no way to test system integrity. I was repliing to the idea of implementing sha-1 checks in the MBR. Please don't bring it out of context. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
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 got really good at it. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
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 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 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 printed copy of the TPM's private key when they buy a board. - 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). But they didn't. 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, because it's not just a specific use, it's part of the design, of its purpose. One of the design goals is remote attestation, which is a threat to our freedom and is unethical. If there was a device that behaves like a TPM except remote attestation is not possible (e.g. by one of the means described above), I wouldn't object to it, and I think the GNU project wouldn't either, but then referring to that as TPM is misleading. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] hdparm.mod - get/set ATA disk parameters
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. Both is also done by a typical PC BIOS. AAM and standby settings are more user specific. The problem is that this relies on native ATA support which is now only available for controllers supported by ata.mod. At least for the boot disk, such hdparm calls could be added by e.g. extending 'prepare_grub_to_access_device'. 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 is added to grub-mkconfig, it should be configurable by some variable. -- Christian Franke ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
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 them with good intent, for example either of these could apply: - Buyer gets a printed copy of the TPM's private key when they buy a board. 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... Public key is then signed by manufacturer's certificate. This ensures that the private key can't be compromised. ...this ensures that $evil_bob can challenge you to prove you're running his proprietary anti-user software. Besides, you can _disable_ endorsement key (TPM_DisablePubekRead) to protect your privacy. Of course. And if you're serious about privacy, you can even trash your computer or unplug it from the internet. The question is, will it be practical for you to do disable the TPM a few years from now? -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
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 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 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 printed copy of the TPM's private key when they buy a board. - 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). But they didn't. 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, because it's not just a specific use, it's part of the design, of its purpose. One of the design goals is remote attestation, which is a threat to our freedom and is unethical. If there was a device that behaves like a TPM except remote attestation is not possible (e.g. by one of the means described above), I wouldn't object to it, and I think the GNU project wouldn't either, but then referring to that as TPM is misleading. I wasn't actually referring to the remote attestation. Just using the TPM to store a disk encryption key sealed with PCR registers, so that it would only be provided once it's been verified that GRUB hasn't been changed. (Personally I wouldn't want to use remote attestation at all.) Michael -- http://michael.gorven.za.net PGP Key ID 6612FE85 S/MIME Key ID AAF09E0E signature.asc Description: This is a digitally signed message part. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
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 point physical access can be managed with traditional methods (e.g. locks). But they didn't. And actually, they did. New flexibility in EKs. In the 1.1b specification, endorsement keys were fixed in the chip at manufacture. This allowed a certificate to be provided by the manufacturer for the key. However, some privacy advocates are worried about the EK becoming a nonchangeable identifier (in spite of all the privacy controls around it, which would make doing this very difficult). ***As a result, the specification allows a manufacturer to allow the key to be removed by the end user and regenerated.*** Of course the certificate at that point would become worthless, and it could be very expensive for the end user to get a new certificate. https://www.trustedcomputinggroup.org/specs/TSS/TSS_1_2_Errata_A-final.pdf I would have to study this in detail, but I don't see the text saying that remote attestation is no longer supported. What this probably amounts to is that the coercion process can now be made anonymously, which I already knew: http://en.wikipedia.org/wiki/Direct_anonymous_attestation and which is not the core of the problem. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] hdparm.mod - get/set ATA disk parameters
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 is added to grub-mkconfig, it should be configurable by some variable. When using coreboot with GRUB, you usually have either: - A single GRUB, in chip, with a hand-crafted configuration. - Two GRUBs, one in chip which loads the other one from disk. The configuration for the first is hand-crafted but the second one would usually be grub-mkconfig'ed. In this case sounds like the right place for this would be the hand-crafted part. There's some example script code in: http://grub.enbug.org/CoreBoot How about adding it there? -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
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, because it's not just a specific use, it's part of the design, of its purpose. One of the design goals is remote attestation, which is a threat to our freedom and is unethical. If there was a device that behaves like a TPM except remote attestation is not possible (e.g. by one of the means described above), I wouldn't object to it, and I think the GNU project wouldn't either, but then referring to that as TPM is misleading. I wasn't actually referring to the remote attestation. Just using the TPM to store a disk encryption key sealed with PCR registers, so that it would only be provided once it's been verified that GRUB hasn't been changed. (Personally I wouldn't want to use remote attestation at all.) 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?). But the important here is not whether there's something wrong with the use case you described or not. The important is that this use case is lumped together with something seriously nasty, and that its promoters are acting irresponsibly by not allowing us to make the distinction. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
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 remote attestation scheme with it and ship it to my customers. Greets, Jan 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 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 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 printed copy of the TPM's private key when they buy a board. - 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). But they didn't. 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, because it's not just a specific use, it's part of the design, of its purpose. One of the design goals is remote attestation, which is a threat to our freedom and is unethical. If there was a device that behaves like a TPM except remote attestation is not possible (e.g. by one of the means described above), I wouldn't object to it, and I think the GNU project wouldn't either, but then referring to that as TPM is misleading. signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: single-user mode string (Re: gettext patch (beta))
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 since they are (usually) a single user. Any comments? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=370110 It was purely aesthetic for me. I would not oppose a change back for the purpose of increasing clarity for others. I suppose a configuration option might be possible, but even that could be considered overkill by the person who has to implement it, and I wouldn't blame him/her. :) Thanks for asking. No opposition from me. Okay thanks for the quick reply. If nobody has a better idea, I'll just set it to recovery mode. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
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 this question, because it's not just a specific use, it's part of the design, of its purpose. One of the design goals is remote attestation, which is a threat to our freedom and is unethical. If there was a device that behaves like a TPM except remote attestation is not possible (e.g. by one of the means described above), I wouldn't object to it, and I think the GNU project wouldn't either, but then referring to that as TPM is misleading. I wasn't actually referring to the remote attestation. Just using the TPM to store a disk encryption key sealed with PCR registers, so that it would only be provided once it's been verified that GRUB hasn't been changed. (Personally I wouldn't want to use remote attestation at all.) 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: 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! Greets, Jan signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
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 it doesn't mean we should support any anti-freedom devices ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
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 your TPM to obtain them, like a beggar. So if you build me a coreboot/GRUB version with a trusted boot chain I can happily implement a remote attestation scheme with it and ship it to my customers. That's the beauty of free software; you can do anything you like with it, even nasty things. Just don't expect us to help you get there. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
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: 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! 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. Anyway, it's obvious that I trust my CPU because I have no other choice. The context in which I said this, is different: there are better choices there. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
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 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! 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 object! Because I think it is not an argument... Anyway, it's obvious that I trust my CPU because I have no other choice. The context in which I said this, is different: there are better choices there. ... and since you seem to agree, please don't use it. You seem to assume, that I really like the idea of a TPM, or something like that. I can assure you, that this is not the case. My only goal is to keep the discussion based on facts and reason. Which way too often get lost in this kind of discussion (and I want to stress that this is not an accusation to anyone here). Greets, Jan signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
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 object! Because I think it is not an argument... Anyway, it's obvious that I trust my CPU because I have no other choice. The context in which I said this, is different: there are better choices there. ... and since you seem to agree, please don't use it. You seem to assume, that I really like the idea of a TPM, or something like that. I can assure you, that this is not the case. My only goal is to keep the discussion based on facts and reason. Which way too often get lost in this kind of discussion (and I want to stress that this is not an accusation to anyone here). Thanks for clarifiing, I appreciate your response. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] implement grub_millisleep in util/misc.c for grub-emu
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 unless it's defined before any header is included. Did it compile without warnings? -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: single-user mode string (Re: gettext patch (beta))
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 the machine boots to, yet will be less confusing to the user as to why it's in the list. Uhm the current single-user mode string is inspired by the one in debian's original update-grub script, which used to be recovery mode but was changed in 2006: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=370110 I guess it'd be polite to ask Martin about it before switching to recovery mode or rescue mode. 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 they are (usually) a single user. Any comments? === Why not then make it a combination of both? Maybe recovery--single-user-mode or single-user-mode/rescue? Just some little something to help clarify it to a new user or user that didn't play with Unix. :-) It wouldn't extend the selection in either the loader list or the grub.cfg that much. -- Pat ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: bugs in loader/i386/pc/multiboot.c
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 simple to resincronize them, but I'd really like to find a way to prevent this from happening again. Does someone have any idea on what would be a good approach? -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
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 incidental. TCG was initially started as a group to develop trusted computing platform. MS later tried to hijack it to realize their wet dream of locked-down computer. Public key is then signed by manufacturer's certificate. This ensures that the private key can't be compromised. ...this ensures that $evil_bob can challenge you to prove you're running his proprietary anti-user software. So I won't be able to answer $evil_bob challenge in any case, since I'm mostly running Linux now. The question is, will it be practical for you to do disable the TPM a few years from now? (I think yes, but that's not the point) -- With respect, Alex Besogonov (cybe...@staffdirector.net) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
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 module, it requires no intervention from GRUB. -- With respect, Alex Besogonov (cybe...@staffdirector.net) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for 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 locks, tamper-proof seals, cameras and alarms?), but most people who're in the bussiness of protecting physical goods manage to sort it out. My devices will be installed at clients' locations. It's impossible to guarantee that all devices will be physically secure. If you live in the USA then one day such device might contain your private data. Would you like it to be stolen? I'm trying to design them so that data can't be stolen easily. Even by me, if someday I become insane because of flame-wars in mailing lists. In any case, if your attacker is that much determined to archieve their goal, reverse engineering a small chip isn't going to stop them. Reverse engineering the TPM chip is very costly. And I'm not going to try to protect data from NSA or CIA or another three-letter agency. -- With respect, Alex Besogonov (cybe...@staffdirector.net) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: A _good_ and valid use for TPM
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 sensitive data from theft (real theft, not copyright infringement). There's no fundamental difference between hardening a device and using that as your root of trust and using someone else's hardened device and using that as your root of trust. There's a difference. It's impossible to create the root-of-trust without some hardware/firmware support. The only differences are: - One more link in the trust chain (irrelevant). - Because it's _someone else's_ computer (the TPM), you're irrationally assuming that its security is flawless. Security of TPM vendors is audited by a third party. For most practical purposes it can be considered quite adequate. - Because it's someone else's computer, this helps them get their foot in your door. Next time you notice, each PC will be verified by one of these, and then you can kiss all your freedom goodbye. And how does not supporting this functionality in GRUB affect this? This is unnecessary. Once GRUB supports crypto, it can simply load itself from an encrypted filesystem on disk. An image can be of arbitrary size. Nope. Still no way to test system integrity. I was repliing to the idea of implementing sha-1 checks in the MBR. Please don't bring it out of context. Sorry, I didn't mean to. -- With respect, Alex Besogonov (cybe...@staffdirector.net) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] implement grub_millisleep in util/misc.c for grub-emu
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 ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Corrections to affs and sfs
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
Re: A _good_ and valid use for TPM
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 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 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 printed copy of the TPM's private key when they buy a board. - 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). But they didn't. 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, because it's not just a specific use, it's part of the design, of its purpose. One of the design goals is remote attestation, which is a threat to our freedom and is unethical. If there was a device that behaves like a TPM except remote attestation is not possible (e.g. by one of the means described above), I wouldn't object to it, and I think the GNU project wouldn't either, but then referring to that as TPM is misleading. (warning, I accidentally wrote a long essay exploring when these TPM-like things are evil) Okay, suppose we use this means to make them not-so-evil: Buyer gets a printed copy of the TPM's private key when they buy a board. I'll call them (pseudo)TPMs when they meet GNU demands. (They could be built with Free software, openly specified hardware designs, etc... why not throw in a bonus :-)) Alex Besogonov's use case is still possible. Which should make us suspicious of whether our moral problem is solved. Here's how it's possible: Assume he has access to computer A, which is physically secured. He buys computer B, which he wants to be able to wander around in the world without much effort put into physical security. He accepts that the hard drive contents can be tampered with, but he's willing to pay for a smaller cryptographic unit that guards its secrets jealously -- the (pseudo)TPM -- in order to prove to computer A that computer B hasn't been changed. Alex is the buyer, so he received the printed copy of the private key, and (for example) stashes it where computer A is, or burns it. How does that make computer B free? Computer A and its buddies (if any) will still refuse to communicate with B if B runs different software than what Alex had put on it. Unless there are laws in place, Alex can go on to sell (or lease) computer B to someone else, without giving *them* the printed private key. Or in the case of the override button and securing the (pseudo)TPM with physical locks, Alex could secure it with a lock, and then sell computer B without giving the lock's key to person who buys the computer from him. This look at (pseudo)TPM makes them look to me as a weak way of asserting at- a-distance your legal/political ownership of a computer. Even if manufacturers cooperate with GNU demands, resulting (pseudo)TPMs are only useful for a purpose that is arguably evil... although the political arguments might be different between an end-user, a small non-computer-focused corporation, a large one, and a computer-manufacturer, asserting ownership. And it depends on whether they share such information (with police, public internets or other networks) in an attempt to detect fugitive computers. I think, in the U.S. we can make laws that coerce corporations pretty effectively, and individuals don't have much power (most people buy their computing devices from mass marketers, large corporations, not people on the streets), so -- if we chose -- we could make laws that ensured that (pseudo)TPM technology was not used for its most serious moral transgressions. (I'm not sure though, because the Internet is so strange.) Also because most software is made by big corporations that can be sued (e.g. Microsoft, Apple), and most Free non-corporate software isn't evil. But I suspect that in a part of the world where people know their immediate oppressors more intimately, where the mass market (the free market?) isn't trusted as much, the TPM (well, like any other piece of software or hardware, only worse) could be abused to control people. I could spin that argument one way to say that U.S. capitalism is to be desired (at least once we can make the legislators do what we want, rather than what big rich
Re: [PATCH] bug fix for x86_64 efi
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, I'M LOOKING FOR THAT PERSON... Cheers. On Feb 20, 2009, at 9:32 PM, Peter Cros wrote: 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 ubuntuforums that you might try (include the patch) . Xserve results would be interesting. grub2 EFI boot loader internal/external booting On Sat, Feb 21, 2009 at 3:16 AM, Drew Rosen drew...@mac.com wrote: 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 64bit for rendering. (and we can't repurpose them as linux servers). Any chance we can help test this patch in an xserve environment, and/ or do you have any ideas that would help us? Here's the most discouraging info I've received in my research to date: The Xserve does not have BIOS compatibility, and so you'll need to boot through EFI. The Apple EFI implementation will not boot directly off ISO9660 media, so you'll need to find a way to get to the EFI console. You'll need a kernel configured with EFI support. There's no especially sensible way to get a working framebuffer on this hardware, so you'll need to work out what arguments need to be passed to your distribution's installer in order to get it to run over the serial port. elilo or grub-efi should be able to boot the kernel and initramfs. I've been catologing my research at: http://drewsta.com/xserve.html Thanks! Drew On Feb 20, 2009, at 6:28 AM, Peter Cros wrote: 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 2:12 AM, Bean bean12...@gmail.com wrote: Hi, This patch contains several important update for x86_64 efi: 1, Support memory larger than 2G. 2, Fix a bug in efi_call_6 that could cause chainloadering osx to fail. 3, Improve the method to detect frame buffer address and line length in linux loader. 2009-02-19 Bean bean12...@gmail.com * configure.ac: Check for -mcmodel=large in x86_64 target. * include/grub/efi/api.h (efi_call_10): New macro. (efi_wrap_10): New function. * include/grub/efi/pe32.h (GRUB_PE32_REL_BASE_HIGH): New macro. (GRUB_PE32_REL_BASED_HIGH): Likewise. (GRUB_PE32_REL_BASED_LOW): Likewise. (GRUB_PE32_REL_BASED_HIGHLOW): Likewise. (GRUB_PE32_REL_BASED_HIGHADJ): Likewise. (GRUB_PE32_REL_BASED_MIPS_JMPADDR): Likewise. (GRUB_PE32_REL_BASED_SECTION): Likewise. (GRUB_PE32_REL_BASED_REL): Likewise. (GRUB_PE32_REL_BASED_IA64_IMM64): Likewise. (GRUB_PE32_REL_BASED_DIR64): Likewise. (GRUB_PE32_REL_BASED_HIGH3ADJ): Likewise. * kern/x86_64/dl.c (grub_arch_dl_relocate_symbols): Fixed relocation issue. * kern/x86_64/efi/callwrap.S (efi_wrap_6): Bug fix. (efi_wrap_10): New function. * kern/x86_64/efi/startup.S (codestart): Use relative addressing. * loader/efi/appleloader.c (devpath_5): Add support for late 2008 MB/MBP model (NV chipset). (devdata_devs): Add devpath_5 to the list. * load/i386/efi/linux.c (video_base): Remove variable. (RGB_MASK): New macro. (RGB_MAGIC): Likewise. (LINE_MIN): Likewise. (LINE_MAX): Likewise. (FBTEST_STEP): Likewise. (FBTEST_COUNT): Likewise. (fb_list): New variable. (grub_find_video_card): Remove function. (find_framebuf): New function. (grub_linux_setup_video): Use find_framebuf to get frame buffer and line length. * util/i386/efi/grub-mkimage.c (grub_reloc_section): Fix relocation problem for x86_64. -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros (pxw) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros
Re: [PATCH] bug fix for x86_64 efi
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 help at developer level. There are also some graphics limitations (use of framebuffer driver) after EFI linux booting for other intel macs, might be important for your application. On Sun, Feb 22, 2009 at 2:16 PM, Drew Rosen drew...@mac.com wrote: 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, I'M LOOKING FOR THAT PERSON... Cheers. On Feb 20, 2009, at 9:32 PM, Peter Cros wrote: 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 ubuntuforums that you might try (include the patch) . Xserve results would be interesting. grub2 EFI boot loader internal/external bootinghttp://ubuntuforums.org/showthread.php?t=995704 On Sat, Feb 21, 2009 at 3:16 AM, Drew Rosen drew...@mac.com wrote: 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 64bit for rendering. (and we can't repurpose them as linux servers). Any chance we can help test this patch in an xserve environment, and/or do you have any ideas that would help us? Here's the most discouraging info I've received in my research to date: The Xserve does not have BIOS compatibility, and so you'll need to boot through EFI. The Apple EFI implementation will not boot directly off ISO9660 media, so you'll need to find a way to get to the EFI console. You'll need a kernel configured with EFI support. There's no especially sensible way to get a working framebuffer on this hardware, so you'll need to work out what arguments need to be passed to your distribution's installer in order to get it to run over the serial port. elilo or grub-efi should be able to boot the kernel and initramfs. I've been catologing my research at: http://drewsta.com/xserve.html Thanks! Drew On Feb 20, 2009, at 6:28 AM, Peter Cros wrote: 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 2:12 AM, Bean bean12...@gmail.com wrote: Hi, This patch contains several important update for x86_64 efi: 1, Support memory larger than 2G. 2, Fix a bug in efi_call_6 that could cause chainloadering osx to fail. 3, Improve the method to detect frame buffer address and line length in linux loader. 2009-02-19 Bean bean12...@gmail.com * configure.ac: Check for -mcmodel=large in x86_64 target. * include/grub/efi/api.h (efi_call_10): New macro. (efi_wrap_10): New function. * include/grub/efi/pe32.h (GRUB_PE32_REL_BASE_HIGH): New macro. (GRUB_PE32_REL_BASED_HIGH): Likewise. (GRUB_PE32_REL_BASED_LOW): Likewise. (GRUB_PE32_REL_BASED_HIGHLOW): Likewise. (GRUB_PE32_REL_BASED_HIGHADJ): Likewise. (GRUB_PE32_REL_BASED_MIPS_JMPADDR): Likewise. (GRUB_PE32_REL_BASED_SECTION): Likewise. (GRUB_PE32_REL_BASED_REL): Likewise. (GRUB_PE32_REL_BASED_IA64_IMM64): Likewise. (GRUB_PE32_REL_BASED_DIR64): Likewise. (GRUB_PE32_REL_BASED_HIGH3ADJ): Likewise. * kern/x86_64/dl.c (grub_arch_dl_relocate_symbols): Fixed relocation issue. * kern/x86_64/efi/callwrap.S (efi_wrap_6): Bug fix. (efi_wrap_10): New function. * kern/x86_64/efi/startup.S (codestart): Use relative addressing. * loader/efi/appleloader.c (devpath_5): Add support for late 2008 MB/MBP model (NV chipset). (devdata_devs): Add devpath_5 to the list. * load/i386/efi/linux.c (video_base): Remove variable. (RGB_MASK): New macro. (RGB_MAGIC): Likewise. (LINE_MIN): Likewise. (LINE_MAX): Likewise. (FBTEST_STEP): Likewise. (FBTEST_COUNT): Likewise. (fb_list): New variable. (grub_find_video_card): Remove function. (find_framebuf): New function. (grub_linux_setup_video): Use find_framebuf to get
