Re: EFI-dualbooting OSX and Linux on iMac with T7400-CPU

[Eeri Kask]

bibo,mao wrote:
>> 2.6.18.5.
> There exists one bug in Linux kernel only EFI bios relative at
> http://marc.theaimsgroup.com/?l=linux-kernel&m=116157536316034&w=2
> I do not know whether 2.6.18.5 incorporates this bug.

Oh, I see.  This bug is not corrected in 2.6.18.5.
As a side note, in contrast, in  "arch/x86_64/kernel/"  there are
seemingly no files having anything to do with efi.  Maybe this is of no
importance though.

>> Maybe MacOS if booting from CD sets up some faked BIOS environment so
>> Linux and X11 are in believing it is usual IBM-PC-hardware, but if
>> booting with grub2 this is not the case and then linux fails?
> I am not familiar with Mac machine, In general there exists two types of
> bios. One is EFI bios, the other is legacy pc bios. I doubt that
> syslinux-CD boots from legacy pc bios but not EFI bios. You can enter
> "dmesg" command to find memory map information to judge which bios kernel
> boots from.

:-)

I sincerely apologise for the long attachment in advance; here I send
you the dmesg output in full, most of it I do not understand.

Greetings,

Eeri Kask

8<8<

Bootdata ok (command line is root=/dev/sda5 BOOT_IMAGE=bzImage )
Linux version 2.6.18.5 ([EMAIL PROTECTED]) (gcc version 4.1.1 (Gentoo 4.1.1))
#1 SMP PREEMPT Wed Dec 6 16:09:02 CET 2006
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000e - 0010 (reserved)
 BIOS-e820: 0010 - 7f103000 (usable)
 BIOS-e820: 7f103000 - 7f304000 (ACPI NVS)
 BIOS-e820: 7f304000 - 7febe000 (ACPI data)
 BIOS-e820: 7febe000 - 7feef000 (ACPI NVS)
 BIOS-e820: 7feef000 - 7ff0 (ACPI data)
 BIOS-e820: 7ff0 - 8000 (reserved)
 BIOS-e820: f000 - f400 (reserved)
 BIOS-e820: fec0 - fec01000 (reserved)
 BIOS-e820: fed14000 - fed1a000 (reserved)
 BIOS-e820: fed1c000 - fed2 (reserved)
 BIOS-e820: fee0 - fee01000 (reserved)
 BIOS-e820: ffe0 - 0001 (reserved)
DMI 2.4 present.
ACPI: RSDP (v002 APPLE ) @
0x000fe020
ACPI: XSDT (v001 APPLE   Apple00 0x0093  0x0113) @
0x7fefd1c0
ACPI: FADT (v003 APPLE   Apple00 0x0093 Loki 0x005f) @
0x7fefb000
ACPI: HPET (v001 APPLE   Apple00 0x0001 Loki 0x005f) @
0x7fefa000
ACPI: MADT (v001 APPLE   Apple00 0x0001 Loki 0x005f) @
0x7fef9000
ACPI: MCFG (v001 APPLE   Apple00 0x0001 Loki 0x005f) @
0x7fef8000
ACPI: ASF! (v032 APPLE   Apple00 0x0001 Loki 0x005f) @
0x7fef7000
ACPI: SBST (v001 APPLE   Apple00 0x0001 Loki 0x005f) @
0x7fef5000
ACPI: ECDT (v001 APPLE   Apple00 0x0001 Loki 0x005f) @
0x7fef4000
ACPI: SSDT (v001 APPLE   SataPri 0x1000 INTL 0x20050309) @
0x7febb000
ACPI: SSDT (v001 APPLE   SataSec 0x1000 INTL 0x20050309) @
0x7feba000
ACPI: SSDT (v001 APPLE CpuPm 0x3000 INTL 0x20050309) @
0x7feef000
ACPI: DSDT (v001 APPLE   iMac6,1 0x00010001 INTL 0x20050309) @
0x
No mptable found.
On node 0 totalpages: 511592
  DMA zone: 2296 pages, LIFO batch:0
  DMA32 zone: 509296 pages, LIFO batch:31
ACPI: PM-Timer IO Port: 0x408
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 6:15 APIC version 20
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1 6:15 APIC version 20
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 1, version 32, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Setting APIC routing to flat
ACPI: HPET id: 0x8086a201 base: 0xfed0
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 8800 (gap: 8000:7000)
Built 1 zonelists.  Total pages: 511592
Kernel command line: root=/dev/sda5 BOOT_IMAGE=bzImage
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
time.c: Using 14.318180 MHz WALL HPET GTOD HPET/TSC timer.
time.c: Detected 2161.258 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Checking aperture...
Memory: 2043072k/2081804k available (3886k kernel code, 38328k reserved,
1916k data, 232k init)
Calibrating delay using timer specific routine.. 4328.85 BogoMIPS
(lpj=8657703)
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cach

