Hi,
Here is a patch to fix core_path_dev path, because it should depends on the
--directory parameters.
Thank you.
--
Alexandre Bique
grub2-fix-grub-setup-directory.patch
Description: Binary data
___
Grub-devel mailing list
Grub-devel@gnu.org
http://
Hi,
Linux needs to locate important data structure such as ACPI. In normal
EFI booting, these information can be retrieved from efi system table,
However, in case of cross booting, for example, booting 32-bit kernel
from 64-bit firmware, or vice verse, the efi information is not
usable, which lead
This patch copy the ACPI information to conventional memory and
emulated the extended bios data area. With this, linux can find
information about ACPI even if efi information is not available, thus
resolving the above problem.
In my efiemu I have a code which does exactly the opposite. But
addi
I'd be happy to document errors and such if someone can recommend what
the best path of target is.
Maya rendering doesn't actually touch the video cards (some of our
linux systems don't even have video cards), and general usage servers
don't care much so drivers for the systems aren't a hug
Hi, all.
I'm reading the grub source code. and found i got no idea how the grub
getting into the normal mode.
in file kern/main.c
/* Load the normal mode module. */
grub_load_normal_mode ();
/* Enter the rescue mode. */
grub_enter_rescue_mode ();
I think the grub_load_normal_mode() fun
On Sat, 2009-02-28 at 01:28 +0800, liu Aleaxander wrote:
> Hi, all.
>
> I'm reading the grub source code. and found i got no idea how the
> grub getting into the normal mode.
>
> in file kern/main.c
> /* Load the normal mode module. */
> grub_load_normal_mode ();
>
> /* Enter the rescue
Hi,
This patch implements badram filtering in GRUB. It's the same idea as in
http://rick.vanrein.org/linux/badram/ but applied to GRUB.
The badram module sits between loaders (or other users like lsmmap) and
filters the mmap entries, but only when user previously set the "badram"
variable (whos
On Sun, Feb 22, 2009 at 01:30:55AM +, Kalamatee wrote:
>
>
> 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.
I just committed it.
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decid
On Sun, Feb 22, 2009 at 03:26:32AM +0200, Alex Besogonov wrote:
> 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 se
On Mon, Feb 23, 2009 at 03:34:56AM +0100, step21 wrote:
> if there is one company that I think would try to lock their hardware
> down as much as possible using something like a tpm, it's apple, but
> they don't.
You're looking at the wrong place. Check the iphone.
Anyway, it's nice to hear TPM
On Sun, Feb 22, 2009 at 03:14:07AM +0200, Alex Besogonov wrote:
> 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.
On Sun, Feb 22, 2009 at 03:21:21AM +0200, Alex Besogonov wrote:
> 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.
>>
On Sun, Feb 15, 2009 at 11:14:18PM +0800, Bean wrote:
> diff --git a/conf/sparc64-ieee1275.rmk b/conf/sparc64-ieee1275.rmk
> index 640ceda..18c108e 100644
> --- a/conf/sparc64-ieee1275.rmk
> +++ b/conf/sparc64-ieee1275.rmk
Don't bother updating sparc64-ieee1275.rmk, it's completely broken by now.
On Sat, Feb 21, 2009 at 09:10:11PM -0500, Isaac Dupree wrote:
>
> (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 boar
On Sun, Feb 22, 2009 at 03:02:43AM +0200, Alex Besogonov wrote:
> 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 t
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 b
It's funny, we're all discussing about performing security measurements in
GRUB and nobody mentioned that our user interface lacks even the most basic
lock mechanism :-)
Perhaps this would be a good time to retake the discussion on implementing
an equivalent to "lock" and "password" commands. I
On Fri, Feb 27, 2009 at 11:15:41AM +, Alexandre Bique wrote:
> Hi,
>
> Here is a patch to fix core_path_dev path, because it should depends on the
> --directory parameters.
Committed, thanks.
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
ho
On Wed, Feb 25, 2009 at 12:59:31PM +0100, phcoder wrote:
> Hello. Marco Gerards already agreed that this port is ok. I made some
> investigations into their code and have to say that it won't be just a
> port. It seems that some features (e.g. directory listing) are missing.
> It also uses di
On Mon, Feb 23, 2009 at 09:57:59AM +0100, phcoder wrote:
> Hello. Here is a fix for a leak I found when debugging grub-emu with
> valgrind
Committed, thanks.
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobo
On Sat, Feb 21, 2009 at 07:40:35PM -0500, BandiPat wrote:
>>
>> 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?
Martin
On Wed, Feb 11, 2009 at 06:01:42PM -0500, BandiPat wrote:
> Hey guys, where does it specify the initial screen border title?
> (GNU GRUB version 1.96)
>
> I would at least like to change that for the Zenwalk build, if that's
> ok? I've looked in several pieces of the code, but can't seem to find
On Sun, Feb 22, 2009 at 10:27:27AM +0100, phcoder wrote:
> Robert Millan wrote:
>> 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 a
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 exc
At Fri, 27 Feb 2009 22:41:47 +0100,
Robert Millan wrote:
> I will try. Does someone have a known-working Multiboot / ELF64 image I can
> test with?
You can try Viengoos:
http://plato.walfield.org/viengoos
Here is a grub.cfg menu entry:
menuentry "Viengoos" {
multiboot /viengoos -D 3
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.
Encrypted filesystems don't prevent some attacks as inconsistent
rollback. Suppose th
On Fri, Feb 27, 2009 at 10:56:48PM +0100, Jan Alsenz wrote:
> > 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.
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 cipherte
On Fri, Feb 27, 2009 at 11:01:30PM +0100, Neal H. Walfield wrote:
> At Fri, 27 Feb 2009 22:41:47 +0100,
> Robert Millan wrote:
> > I will try. Does someone have a known-working Multiboot / ELF64 image I can
> > test with?
>
> You can try Viengoos:
>
> http://plato.walfield.org/viengoos
>
>
>
On Fri, Feb 27, 2009 at 11:55:55PM +0100, 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
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
I stand corrected; But in that case, measurement can still be implemented
at the filesystem level?
Yes it can be done. Most common way is to attach a mac to every sector
(like a signature but uncheckable without the key). One could also
implement mac on filesystems like btrfs. It doesn't solv
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 Rob
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 encrypte
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
Alexandre Bique wrote:
On Thu, Feb 26, 2009 at 2:35 PM, Christian Franke
<...> wrote:
What is the error message you got on Cygwin ?
The problem is that make install installs elf binaries and not win32
binaries. But win32 binaries are compiled. I moved win32 binaries by
hand.
I co
Alexandre Bique wrote:
Hi,
On windows with cygwin or mingw, when i do make install, it installs
linux elf32 files instead of windows *.exe.
Here is a patch to install the right file depending on $(EXEEXT).
Thank you.
Ooouuuppss, there is a little mistake : $(EXEXT) instead of $(EXEEX
On Sat, Feb 28, 2009 at 12:32 AM, Christian Franke
wrote:
>
> Alexandre Bique wrote:
>>
>>
>>>
>>> Hi,
>>>
>>> On windows with cygwin or mingw, when i do make install, it installs
>>> linux elf32 files instead of windows *.exe.
>>>
>>> Here is a patch to install the right file depending on $(EXEEX
On Sat, Feb 28, 2009 at 3:54 AM, Robert Millan wrote:
> On Sun, Feb 15, 2009 at 11:14:18PM +0800, Bean wrote:
>> diff --git a/conf/sparc64-ieee1275.rmk b/conf/sparc64-ieee1275.rmk
>> index 640ceda..18c108e 100644
>> --- a/conf/sparc64-ieee1275.rmk
>> +++ b/conf/sparc64-ieee1275.rmk
>
> Don't bothe
39 matches
Mail list logo
