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
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
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
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
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()
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 mode. */
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 (whose
On Sun, Feb 22, 2009 at 01:30:55AM +, Kalamatee wrote:
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.
I just committed it.
--
Robert Millan
The DRM opt-in fallacy: Your data belongs to us. We will
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 sensitive
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 TPMs
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. where do you
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.
I'm not sure
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 board.
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 true (which
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
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
how)
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 dirty
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
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 said it he was
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 are supposed
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
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 -o
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
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
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
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
Here is a
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_{key,sector}
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
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
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
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
On Sat, Feb 28, 2009 at 12:32 AM, Christian Franke
christian.fra...@t-online.de 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
On Sat, Feb 28, 2009 at 3:54 AM, Robert Millan r...@aybabtu.com 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
36 matches
Mail list logo