Re: Conditionally building `grub-emu'

[Thomas Schwinge]

Hello!

On Thu, Dec 14, 2006 at 01:19:49PM +0100, Marco Gerards wrote:
> Thomas Schwinge <[EMAIL PROTECTED]> writes:
> > On request / suggestion / whatever ;-) of Marco I created the following
> > patch.
> 
> Thanks a lot for doing this!

Sure, sure.


> > The only remaining problem --- which only happens if building without
> > having `grub-emu' enabled --- is the following one:
> 
> Is this fixed already by what Okuji proposed (and possibly committed)?

Yesh, I think I validated it at that time.


Regards,
 Thomas


signature.asc
Description: Digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Stack protection via GCC's `-fstack-protector'

[Thomas Schwinge]

Hello!

On Wed, Nov 08, 2006 at 10:40:54PM +0100, I wrote:
> For some time, GCC now offers the following feature:
> 
> info Gcc
> #v+
> `-fstack-protector'
>  Emit extra code to check for buffer overflows, such as stack
>  smashing attacks.  This is done by adding a guard variable to
>  functions with vulnerable objects.  This includes functions that
>  call alloca, and functions with buffers larger than 8 bytes.  The
>  guards are initialized when a function is entered and then checked
>  when the function exits.  If a guard check fails, an error message
>  is printed and the program exits.
> #v-
> 
> I now happen to be running a GCC 4.1 installation which has that one
> enabled by default.  Unfortunately, building GNU Mach and GRUB2 (didn't
> check GRUB legacy) is affected by that:

To completely support this feature in kernel-like environments, work on
GCC itself is needed, see
, so for the mean time
I created the following patch to be able to continue building GRUB2 on
systems that have `-fstack-protector' enabled by default.  (This patch is
equal to what we've been using in GNU Mach for some time now.)


2006-12-15  Thomas Schwinge  <[EMAIL PROTECTED]>

* aclocal.m4 (grub_CHECK_STACK_PROTECTOR): New definition.
* configure.ac: Use it for testing the HOST and TARGET compilers.

Index: aclocal.m4
===
RCS file: /cvsroot/grub/grub2/aclocal.m4,v
retrieving revision 1.5
diff -u -p -r1.5 aclocal.m4
--- aclocal.m4  13 Aug 2005 18:44:14 -  1.5
+++ aclocal.m4  15 Dec 2006 19:18:18 -
@@ -343,3 +343,23 @@ dnl So use regparm 2 until a better test
[Catch gcc bug])
 fi
 ])
+
+dnl Check if the C compiler supports `-fstack-protector'.
+dnl Written by Thomas Schwinge.
+AC_DEFUN(grub_CHECK_STACK_PROTECTOR,[
+[# Smashing stack protector.
+ssp_possible=yes]
+AC_MSG_CHECKING([whether `$CC' accepts `-fstack-protector'])
+# Is this a reliable test case?
+AC_LANG_CONFTEST([[void foo (void) { volatile char a[8]; a[3]; }]])
+[# `$CC -c -o ...' might not be portable.  But, oh, well...  Is calling
+# `ac_compile' like this correct, after all?
+if eval "$ac_compile -S -fstack-protector -o conftest.s" 2> /dev/null; then]
+  AC_MSG_RESULT([yes])
+  [# Should we clear up other files as well, having called `AC_LANG_CONFTEST'?
+  rm -f conftest.s
+else
+  ssp_possible=no]
+  AC_MSG_RESULT([no])
+[fi]
+])
Index: configure.ac
===
RCS file: /cvsroot/grub/grub2/configure.ac,v
retrieving revision 1.35
diff -u -p -r1.35 configure.ac
--- configure.ac13 Dec 2006 22:30:19 -  1.35
+++ configure.ac15 Dec 2006 19:18:18 -
@@ -149,6 +149,19 @@ fi
 AC_CHECK_FUNCS(posix_memalign memalign)
 
 #
+# Compiler features.
+#
+
+# Smashing stack protector.
+grub_CHECK_STACK_PROTECTOR
+[# Need that, because some distributions ship compilers that include
+# `-fstack-protector' in the default specs.
+if [ x"$ssp_possible" = xyes ]; then
+  CFLAGS=$CFLAGS\ -fno-stack-protector
+fi]
+
+
+#
 # Check for target programs.
 #
 
@@ -225,6 +238,18 @@ if test "x$target_m32" = x1; then
   TARGET_LDFLAGS="$TARGET_LDFLAGS -m32"
 fi
 
