Re: GRUB hardened boot framework
Robert Millan wrote: > On Sat, Feb 28, 2009 at 12:18:17AM +0100, phcoder wrote: >>> If the code that does the authentication is loaded from the encrypted >>> partition, >>> without being checked, this is true, but we assume, that core.img is already >>> loaded (and checked), so the authentication code is not on the encrypted >>> partition, and can detect any tampering. >> As far as I understood Robert Millan was suggesting that just encrypting >> (but not verifying) your kernel is enough. I wanted to show wha it isn't > > Fair enough. My point is that we don't need overcomplicated mechanisms to > measure every module, config file or component separately. After core.img > is verified/loaded, it's much simpler to handle the rest at this layer > below the filesystem, which doesn't require significant redesign of how > GRUB works. Well, the problem there will probably be, that no commonly used disk encryption (e.g. dm-crypt) uses checksums (as far as I know), when reading from disk. So if you want to be compatible, the check of the files needs to be done either by the filesystem (which only very few can do), or by a separate layer. Which brings us back to the initial idea. In any case, for all the crypto stuff it would be a good idea, to have some general GRUB crypto-library, that everyone could use. Probably like it is done in the linux kernel. This could then also be used for the password command. 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: GRUB hardened boot framework
phcoder wrote:
>>
>> I'm no crypto expert, but I was under the impression that when the
>> data is
>> encrypted, measurement comes "for free": if someone tampered it, you'd be
>> unable to decrypt. Is this correct?
>>
> It's not. Encryption is permutation
> E_{key,sector} (P) -> C
> Which permutes transforms plaintext P to ciphertext P. Without knowing
> the key an attacker still can reuse the values he has already seen (e.g.
> if he has an image of FS at previous date).
> He can also replace the sector with anything. He can't predict to what
> it will be decrypted but not to what it originally was
> Additionally most current modes subdivide sectors in 16-byte blocks. And
> how a block is encrypted depends on previous but not next blocks in
> sector. Then if attacker knows where the authentication is he can
> rewrite this place with anything. It will decrypt to garbage and with
> some quite high probability it won't crash and will let the attacker in.
> With XTS block encryptions depends neither on previous nor on next block
> . So attacker doesn't even need the authenthication code to be at the
> end of the sector.
> In various CBC modes if an attacker replaces sector A with sector B
> first block of sector B will decrypt to garbage but the rest will
> decrypt just fine. It can be used for e.g. launching printk to output
> the encryption keys.
> In conclusion encryption doesn't check for modifications. Some
> encryption systems do it additionally through separate mechanism but
> encryption itself does no such thing
If the code that does the authentication is loaded from the encrypted partition,
without being checked, this is true, but we assume, that core.img is already
loaded (and checked), so the authentication code is not on the encrypted
partition, and can detect any tampering.
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: GRUB hardened boot framework
Robert Millan wrote: > On Sun, Feb 22, 2009 at 02:27:25PM +0100, Jan Alsenz wrote: >> If we could agree on this, then I think we could find a way to extend the >> GRUB >> module system to fully allow this. >> >> From my point of view the minimal needed features for these systems are: >> - easy exchange of the MBR binary to be installed >> - easy exchange of the core.img loader binary >> - hooks for any disk read (not sure if write is necessary) >> >> (I didn't check if any of these is already implemented) >> >> Last part to agree on would then be, that these infrastructure features >> should >> be in the mainline code. > > Hi, > > The last stage is much simpler. Just put /boot/ in a crypted filesystem (we > have a patch liing around which is pending to merge). Yes, that would also be an idea. Then the filesystem needs the authentication. > That only leaves MBR and core.img. You can either check both from firmware > (does any BIOS allow this?) or do some funny gimmicks in MBR ;-) There might be some boot virus protections, that could be abused. Or otherwise - coreboot. >> That way it would be easy to develop various trusted boot solutions (and >> probably some other systems too), but keep all the controversial code out of >> mainline. > > I appreciate your interest in avoiding controversy. If you want that, then > please don't refer to this as "trusted". It is implied that all the code in > GRUB is already trusted by its user. The difference here is that our system > would be hardened against physical attack, it doesn't change anything about > who is able to "trust" your computer and who isn't. Alright, hardened then. Personally I would still use "trusted", but it has been a bit overly (mis)used in the recent past, which could lead to misunderstandings. 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: GRUB trusted boot framework
phcoder wrote: > Jan Alsenz wrote: >> phcoder wrote: >>>> Oh, I want! >>>> If I remember correctly, exactly this broke the protection on some >>>> game console! >>> Do you refer to Xbox crack based on King kong game? For once their goal >>> is the evil one. For second the problem is a buffer overflow in >>> rendering engine, not the not checking part. If you want to make a >>> secure system it must be free of such bugs. Or you may as well hash the >>> whole hd and be hacked through network code. Here is where advantages of >>> open developement come in play >> >> It is totally irrelevant, if the purpose is good or evil, if it can >> break the >> system. >> And since it is awfully difficult to produce bug free code, the goal >> must be to >> reduce the code that has to be bug free to the absolute (and openly >> known) >> minimum: In this case I'd say the reasonable choice is the fs driver >> code. >> > You can't really do this. You can safeguard from e.g. fonts drivers > bugs. But what do you do with vulnerabilities with usb code. Some may > connect an evil mouse to the computer Ok, your right, the definition should be: The fs drivers, and everything else, that takes non disk input (this includes keyboard, command-line parser, mouse, network, pci probe, etc.). But I still think, that this is better, that everything above plus any component, that reads a file! If there is a way to prevent bugs in a part of our code, to hit our security system, we should use it, because as we know - bugs DO occur. There is alway the chance to be hit by new ideas and attack vectors, you can't prevent that, but if we can, we should protect against the one we know. >>>> But how do I get it into every possible loader? >>> s/grub_gzio_open(filename, 1)/grub_gnupg_open(filename, >>> GZIO_TRANSPARENT) >>> s/grub_file_open(filename)/grub_gnupg_open(filename, 0) >> >> With "every possible loader", I wanted to include unknown future loaders. >> > New loaders will use the existing ones as a template. I did > >> That would be a good idea. >> The difference between your and my solution was, that mine it had >> secure as default. > Mine too. It involves just using right code. If a developer wants to > wrote unsecure code he can always, otherwise I don't see why he wouldn't Yes, but it's a matter good design and convenience. If it can, secure should always be default, without anyone having to think about it. If security needs to be explicitly put in a and someone fails to do that, he can blame you for not telling him to do that, but if you have secure defaults and someone uses insecure, you can blame him for not following good practices/reading the docs/etc. This is especially useful if many people work on the code, like open source projects, and not everyone might be aware of the security implication of his/her actions. > use e.g. linux loader as a template >> - (It may be useful to have some order within the hooks) > It's even necessary. Otherwise you can't know if you have first to > compress or to sign Agreed. 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: GRUB trusted boot framework
phcoder wrote: >> Oh, I want! >> If I remember correctly, exactly this broke the protection on some >> game console! > Do you refer to Xbox crack based on King kong game? For once their goal > is the evil one. For second the problem is a buffer overflow in > rendering engine, not the not checking part. If you want to make a > secure system it must be free of such bugs. Or you may as well hash the > whole hd and be hacked through network code. Here is where advantages of > open developement come in play It is totally irrelevant, if the purpose is good or evil, if it can break the system. And since it is awfully difficult to produce bug free code, the goal must be to reduce the code that has to be bug free to the absolute (and openly known) minimum: In this case I'd say the reasonable choice is the fs driver code. >> But how do I get it into every possible loader? > s/grub_gzio_open(filename, 1)/grub_gnupg_open(filename, GZIO_TRANSPARENT) > s/grub_file_open(filename)/grub_gnupg_open(filename, 0) With "every possible loader", I wanted to include unknown future loaders. >> I also checked the loopback code and it uses the standard >> grub_file_read, so for >> these cases a read version without a hook would be needed. > > Then how is your proposition with two file read functions different from > mine with two file read functions? What can be proposed is to merge > somehow all opening functions into one with following protype > grub_file_open (const char *filename, int flags, struct grub_file_info > *info) > Then on opening the function will do the default behavior with possible > override possible through flags. It has an advantage of future > expandability for possible new transparent transformations That would be a good idea. The difference between your and my solution was, that mine it had secure as default. I'm not yet sure about the flag solution though. If we want to keep the solution general - which I would prefer - the flag is only known to the transformation and the code who wants to avoid it. To clarify: I'm thinking about a general hook/transformation solution in kern/file.c . Everyone can register a hook there, and now the goal of the flags is, to selectively enable or disable hooks. Problem is, that these hooks are not necessarily all known to all components. My first thought for a solution was something like: - Every hook gets an unique ID (distribution controlled e.g. via wiki) - The flags are lists of these IDs - A hook can by default be active or inactive - (It may be useful to have some order within the hooks) Apart from solving the problem, this solution would have a few other advantages: - Existing filters, like gzio, could be ported to this generic framework - IDs could be grouped into classes, e.g. to say "I don't want any security hooks on this operation" for the loopback device I'm not yet happy with the flag-list implementation, so if someone has a better idea, I would be happy to hear it. >> By the way we're assuming here, that every file-system driver is free of >> exploitable bugs! >> To avoid this a real disk read hook would be needed, but of course >> that is >> largely impractical. (There might be options with "sparce" hashing - >> meaning >> only hashing the parts that are actually read, and including the map >> of read >> areas into the final hash) > And then after a minor write or fs self-maintenance it suddenly stops > working. You may as well not boot at all. Perfectly secure booter in 2 > bytes of x86-assembly: > eb fe : self: jmp self That's also part of what I meant with "largely impractical" ;) 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: GRUB trusted boot framework
Vesa Jääskeläinen wrote: > Jan Alsenz wrote: >> Vesa Jääskeläinen write: >>> I do like the idea what some protected systems use, they sign the binary >>> (in our case .mod file and kernels of loaded OSes). Now in that scenario >>> it is responsibility of the kernel module loader to first verify the >>> signature for correctness. This way the signature checking would be >>> somewhat transparent to the rest of the system. >>> >>> I do not see a need to add any hooks to disk read. It should be >>> responsibility of the code needing signature checking to handle that. >> Well, since to trusted operation should be transparent (and in my opinion >> should >> not need code changes in something like the loaders - so if someone writes a >> new >> loader, it should work by default), that's where the hooks come in. >> Maybe the "disk read" was misleading, what I meant where "file reads". > > Hi, > > Well.. you probably don't want to verify authenticity of the fonts or > bitmaps in graphical menu? Oh, I want! If I remember correctly, exactly this broke the protection on some game console! > Anyway. I think the right place for verification hook in this case is > the module or OS kernel loader. > > If you think otherwise. Then you have to provide a complete technical > design how it should work as I see no other good choice for it. > > (actually there is one other place that could be used, but I let you > come up with the idea after you have given a bit more though on the > implementation side :)) But how do I get it into every possible loader? My current suggestion would be to put a hook possibility into kern/file.c and extend the fs interface with a function to compare to files, to get rid of the double hashing problem mentioned by phcoder. I also checked the loopback code and it uses the standard grub_file_read, so for these cases a read version without a hook would be needed. By the way we're assuming here, that every file-system driver is free of exploitable bugs! To avoid this a real disk read hook would be needed, but of course that is largely impractical. (There might be options with "sparce" hashing - meaning only hashing the parts that are actually read, and including the map of read areas into the final hash) 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: GRUB trusted boot framework
Vesa Jääskeläinen write: > Hi All, > > Ok. Please keep the fighting of TPM out of this thread ;). Lets keep it > to the topic first... (I am already waiting for summary of that other > discussion at some point ;)) > > Jan Alsenz wrote: >> Next I think we can agree, that some sort of trusted boot chain can be >> useful. >> >> Also there should be more than one implementation for this (or at least the >> possibility to have them). > > I like the idea of modularity in here. However. It should work with > different schemes but same generic interfaces if that is what is planned. That was what I had in mind. >> If we could agree on this, then I think we could find a way to extend the >> GRUB >> module system to fully allow this. >> >> From my point of view the minimal needed features for these systems are: >> - easy exchange of the MBR binary to be installed >> - easy exchange of the core.img loader binary >> - hooks for any disk read (not sure if write is necessary) > > Note: I will skip MBR+core.img validation for a reason here now. > > I do like the idea what some protected systems use, they sign the binary > (in our case .mod file and kernels of loaded OSes). Now in that scenario > it is responsibility of the kernel module loader to first verify the > signature for correctness. This way the signature checking would be > somewhat transparent to the rest of the system. > > I do not see a need to add any hooks to disk read. It should be > responsibility of the code needing signature checking to handle that. Well, since to trusted operation should be transparent (and in my opinion should not need code changes in something like the loaders - so if someone writes a new loader, it should work by default), that's where the hooks come in. Maybe the "disk read" was misleading, what I meant where "file reads". 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: GRUB trusted boot framework
phcoder wrote: >> Ok, but your already talking of a specific solution here. My >> conclusion would >> be: The hooks need to be able to determine the filename, that is >> currently read. >> > And then also where it comes from but some files may have different > filenames. IMO the solution work independently of the order of files and > where they come from. TPM checking is too limited for grub2 architecture. I agree and I'm not talking TPM here. Do you know if it is possible to determine where the files come from? >> The reason why I want generic read hooks, is that I want it to inter >> operate >> with everything else. So I should not need to figure out what files >> e.g. the >> linux loader is going to read, or change it's code to do so. > You can do anything secure without collaboration from upper layers. > Consider a huge loopback image from which you load only kernel. In you > solution it will unnecessary check the whole image Hmm, to be precise we're interested in file reads. So if the loopback image is implemented as disk driver, it should work. 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: GRUB trusted boot framework
phcoder wrote: >> - hooks for any disk read (not sure if write is necessary) > This way how trusted grub does it is an ad-hoc solution which results in > a MESS. They just try to hash and rehash everything without design. So > if grub is instructed to load all modules in a directory and filesystem > is reindexed then grub will load the same modules in a different order > which results in a different hash. IMO we can't allow such thing to come > to grub2 it's just against its basic design principles. Much better > would be a layer similar to gzio: > > grub_gnupg_open (const char *filename, int flags, struct grub_gnupg_info > *info); > Which internally checks the certificate. This layer can also > encrypt/decrypt from gnupg containers > Then all kernel and config loads would use this function instead of > grub_gzio_open and grub_gnupg_open would check if its contents is > gzipped. Flags can include: > GRUB_GNUPG_FLAGS_ALLOW_UNSIGNED > if signature can be checked later on (e.g. signed ELF) > Then the behavior is controlled by an environment variable > allow_unsigned=yes|no > If grub_gnupg_open is invoked without GRUB_GNUPG_FLAGS_ALLOW_UNSIGNED > and allow_unsigned=no and signature is broken or not present it should > prompt for password (if it isn't supplied yet) and write something like > File %s is unsigned. Are you sure you want to load it? Type "YES" if you > do. Ok, but your already talking of a specific solution here. My conclusion would be: The hooks need to be able to determine the filename, that is currently read. The reason why I want generic read hooks, is that I want it to inter operate with everything else. So I should not need to figure out what files e.g. the linux loader is going to read, or change it's code to do so. Greets, Jan signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
GRUB trusted boot framework
Hello! Alright, lets try to end the pointless (in the sense, that I guess noone here, including myself, will change their opinion anytime soon) TPM discussion and get something done. First I'd say we can agree, that we don't agree on whether/how to use a TPM. I don't know about you, but I can perfectly live with that! Next I think we can agree, that some sort of trusted boot chain can be useful. Also there should be more than one implementation for this (or at least the possibility to have them). If we could agree on this, then I think we could find a way to extend the GRUB module system to fully allow this. From my point of view the minimal needed features for these systems are: - easy exchange of the MBR binary to be installed - easy exchange of the core.img loader binary - hooks for any disk read (not sure if write is necessary) (I didn't check if any of these is already implemented) Last part to agree on would then be, that these infrastructure features should be in the mainline code. That way it would be easy to develop various trusted boot solutions (and probably some other systems too), but keep all the controversial code out of mainline. 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
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
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
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: [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: 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
Robert Millan wrote: > On Fri, Feb 20, 2009 at 03:03:04AM +0200, Alex Besogonov wrote: >> On Fri, Feb 20, 2009 at 2:29 AM, Jan Alsenz >> wrote: >> [skip] >>>The TPM can proof to another party, that the PCRs have certain >>> values (of >>> course the communication needs to be established 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
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: 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
phcoder wrote:
>> It's not complete SHA-1, but the rest should be just a constant offset.
> I already said how it differs from standard one. If you feed padded
> byteswapped data to it and then byteswap the rsult back you obtain
> exactly normal SHA-1. But as I said if size is fixed it's compeletely
> equivalent in security to normal SHA-1 (you can easily prove formally
> that any successful attack on one variant immediately results in
> successful attack on another variant)
That's what I meant ;)
>> But I'm still not sure, what you are trying to do here, is the MBR
>> your root of
>> trust?
>
> I'm trying to achieve universal verification scheme which is able to do
> what is needed to support tpm ("prolonging chain of trust" in tpm
> unstandard parlance) without using tpm itself. Such scheme can in future
> be useful in other applications as well.
Okay.
But I think it won't work.
>> 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.
- 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.
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
Hi! Wow, cool work! It's not complete SHA-1, but the rest should be just a constant offset. But I'm still not sure, what you are trying to do here, is the MBR your root of trust? If not, who checks the MBR? Greets, Jan phcoder wrote: > Hello, as promised I wrote an mbr which performs SHA-1. To squeeze the > code I had to remove chs and to change the bootdrive installer will have > to overwrite corresponding instruction. SHA-1 implemented in it is > little-endian and without padding. Standard version is big-endian and > with padding. In this case padding is unnecessary since a sector is > always 512 bytes. Litt-le endian means just that data isn't byte-swapped > before hashing. And the hash in sector has to be written in little > endian and the double should be in order > h1,h2,h3,h4,h0 > I also implemented the same thing as standalone program > Regards > Vladimir 'phcoder' Serbinenko 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
Vesa Jääskeläinen wrote: > In case it will get some day in. I would propose that you make own MBR > code like that gets compiled to own img file like tpmboot.img (512 > bytes). Then you can just provide img file for tool chain. You are > probably throwing code away anyway from normal mbr boot code. That should be possible I guess. And I have multiple versions, using different TPM commands. One of the versions keeps all the existing functionality! I had to squeeze the existing code a bit though. It should still work as expected, but I didn't have the time to test it yet. (If someone wants to volunteer, I could send the code). 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
I agree too! Multiple methods are interesting and everything that can be, should be placed in modules. But some parts of a trusted boot chain need to be in the MBR, etc. which is mainline code (regardless of how how you build it). The way I have implemented my version of the MBR right now is with compile flags: If you don't want/need TPM code it won't be on your system! If you compile it with TPM support, it won't boot if there is no TPM (I don't like silent failures). Greets, Jan Michael Gorven schrieb: > On Friday 20 February 2009 13:27:28 phcoder wrote: >> Free software is about freedom of choice. I think we should have >> possibility to have multiple authentication and key sources. Then one >> could e.g. not save password as md5 somewhere in configfile or embedded >> in module but check that this password opens luks. Or that it's a >> password of somebody in wheel group basing on /etc/passwd, /etc/shadow >> and /etc/group. In this case tpm-keyretrieve module may be developed >> outside of main trunk and if someone wants it he can download it > > 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. They > would have to explicitly enable and set it up. As Jan said, the TPM is a > passive device which can be used in any way we wish, and I don't see why > using some of its features to create a more secure system is wrong. > > Regards > Michael 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
Alex Besogonov wrote: [skip] >>> As far as I understand - no. >> Actually - it is. >> Check the "TCG PC Client Specific Implementation Specification for >> Conventional >> Bios" or "TCG PC Specific Implementation Specification" at >> https://www.trustedcomputinggroup.org/specs/PCClient/ >> and look for CRTM (Core Root of Trust for Measurement) > Yes, BIOS is a root of trust, but not the Core Root. BIOS itself is > checked before execution (pages 20 and onwards in the "TCG PC Client > Specific Implementation Specification for Conventional Bios" spec), > even before dynamic memory is initialized. Well on page 32 they list two options, how to implement the CRTM: BIOS Boot Block or entire BIOS Since the BIOS is usually updateable, it seems that most manufacturers opt for BIOS Boot Block, which I assume will be something like: "lets put the first sector of the BIOS in ROM" (of course it might be something else completely, but I doubt it) >>> 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. Sounds interesting. >>> Second, the only safe action non TPM-aware MBR can perform if it >>> detects tampering is just shutting down hard. Everything else is >>> dangerous. >> 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? > PS: thanks for detailed explanation! Sure, glad I could help! 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
Hi! Alright, lets try to make sure everyone is talking about the same things here. First of all a TPM is not just some kind of secure memory only accessible from early BIOS, it basically is a small computer. You can only send it commands, and it can "decide" to reject them, e.g. if you try to read out the endorsement private key. (Of course there is always the chance that the TPM has hidden commands to do that, or the manufacturer already has the keys anyway) Next, we need to keep in mind, what kind of attack and attacker we're trying to defend against. As I see it we have an attacker with relatively low-tech abilities (he cannot replace chips, break the TPM physically, or knows it's "dark secrets"), who gets physical access to the machine. So he is basically limited to flashing the BIOS, replacing anything, that is written on a disk, controling the network, etc. I excluded a higher grade attacker, because, if we have one of these, there is nothing we can do. Any solution, TPM or not, can be broken under these assumptions. Now for, what the TPM can do and is SUPPOSED to do according to the specification. First there is nothing it can do actively, like interrupt or change anything in the system. It is pretty passive and only acts on request. The TPM has a number of PCRs (Platform Configuration Registers), where it can store and concatenate hash values - this is what every stage of a trusted boot chain has to do. Every stage has to get a hash of the next one, before it executes it. (The assumption here is, that the PCRs cannot be tampered with and the stages to it correctly) So in the end (after boot) you have a bunch of PCR values, that represent all the code and data, that was used to boot the system. If you have this and are sure, that the current configuration is correct, you have a reference value of the expected system state, which you can use for the following: - seal a key: You can create a key with the TPM and "bind" it to specific values of the PCRs, so it only en/decrypts with it, if these values match. You can encrypt any kind of data with this, but the only useful thing for boot is to encrypt a cryptographic key needed to further start the system. - remote attestation: 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) The TPM has a few more functions, but I think they are not relevant here. And now for the ongoing discussion: (things I didn't comment on should have been answered above) Alex Besogonov wrote: > On Thu, Feb 19, 2009 at 9:30 PM, phcoder wrote: >>> Yes, but that's way too hard. >> Sure? There was a demonstration when rsa key was recovered just by plotting >> variations on powerline of usb port > TPM performs encoding/decoding, and I consider it secure. > > I don't think it's possible to recover the symmetric key used later > during normal system operation. It could possibly be done, but that is out of scope here. Regardless of what you use to establish your trust, if someone can extract the key for your disk encryption from the running system your screwed. >> And what about cache attack? > You mean frozen memory chip attack? No, cache timing. (search for "aes cache timing") >>> That's possible, but again I consider this not critical. BIOS itself >>> is checksummed and checked by the root of trust. >> Isn't bios (or part of it) the root of "trust" > As far as I understand - no. Actually - it is. Check the "TCG PC Client Specific Implementation Specification for Conventional Bios" or "TCG PC Specific Implementation Specification" at https://www.trustedcomputinggroup.org/specs/PCClient/ and look for CRTM (Core Root of Trust for Measurement) >>> Why? >> Because I don't want support this technology. TPM=obfuscation=unsecurity. > No. TPM is just a secure way to store keys, nothing more. It can be > used for good and bad. Well, it is a bit more, but it's definitely not just obfuscation. Actually it's pretty well documented what it's supposed to do (all the specification is available, there is an open-source emulation implementation of it). What you are referring to, is that you don't trust it to have ONLY this functionality, but you can make the same argument for every part of your PC! Are you sure, there is nothing in your network card, CPU or hard drive, that can be used against you? >> And as an opensource and open security fan I can't claim to have solved an >> impossible problem. But if you want to use obfuscation schemes it's your >> right > I want a reasonably secure scheme that DOESN'T use obfuscation. > >> You assume that noone will develop hypervisor able to fool tpm bios. One >> could powercut the tpm chip (similar to how a resistor is remove to avoid >> burning efuses in xbox) then power would be reestablished to it and bios >> would be executed on hypervisor which will retrieve the keys. > Would not work. Or rather it'll
Re: [PATCH] Long linux kernel command lines
Hi again!
I checked the boot protocol documentation and found that since version
2.06 (kernel 2.6.22) there is a field with the supported command line size.
I updated my patch to respect this field if it is present, otherwise the
maximum 4k buffer is used.
Greets,
Jan
Jan Alsenz schrieb:
> 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.
>
> I found a patch on this list from last year (
> http://lists.gnu.org/archive/html/grub-devel/2008-05/msg5.html ),
> which apparently was lost in some other discussion.
> I didn't use it, because I think my version works better with older kernels.
>
> I tested this on my machine and it worked without a problem with a
> 2.6.27 kernel.
>
> It would be great if you could add this (or something like it), so I can
> switch to the official version again.
>
> Thanks and Regards,
>
> Jan
>
--- loader/i386/pc/linux.c.orig 2009-02-11 10:56:27.0 +0100
+++ loader/i386/pc/linux.c 2009-02-11 10:56:38.0 +0100
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#define GRUB_LINUX_CL_OFFSET 0x9000
#define GRUB_LINUX_CL_END_OFFSET 0x90FF
@@ -38,11 +39,15 @@
static grub_size_t linux_mem_size;
static int loaded;
+static char* kernel_cl_space = NULL;
+#define GRUB_LINUX_CL_MAX_SIZE 0x1000 /* maximum defined for linux kernels */
static grub_err_t
grub_linux_unload (void)
{
grub_dl_unref (my_mod);
+ grub_free(kernel_cl_space);
+ kernel_cl_space = NULL;
loaded = 0;
return GRUB_ERR_NONE;
}
@@ -119,9 +124,14 @@
lh.loadflags |= GRUB_LINUX_FLAG_CAN_USE_HEAP;
}
- if (grub_le_to_cpu16 (lh.version) >= 0x0202)
- lh.cmd_line_ptr = grub_linux_real_addr + GRUB_LINUX_CL_OFFSET;
- else
+ if (grub_le_to_cpu16 (lh.version) >= 0x0202) {
+ if (grub_le_to_cpu16 (lh.version) >= 0x0206) {
+ kernel_cl_space = grub_malloc(lh.cmdline_size+1);
+ } else {
+ kernel_cl_space = grub_malloc(GRUB_LINUX_CL_MAX_SIZE);
+ }
+ lh.cmd_line_ptr = kernel_cl_space;
+ } else
{
lh.cl_magic = grub_cpu_to_le16 (GRUB_LINUX_CL_MAGIC);
lh.cl_offset = grub_cpu_to_le16 (GRUB_LINUX_CL_OFFSET);
@@ -245,16 +255,29 @@
((GRUB_LINUX_MAX_SETUP_SECTS - setup_sects - 1)
<< GRUB_DISK_SECTOR_BITS));
+ /* Choose the command line area */
+ char* cl_end;
+ if (kernel_cl_space) {
+ dest = kernel_cl_space;
+ if (grub_le_to_cpu16 (lh.version) >= 0x0206) {
+ cl_end = dest + lh.cmdline_size;
+ } else {
+ cl_end = dest + GRUB_LINUX_CL_MAX_SIZE - 1;
+ }
+ } else {
+ dest = grub_linux_tmp_addr + GRUB_LINUX_CL_OFFSET;
+ cl_end = grub_linux_tmp_addr + GRUB_LINUX_CL_END_OFFSET;
+ }
+
/* Specify the boot file. */
- dest = grub_stpcpy (grub_linux_tmp_addr + GRUB_LINUX_CL_OFFSET,
+ dest = grub_stpcpy (dest,
"BOOT_IMAGE=");
dest = grub_stpcpy (dest, argv[0]);
/* Copy kernel parameters. */
for (i = 1;
i < argc
-&& dest + grub_strlen (argv[i]) + 1 < (grub_linux_tmp_addr
- + GRUB_LINUX_CL_END_OFFSET);
+&& dest + grub_strlen (argv[i]) + 1 < cl_end;
i++)
{
*dest++ = ' ';
--- include/grub/i386/linux.h.orig 2009-02-11 10:43:01.0 +0100
+++ include/grub/i386/linux.h 2009-02-11 10:50:33.0 +0100
@@ -123,6 +123,15 @@
grub_uint16_t pad1; /* Unused */
char *cmd_line_ptr; /* Points to the kernel command line */
grub_uint32_t initrd_addr_max;/* Highest address for initrd */
+ /* 2.05+ */
+ grub_uint32_t kernel_alignment; /* Physical addr alignment required for
kernel */
+ grub_uint8_t relocatable_kernel; /* Whether kernel is relocatable or not
*/
+ grub_uint8_t pad2[3];/* Unused */
+ /* 2.06+ */
+ grub_uint32_t cmdline_size; /* Maximum size of the kernel command
line */
+ /* 2.07+ */
+ grub_uint32_t hardware_subarch; /* Hardware subarchitecture */
+ grub_uint64_t hardware_subarch_data; /* Subarchitecture-specific data */
} __attribute__ ((packed));
/* Boot parameters for Linux based on 2.6.12. This is used by the setup
signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Long linux kernel command lines
Hi! I also don't know the exact details, it sure would be better to have some kind of detection! But the limit I set is not that arbitrary: --- Quote from Documentation/kernel-parameters.txt --- The number of kernel parameters is not limited, but the length of the complete command line (parameters including spaces etc.) is limited to a fixed number of characters. This limit depends on the architecture and is between 256 and 4096 characters. It is defined in the file ./include/asm/setup.h as COMMAND_LINE_SIZE. --- Quote end --- And from what I've seen in the kernel code the maximum supported length is copied from lh.cmd_line_ptr into kernel space and processed. Greets, Jan phcoder schrieb: > Hello! > I don't know the linux booting protocol in details but it looks like you > patch replaces one arbitrary limit (256) by another (4096). Is there any > way of avoiding any arbitrary limit at all wothout modyfiing boot protocol? > Thanks > Vladimir 'phcoder' Serbinenko > 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. >> >> I found a patch on this list from last year ( >> http://lists.gnu.org/archive/html/grub-devel/2008-05/msg5.html ), >> which apparently was lost in some other discussion. >> I didn't use it, because I think my version works better with older >> kernels. >> >> I tested this on my machine and it worked without a problem with a >> 2.6.27 kernel. >> >> It would be great if you could add this (or something like it), so I can >> switch to the official version again. >> >> Thanks and Regards, >> >> 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 > signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] Long linux kernel command lines
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.
I found a patch on this list from last year (
http://lists.gnu.org/archive/html/grub-devel/2008-05/msg5.html ),
which apparently was lost in some other discussion.
I didn't use it, because I think my version works better with older kernels.
I tested this on my machine and it worked without a problem with a
2.6.27 kernel.
It would be great if you could add this (or something like it), so I can
switch to the official version again.
Thanks and Regards,
Jan
--- loader/i386/pc/linux.c.orig 2009-02-10 17:45:05.0 +0100
+++ loader/i386/pc/linux.c 2009-02-10 17:25:22.0 +0100
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#define GRUB_LINUX_CL_OFFSET 0x9000
#define GRUB_LINUX_CL_END_OFFSET 0x90FF
@@ -38,11 +39,15 @@
static grub_size_t linux_mem_size;
static int loaded;
+static char* kernel_cl_space = NULL;
+#define GRUB_LINUX_CL_MAX_SIZE 0x1000 /* maximum defined for linux kernels */
static grub_err_t
grub_linux_unload (void)
{
grub_dl_unref (my_mod);
+ grub_free(kernel_cl_space);
+ kernel_cl_space = NULL;
loaded = 0;
return GRUB_ERR_NONE;
}
@@ -119,9 +124,10 @@
lh.loadflags |= GRUB_LINUX_FLAG_CAN_USE_HEAP;
}
- if (grub_le_to_cpu16 (lh.version) >= 0x0202)
- lh.cmd_line_ptr = grub_linux_real_addr + GRUB_LINUX_CL_OFFSET;
- else
+ if (grub_le_to_cpu16 (lh.version) >= 0x0202) {
+ kernel_cl_space = grub_malloc(GRUB_LINUX_CL_MAX_SIZE);
+ lh.cmd_line_ptr = kernel_cl_space;
+ } else
{
lh.cl_magic = grub_cpu_to_le16 (GRUB_LINUX_CL_MAGIC);
lh.cl_offset = grub_cpu_to_le16 (GRUB_LINUX_CL_OFFSET);
@@ -245,16 +251,25 @@
((GRUB_LINUX_MAX_SETUP_SECTS - setup_sects - 1)
<< GRUB_DISK_SECTOR_BITS));
+ /* Choose the command line area */
+ char* cl_end;
+ if (kernel_cl_space) {
+ dest = kernel_cl_space;
+ cl_end = dest + GRUB_LINUX_CL_MAX_SIZE - 1;
+ } else {
+ dest = grub_linux_tmp_addr + GRUB_LINUX_CL_OFFSET;
+ cl_end = grub_linux_tmp_addr + GRUB_LINUX_CL_END_OFFSET;
+ }
+
/* Specify the boot file. */
- dest = grub_stpcpy (grub_linux_tmp_addr + GRUB_LINUX_CL_OFFSET,
+ dest = grub_stpcpy (dest,
"BOOT_IMAGE=");
dest = grub_stpcpy (dest, argv[0]);
/* Copy kernel parameters. */
for (i = 1;
i < argc
-&& dest + grub_strlen (argv[i]) + 1 < (grub_linux_tmp_addr
- + GRUB_LINUX_CL_END_OFFSET);
+&& dest + grub_strlen (argv[i]) + 1 < cl_end;
i++)
{
*dest++ = ' ';
signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