+#
+# Compiler features.
+#
+
+# Smashing stack protector.
+grub_CHECK_STACK_PROTECTOR
+[# Need that, because some distributions ship compilers that include
+# `-fstack-protector' in the default specs.
+if [ x"$ssp_possible" = xyes ]; then
+  TARGET_CFLAGS=$TARGET_CFLAGS\ -fno-stack-protector
+fi]
+
 AC_SUBST(TARGET_CFLAGS)
 AC_SUBST(TARGET_CPPFLAGS)
 AC_SUBST(TARGET_LDFLAGS)


Regards,
 Thomas


signature.asc
Description: Digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: disk vs partition numbering

[Tristan Gingold]

On Thu, Dec 14, 2006 at 11:09:59AM +0100, adrian15 wrote:
> >On Wednesday 13 December 2006 09:59, adrian15 wrote:
> >>> For them their first hard disk (Who is going to have a zero-hard disk in
> >>> the real world. It has no sense) is C:, but you could name it 1.
> >>> And when they partition their hard disk they suppose that the first cut
> >>> it is the 1 not the 0.
> >
> >And you could name it 0.
> 
> This is in computing world... but if you go to a building you go to the 
> ground floor or to the 1st floor but you not do go to the 0th floor!
That's a pretty interesting example.  In US and Japan ground floor is 1st floor
while in *some* other countries (such as France) ground floor is 0th floor.
I concluded that some conventions are not universal and one have to choose
one.

Tristan.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: identifying module types

[Tristan Gingold]

[Sorry for the late reply]
On Tue, Dec 12, 2006 at 02:56:10PM -0600, Hollis Blanchard wrote:
> On Sat, 2006-12-09 at 06:31 +0100, Tristan Gingold wrote:
> > On Fri, Dec 08, 2006 at 06:02:31PM -0600, Hollis Blanchard wrote:
> > > On Fri, 2006-10-27 at 06:09 +0200, Tristan Gingold wrote:
[...]
> > > One option is a fixed-length encoded field, say 32 bytes wide. To avoid
> > > namespace collisions, we could require that projects prefix types with
> > > their project name, which must be at least 4 bytes.
> > Nb: UUID are 16 bytes and collisions are avoided.
> 
> Please detail your proposal.
You have exposed it just below better than I could.
 
> > I prefer the use of a fixed-length field.
> 
> Me too.
> 
> > But that's my own opinion (UUID are
> > easy to generate, to compare and well-known - do not reinvent the wheel).
> 
> UUIDs, e.g.  550e8400-e29b-41d4-a716-44665544, are also completely
> unintelligible, so they cannot be the only answer.
Sure.
 
> So far you seem to be advocating the following:
> module [--type TYPE | --uuid UUID] file
> 
> TYPE: an English word that GRUB translates to a UUID. GRUB must therefor
> maintain a table of known types and their associated UUIDs.
> UUID: a 16-byte number which can be represented as 36 ASCII characters
> (including hyphens).
> 
> How should we generate the UUIDs for the table in GRUB? I'll just run
> uuidgen here and create them myself?
Yes.

> Does anybody object to this scheme?
Tristan.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: identifying module types

[Tristan Gingold]

On Tue, Dec 12, 2006 at 03:48:34PM -0600, Hollis Blanchard wrote:
> On Fri, 2006-12-08 at 18:02 -0600, Hollis Blanchard wrote:
> > 
> > On the consumer side of multiboot (in this case Xen), we need to loop
> > over the tags, and when we find a module tag, how do we know which it
> > is? The Multiboot2 spec tells us "The order of modules is not
> > guaranteed." (Why not?) 
> 
> Of course, requiring that the order be preserved is the simplest
> solution, so unless there is a compelling reason to avoid that, I think
> we should avoid the UUID complexity.
I don't agree here.  Preserving the order is not enough.  The best example
is Xen: even if we agree that the first module is the dom0 kernel, the second
module may be either the dom0 initrd *or* the acm configuration file.  Both
are optional.

Tristan.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: identifying module types

[Tristan Gingold]

On Tue, Dec 12, 2006 at 11:54:41PM +0100, Yoshinori K. Okuji wrote:
> On Tuesday 12 December 2006 21:56, Hollis Blanchard wrote:
> > On Sat, 2006-12-09 at 06:31 +0100, Tristan Gingold wrote:
> > > On Fri, Dec 08, 2006 at 06:02:31PM -0600, Hollis Blanchard wrote:
> > > > On Fri, 2006-10-27 at 06:09 +0200, Tristan Gingold wrote:
[...]
> I am for making "type"s arbitrary. If one wants to use a "type" as an UUID, 
> she can. If one wants to use a "type" as a symbolic name, she can. I think it 
> is the most flexible and simplest way to make the interpretation of "type"s 
> up to the user.
I am not against this proposal.  I just could object we'd better to have
a mechanism to avoid collision.  If the "type" is a string collisions would
appear really soon.

Tristan.


___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel