Sendkey patch

[phcoder]

Hello. I wrote a patch to add sendkey functionality to grub2. After
loading sendkey module some new environments variables appear with which
one may control the sequence of keys that would be sent to OS or next
bootloader. This functionality is useful in different cases. One example
 is entering "safe mode" in some OS when without this feature you
desperately try many times to press "magic key" in exactly good moment.
Another usage example is chainloading another bootloader. Then you can
send someting like "down down enter" to it and avoid another delay. The
implementation as environment variables has its downside as I don't know
where to put help about it. Perhaps possibility of adding help notice to
environment variables would be a good idea. Then we could do like
>help root
root is a variable containing root device.
For implementing this functionality I needed my function to be executed
right before booting. To do it I added a simple interface for adding
"preboot" functions:
struct grub_preboot_t *grub_loader_add_preboot (grub_err_t
(*preboot_func) (int));
As parameter this function recieves a callback (integer parameter to
callback is noreturn variable). This function returns a handle with
which the preboot function may be removed using
void grub_loader_remove_preboot (struct grub_preboot_t *p);
Implementation uses linked lists and tries to implement it in as few
commands as possible since this code is a part of core image. This
interface can later be reused for adding different hooks to bios ("map",
"memdisk",...). Now the questions are:
Whether such interface is OK for grub2?
Whether we need also interface for adding "postboot" commands? (in case
boot_function returns)
Variables made available after loading sendkey module:
sendkey - a space-separated list of keys to be sent
kb_num, kb_caps, kb_scroll, kb_insert, kb_wait - [keep|on|off] - set
numlock, capslock, scrollock, insert or wait state
kb_noled - [0|1] When set to 1 the LED state is not changed to match
num-/caps-/scrolllock state
"kb_lshift", "kb_rshift", "kb_sysreq", "kb_numkey", "kb_capskey",
"kb_scrollkey", "kb_insertkey", "kb_lalt", "kb_ralt", "kb_lctrl",
"kb_rctrl" - [keep|on|off] When set to on emulate pressing and holding
of corresponding key. To undo just press the corresponding key on your
keyboard

Regards
Vladimir Serbinenko
Index: conf/i386-pc.rmk
===
--- conf/i386-pc.rmk	(revision 1845)
+++ conf/i386-pc.rmk	(working copy)
@@ -117,7 +117,7 @@
 	commands/configfile.c commands/echo.c commands/help.c		\
 	commands/terminal.c commands/ls.c commands/test.c 		\
 	commands/search.c commands/blocklist.c commands/hexdump.c	\
-	lib/hexdump.c commands/i386/pc/halt.c commands/reboot.c		\
+	lib/hexdump.c commands/i386/pc/halt.c  commands/reboot.c		\
 	commands/i386/cpuid.c		\
 	disk/host.c disk/loopback.c	\
 	fs/fshelp.c 	\
@@ -161,7 +161,7 @@
 
 # Modules.
 pkglib_MODULES = biosdisk.mod _chain.mod _linux.mod linux.mod normal.mod \
-	_multiboot.mod chain.mod multiboot.mod reboot.mod halt.mod	\
+	_multiboot.mod chain.mod multiboot.mod reboot.mod halt.mod sendkey.mod	\
 	vbe.mod vbetest.mod vbeinfo.mod video.mod gfxterm.mod \
 	videotest.mod play.mod bitmap.mod tga.mod cpuid.mod serial.mod	\
 	ata.mod vga.mod memdisk.mod jpeg.mod png.mod pci.mod lspci.mod \
@@ -214,6 +214,11 @@
 halt_mod_CFLAGS = $(COMMON_CFLAGS)
 halt_mod_LDFLAGS = $(COMMON_LDFLAGS)
 
+# For sendkey.mod.
+sendkey_mod_SOURCES = commands/i386/pc/sendkey.c
+sendkey_mod_CFLAGS = $(COMMON_CFLAGS)
+sendkey_mod_LDFLAGS = $(COMMON_LDFLAGS)
+
 # For serial.mod.
 serial_mod_SOURCES = term/i386/pc/serial.c
 serial_mod_CFLAGS = $(COMMON_CFLAGS)
Index: conf/i386-pc.mk
===
--- conf/i386-pc.mk	(revision 1845)
+++ conf/i386-pc.mk	(working copy)
@@ -520,7 +520,7 @@
 	commands/configfile.c commands/echo.c commands/help.c		\
 	commands/terminal.c commands/ls.c commands/test.c 		\
 	commands/search.c commands/blocklist.c commands/hexdump.c	\
-	lib/hexdump.c commands/i386/pc/halt.c commands/reboot.c		\
+	lib/hexdump.c commands/i386/pc/halt.c  commands/reboot.c		\
 	commands/i386/cpuid.c		\
 	disk/host.c disk/loopback.c	\
 	fs/fshelp.c 	\
@@ -926,7 +926,7 @@
 
 # Modules.
 pkglib_MODULES = biosdisk.mod _chain.mod _linux.mod linux.mod normal.mod \
-	_multiboot.mod chain.mod multiboot.mod reboot.mod halt.mod	\
+	_multiboot.mod chain.mod multiboot.mod reboot.mod halt.mod sendkey.mod	\
 	vbe.mod vbetest.mod vbeinfo.mod video.mod gfxterm.mod \
 	videotest.mod play.mod bitmap.mod tga.mod cpuid.mod serial.mod	\
 	ata.mod vga.mod memdisk.mod jpeg.mod png.mod pci.mod lspci.mod \
@@ -1661,6 +1661,63 @@
 halt_mod_CFLAGS = $(COMMON_CFLAGS)
 halt_mod_LDFLAGS = $(COMMON_LDFLAGS)
 
+# For sendkey.mod.
+sendkey_mod_SOURCES = commands/i386/pc/sendkey.c
+CLEANFILES += sendkey.mod mod-sendkey.o mod-sendkey.c pre-sendkey.o sendkey_mod-commands_i386_pc_sendkey.o und-sendkey.lst
+

Re: Sendkey patch

[phcoder]

Hello, again
I had a look at your patch. In some mail it was suggested that kernel
patch should be split from module that uses it. So I resend the kernel
part of my patch. Another question is whether we need some kind of
abortion procedure (like in your patch) if a preboot hook fails.
Javier Martín wrote:
> An interface like this is implemented in another patch in "discussion",
> my drivemap patch (see the August list archives). As yours, it is
> linked-list based and very similar in the prototypes. I haven't checked
> if your code has any kind of errors/corner cases,

I checked and found that I didn't check if grub_malloc succeeded

> but it seems terser
> than mine even though it's a bit more difficult to understand because
> you use double pointers to avoid my handling of the head case. I don't
> understand the purpose of doubly-linking the list though...
> 
The goal is to avoid walking through list when deleting an entry from it.
>> Whether we need also interface for adding "postboot" commands? (in case
>> boot_function returns)
> I don't think it would offer a lot of functionality because most loaders
> don't return on failure, they just get stuck or their payload
> triple-faults and reboots.

It's the case for i386-pc loaders but not the case of some other targets
(e.g. EFI). So the question remains.

Vladimir Serbinenko


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

Re: Sendkey patch

[phcoder]

Sorry, forgot to attach
phcoder wrote:
> Hello, again
> I had a look at your patch. In some mail it was suggested that kernel
> patch should be split from module that uses it. So I resend the kernel
> part of my patch. Another question is whether we need some kind of
> abortion procedure (like in your patch) if a preboot hook fails.
> Javier Martín wrote:
>> An interface like this is implemented in another patch in "discussion",
>> my drivemap patch (see the August list archives). As yours, it is
>> linked-list based and very similar in the prototypes. I haven't checked
>> if your code has any kind of errors/corner cases,
> 
> I checked and found that I didn't check if grub_malloc succeeded
> 
>> but it seems terser
>> than mine even though it's a bit more difficult to understand because
>> you use double pointers to avoid my handling of the head case. I don't
>> understand the purpose of doubly-linking the list though...
>>
> The goal is to avoid walking through list when deleting an entry from it.
>>> Whether we need also interface for adding "postboot" commands? (in case
>>> boot_function returns)
>> I don't think it would offer a lot of functionality because most loaders
>> don't return on failure, they just get stuck or their payload
>> triple-faults and reboots.
> 
> It's the case for i386-pc loaders but not the case of some other targets
> (e.g. EFI). So the question remains.
> 
> Vladimir Serbinenko

Index: kern/loader.c
===
--- kern/loader.c	(revision 1845)
+++ kern/loader.c	(working copy)
@@ -22,12 +22,46 @@
 #include 
 #include 
 
+
 static grub_err_t (*grub_loader_boot_func) (void);
 static grub_err_t (*grub_loader_unload_func) (void);
 static int grub_loader_noreturn;
 
 static int grub_loader_loaded;
 
+static struct grub_preboot_t *grub_loader_preboots=0;
+
+struct grub_preboot_t *
+grub_loader_add_preboot (grub_err_t (*preboot_func) (int))
+{
+  struct grub_preboot_t **cur=&grub_loader_preboots;
+  if (!preboot_func)
+return 0;
+  while (*cur)
+cur=&((*cur)->next);
+  *cur=(struct grub_preboot_t *)grub_malloc (sizeof (struct grub_preboot_t));
+  if (!*cur)
+{
+  grub_error (GRUB_ERR_OUT_OF_MEMORY, "hook not added");
+  return 0;
+}
+  (*cur)->prev_pointer=cur;
+  (*cur)->next=0;
+  (*cur)->preboot_func=preboot_func;
+  return *cur;
+}
+
+void
+grub_loader_remove_preboot (struct grub_preboot_t *p)
+{
+  if (!p)
+return;
+  *(p->prev_pointer)=p->next;
+  if (p->next)
+(p->next)->prev_pointer=p->prev_pointer;
+  grub_free (p);
+}
+
 int
 grub_loader_is_loaded (void)
 {
@@ -64,11 +98,19 @@
 grub_err_t
 grub_loader_boot (void)
 {
+  struct grub_preboot_t *iter=grub_loader_preboots;
   if (! grub_loader_loaded)
 return grub_error (GRUB_ERR_NO_KERNEL, "no loaded kernel");
 
   if (grub_loader_noreturn)
 grub_machine_fini ();
+
+  while (iter)
+{
+  if (iter->preboot_func)
+	iter->preboot_func (grub_loader_noreturn);
+  iter=iter->next;
+}
   
   return (grub_loader_boot_func) ();
 }
Index: include/grub/loader.h
===
--- include/grub/loader.h	(revision 1845)
+++ include/grub/loader.h	(working copy)
@@ -25,6 +25,14 @@
 #include 
 #include 
 
+struct grub_preboot_t
+{
+  grub_err_t (*preboot_func) (int);  
+  struct grub_preboot_t *next;
+  struct grub_preboot_t **prev_pointer;
+};
+
+
 /* Check if a loader is loaded.  */
 int EXPORT_FUNC(grub_loader_is_loaded) (void);
 
@@ -37,6 +45,12 @@
 /* Unset current loader, if any.  */
 void EXPORT_FUNC(grub_loader_unset) (void);
 
+/*Add a preboot function*/
+struct grub_preboot_t *EXPORT_FUNC(grub_loader_add_preboot) (grub_err_t (*preboot_func) (int noreturn));
+
+/*Remove given preboot function*/
+void EXPORT_FUNC(grub_loader_remove_preboot) (struct grub_preboot_t *p);
+
 /* Call the boot hook in current loader. This may or may not return,
depending on the setting by grub_loader_set.  */
 grub_err_t EXPORT_FUNC(grub_loader_boot) (void);
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Sendkey patch

[phcoder]

Javier Martín wrote:
> But you negate any performance gain when you _do_ traverse the list to
> add an entry to it instead of just make it the new head as I do.
> Besides, even for that, double indirection should be avoided in the
> structure previous pointer because it makes things oh-so-incredibly
> confusing.
I was thinking about code size then about performance or easy of
understanding. On my system this code results in 91 addition bytes in
core image (63 if I remove grub_error). Do you have any idea how it
would be possible to do an error message without description or put some
generic description?
> 
> Besides, I think the "user" (i.e. module) visible type returned by _add
> and taken by _remove should be a "blank hidden type", i.e. you don't
> need to declare "struct grub_preboot_t" in loader.h because the public
> interface only uses _pointers_ to it, whose size is known. This is all
> the C compiler requires and you avoid polluting the namespace with
> internal implementation details. I recommend the following typedefs:
> 
> typedef struct grub_preboot_t* grub_preboot_hnd;
> typedef grub_err_t *(grub_preboot_func)(int noreturn);
> 
> So that the prototypes would look
> 
> grub_preboot_hnd add(grub_preboot_func f);
> void remove(grub_preboot_hnd handle);
I noticed that actually no code needs the size of grub_preoot_hnd. So I
changed it to void *
Vladimir Serbinenko
Index: kern/loader.c
===
--- kern/loader.c	(revision 1845)
+++ kern/loader.c	(working copy)
@@ -22,12 +22,54 @@
 #include 
 #include 
 
+#define PREBOOT_HND(x) (((struct grub_preboot_t *)x))
+
+struct grub_preboot_t
+{
+  grub_err_t (*preboot_func) (int);  
+  struct grub_preboot_t *next;
+  struct grub_preboot_t **prev_pointer;
+};
+
 static grub_err_t (*grub_loader_boot_func) (void);
 static grub_err_t (*grub_loader_unload_func) (void);
 static int grub_loader_noreturn;
 
 static int grub_loader_loaded;
 
+static struct grub_preboot_t *grub_loader_preboots=0;
+
+void *
+grub_loader_add_preboot (grub_err_t (*preboot_func) (int))
+{
+  struct grub_preboot_t *cur;
+  if (!preboot_func)
+return 0;
+  cur=(struct grub_preboot_t *)grub_malloc (sizeof (struct grub_preboot_t));
+  if (!cur)
+{
+  grub_error (GRUB_ERR_OUT_OF_MEMORY, "hook not added");
+  return 0;
+}
+  cur->next=grub_loader_preboots;
+  cur->prev_pointer=0;
+  cur->next->prev_pointer=&(cur->next);
+  cur->preboot_func=preboot_func;
+  grub_loader_preboots=cur;
+  return cur;
+}
+
+void
+grub_loader_remove_preboot (void *p)
+{
+  if (!p)
+return;
+  *(PREBOOT_HND(p)->prev_pointer)=PREBOOT_HND(p)->next;
+  if (PREBOOT_HND(p)->next)
+PREBOOT_HND(p)->next->prev_pointer=PREBOOT_HND(p)->prev_pointer;
+grub_free (p);
+}
+
 int
 grub_loader_is_loaded (void)
 {
@@ -64,12 +106,18 @@
 grub_err_t
 grub_loader_boot (void)
 {
+  struct grub_preboot_t *iter=grub_loader_preboots;
   if (! grub_loader_loaded)
 return grub_error (GRUB_ERR_NO_KERNEL, "no loaded kernel");
 
   if (grub_loader_noreturn)
 grub_machine_fini ();
-  
+  while (iter)
+{
+  if (iter->preboot_func)
+	iter->preboot_func (grub_loader_noreturn);
+  iter=iter->next;
+}
   return (grub_loader_boot_func) ();
 }
 
Index: include/grub/loader.h
===
--- include/grub/loader.h	(revision 1845)
+++ include/grub/loader.h	(working copy)
@@ -25,6 +25,7 @@
 #include 
 #include 
 
+
 /* Check if a loader is loaded.  */
 int EXPORT_FUNC(grub_loader_is_loaded) (void);
 
@@ -37,6 +38,12 @@
 /* Unset current loader, if any.  */
 void EXPORT_FUNC(grub_loader_unset) (void);
 
+/*Add a preboot function*/
+void *EXPORT_FUNC(grub_loader_add_preboot) (grub_err_t (*preboot_func) (int noreturn));
+
+/*Remove given preboot function*/
+void EXPORT_FUNC(grub_loader_remove_preboot) (void *hnd);
+
 /* Call the boot hook in current loader. This may or may not return,
depending on the setting by grub_loader_set.  */
 grub_err_t EXPORT_FUNC(grub_loader_boot) (void);
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Sendkey patch

[phcoder]

Well the interface is as we described: the module gives a callback
function which will be called before launching boot function. This
interface is enough for both (and probaly many other) needs. The only
problem is that callback functions can conflict with each other and with
boot function. E.g. if callback sets an INT13h hook and then boot
function reads harddrive then it could get wrong data. In my opinion the
ese callback and boot functions shouldn't use device access at all. This
is especially true because theese functions are after grub_machine_fini.


> 
> This way it would be also easier to incorporate patches as there is
> already skeleton that can be used easily.
> 
There could several templates for using such feature because it's quite
universal


Vladimir Serbinenko


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

Re: Sendkey patch

[phcoder]

Javier Martín wrote:
> El mar, 02-09-2008 a las 20:39 +0200, phcoder escribió:
>> +void
>> +grub_loader_remove_preboot (void *p)
>> +{
>> +  if (!p)
>> +return;
>> +  *(PREBOOT_HND(p)->prev_pointer)=PREBOOT_HND(p)->next;
> This line will "crash" if p is the head of the list (with prev_pointer
> being 0). I quote crash because a crash is what happens under an OS:
> under GRUB you just overwrite address 0x0 which in i386-pc is the start
> of the real mode IVT.
Thank you for pointing at this mistake. Corrected. I should really go to
bed now.
> 
>> +  if (PREBOOT_HND(p)->next)
>> +PREBOOT_HND(p)->next->prev_pointer=PREBOOT_HND(p)->prev_pointer;
>> +grub_free (p);
>> +}
> All these macro plays are nonsense and a hindrance to readability just
> because you did not want to add a local variable and do the cast once.
> 
> Here is my "version" of your patch, without the double indirection and
> the strange plays. The overhead is 103 bytes without the error line
> against 63 of yours, but I really think that the symmetric and
> understandable handling of previous and next is worth 40 bytes.
> 
Well let's summ up what we have:
-my version in 63 bytes but difficult to read (could some comments help
with it?)
-your version much easier to read but in 103 bytes
Neither of versions is right or wrong. It's a question of priorities. I
had some experiences that past some point it's difficult to decrease
size past some point. Core image has to be embed in first cylinder.
There we have 62 sectors=31744 bytes. And now our core image (my version
with error reporting) with ata,pc  and reiserfs is 29654 bytes. This
leaves us 2090 bytes. This combination is not something completely out
of the ordinary. So I suggest to give the priority to the size of the
kernel over readability (perhaps adding some comments to my version).
> PS:
>> +void *EXPORT_FUNC(grub_loader_add_preboot) (grub_err_t ...
> I think that (only) in function declarations it's better to write "void*
> f()" than "void *f()" because otherwise the * can be easily overlooked.
> However, this is my word and does not come from the GCS.
> 
I've just made the same that I see in include/grub/mm.h . But for me it
doesn't really matter
Vladimir Serbinenko

Index: kern/loader.c
===
--- kern/loader.c	(revision 1845)
+++ kern/loader.c	(working copy)
@@ -22,12 +22,54 @@
 #include 
 #include 
 
+#define PREBOOT_HND(x) (((struct grub_preboot_t *)x))
+
+struct grub_preboot_t
+{
+  grub_err_t (*preboot_func) (int);  
+  struct grub_preboot_t *next;
+  struct grub_preboot_t **prev_pointer;
+};
+
 static grub_err_t (*grub_loader_boot_func) (void);
 static grub_err_t (*grub_loader_unload_func) (void);
 static int grub_loader_noreturn;
 
 static int grub_loader_loaded;
 
+static struct grub_preboot_t *grub_loader_preboots=0;
+
+void *
+grub_loader_add_preboot (grub_err_t (*preboot_func) (int))
+{
+  struct grub_preboot_t *cur;
+  if (!preboot_func)
+return 0;
+  cur=(struct grub_preboot_t *)grub_malloc (sizeof (struct grub_preboot_t));
+  if (!cur)
+{
+  grub_error (GRUB_ERR_OUT_OF_MEMORY, "hook not added");
+  return 0;
+}
+  cur->next=grub_loader_preboots;
+  cur->prev_pointer=&grub_loader_preboots;
+  cur->next->prev_pointer=&(cur->next);
+  cur->preboot_func=preboot_func;
+  grub_loader_preboots=cur;
+  return cur;
+}
+
+void
+grub_loader_remove_preboot (void *p)
+{
+  if (!p)
+return;
+  *(PREBOOT_HND(p)->prev_pointer)=PREBOOT_HND(p)->next;
+  if (PREBOOT_HND(p)->next)
+PREBOOT_HND(p)->next->prev_pointer=PREBOOT_HND(p)->prev_pointer;
+grub_free (p);
+}
+
 int
 grub_loader_is_loaded (void)
 {
@@ -64,12 +106,18 @@
 grub_err_t
 grub_loader_boot (void)
 {
+  struct grub_preboot_t *iter=grub_loader_preboots;
   if (! grub_loader_loaded)
 return grub_error (GRUB_ERR_NO_KERNEL, "no loaded kernel");
 
   if (grub_loader_noreturn)
 grub_machine_fini ();
-  
+  while (iter)
+{
+  if (iter->preboot_func)
+	iter->preboot_func (grub_loader_noreturn);
+  iter=iter->next;
+}
   return (grub_loader_boot_func) ();
 }
 
Index: include/grub/loader.h
===
--- include/grub/loader.h	(revision 1845)
+++ include/grub/loader.h	(working copy)
@@ -25,6 +25,7 @@
 #include 
 #include 
 
+
 /* Check if a loader is loaded.  */
 int EXPORT_FUNC(grub_loader_is_loaded) (void);
 
@@ -37,6 +38,12 @@
 /* Unset current loader, if any.  */
 void EXPORT_FUNC(grub_loader_unset) (void);
 
+/*Add a preboot function*/
+void *EXPORT_FUNC(grub_loader_add_preboot) (grub_err_t (*preboot_func) (int noreturn));
+
+/*Remove given preboot function*/
+void EX

Re: Sendkey patch

[phcoder]

Hello, again.
Javier Martín wrote:
> We have 63 sectors = 32256 bytes (sectors range from 0 to 63 and the
> first is used by the MBR).
> 
I've just rechecked on my system. My first partition begins at sector
number 63. This is the value I've seen at most systems. So last usable
sector is 62. Sector 0 is MBR. So we have 62 sectors
>> And now our core image (my version
>> with error reporting) with ata,pc  and reiserfs is 29654 bytes. This
>> leaves us 2090 bytes. This combination is not something completely out
>> of the ordinary. So I suggest to give the priority to the size of the
>> kernel over readability (perhaps adding some comments to my version).
> I was wondering why my data did not match yours, and then I realized I
> was using my usual "extreme" combination of modules: "biosdisk pc ext2
> lvm raid" yields 29298 bytes, "plenty" of space. But ata and reiserfs
> are quite the bloaters... The reiserfs case is particularly strange: in
> the linux kernel, the reiserfs module is 50% bigger than ext3.ko; while
> in GRUB, reiserfs.mod (without journaling) is twice the size of ext2.mod
> (which includes full support for ext2, partial journal support in ext3
> and extents in ext4).
> 
I'll have a look at it but not sure to find anything since I'm not
familiar with either ata or reiserfs internal structure.
> Thus, while you are right in prioritizing kernel size; why not optimize
> reiserfs a bit instead of killing our (and future maintainers') eyes and
> brains to shave less than 40 bytes from kernel? I suppose the story
> would be similar with ata, because it is a new module that is yet in
> development.
Well the point is that if we don't do it now and then one day we'll have
to squeeze the core it will be very difficult to find places like this.
> 
> -Habbit
> 
Vladimir 'phcoder' Serbinenko


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

Re: Sendkey patch

[phcoder]

Javier Martín wrote:
> El mié, 03-09-2008 a las 02:08 +0200, phcoder escribió:
>> Hello, again.
>> Javier Martín wrote:
>>> We have 63 sectors = 32256 bytes (sectors range from 0 to 63 and the
>>> first is used by the MBR).
>>>
>> I've just rechecked on my system. My first partition begins at sector
>> number 63. This is the value I've seen at most systems. So last usable
>> sector is 62. Sector 0 is MBR. So we have 62 sectors
> Oops, true! How strange. So there was no sector 63 in the CHS model and
> that is why the first sector of cyl 1 (the start of the first partition)
> is LBA 63... Does anyone know the historical reasons for this?
> 
int 0x13:0x08 can't return more than 63 sectors per track.
http://en.wikipedia.org/wiki/Int_13h#INT_13h_AH.3D08h:_Read_Drive_Parameters
>> I'll have a look at it but not sure to find anything since I'm not
>> familiar with either ata or reiserfs internal structure.
> I was not suggesting that it was you or me who did it; it was a general
> "call" for GRUB devs... (ahem xD)
> 
I understand. I was saying that I'll just have a look at least to know
what I'm talking about. But even if we manage to decrease the size of
reiserfs module there are still other FS which could result in big
modules e.g. ZFS.
>>> Thus, while you are right in prioritizing kernel size; why not optimize
>>> reiserfs a bit instead of killing our (and future maintainers') eyes and
>>> brains to shave less than 40 bytes from kernel? I suppose the story
>>> would be similar with ata, because it is a new module that is yet in
>>> development.
>> Well the point is that if we don't do it now and then one day we'll have
>> to squeeze the core it will be very difficult to find places like this.
> Yes, but my point is that 40 bytes is so small a difference

40 bytes are small but 40 bytes per small interface is a big difference

> that it can
> offset by simply rewriting error strings in kernel and other smallish
> non-intrusive changes and thus we should prioritize future
> maintainability. However, eventually this is not our decision to make:
> the Overlords here (mainly Marco, but also Robert, Vesa and Bean) are
> the ones who should, likely only once the interface is established,
> decide how to conjugate the Prime Directive of "keep kernel small" with
> code complexity in this particular case.
> 
You have the point. But if we don't discuss this matter the choice made
by maintainers can be random.
> -Habbit

Vladimir 'phcoder' Serbinenko


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

[RFC] add custom strings to the help list

[phcoder]

Hello all. In old good time of grub-legacy one could obtain the help
about "root" command with
> help root
Now "root" is a variable and so "help root " gives no information. I
suggest that it should be possible to add custom strings to help command
in normal mode. Something like
grub_register_help (title, contents);
grub_unregister_help (title);

what do you think about it?
Vladimir 'phcoder' Serbinenko

P.S. Of course I'm ready to implement it


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

[RFC]swapfso and "ioctl" function for filesystems

[phcoder]

Hello, all.
For some FS sometimes additional functions are needed. It could be some
type of control (e.g. in ZFS manage zpools) or preparation for OS
booting (e.g. in FAT put IO.SYS and MSDOS.SYS at the begining of the
root directory). While theese functions are quite specific to FS
sometimes are important to implement. So I suggest to add to grub_fs a
pointer to an array in which fs module can put custom functions.
Also in many filesystems it's quite difficult to add a new file or
remove already existing one it's often quite easy to exchange 2 files or
directories. So I intend to implement a call "swapfso" (FSO=File System
Object) at least for fat and ext2. Such a call could be useful to have
multiple OS on the same partition or to have multiple configurations of
the same OS (e.g. normal and backup). Then I think to have this function
in this extended list (even if this function can be implemented for more
FS) unless maintainers suggest that such function should be a part of
grub_fs. In this case a good idea would be to have 2 modules for
fat,ext2,...: one with swapfso and one without for core image.
Vladimir 'phcoder' Serbinenko


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

[RFC] Boot parameters and geometrical stability

[phcoder]

Hello, all.
Now when core image can be booted by multiple sources perhaps it would
be a good idea to recieve some boot arguments in case boot method (e.g.
multiboot) supports it. Probably the best way is to recieve pairs
 which can be easily imported to environment. Another
possibility of improving boot process is to detect the prefix even if
partition map changed it can be done e.g. with UUID but this comprises a
security risk in case an attacker can plug a device (cdrom, floppy,
USB-memory,..) containing a partition with the same UUID. What do you
think about it
Vladimir 'phcoder' Serbinenko


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

Re: [RFC]swapfso and "ioctl" function for filesystems

[phcoder]

Robert Millan wrote:
> On Wed, Sep 03, 2008 at 11:42:44AM +0200, phcoder wrote:
>> Hello, all.
>> For some FS sometimes additional functions are needed. It could be some
>> type of control (e.g. in ZFS manage zpools) or preparation for OS
>> booting (e.g. in FAT put IO.SYS and MSDOS.SYS at the begining of the
>> root directory). While theese functions are quite specific to FS
>> sometimes are important to implement.
> 
> What would be the purpose of that?  Please describe a use case.
> 
With ZFS or ext3cow: Suppose you made a huge mistake and installed
unbootable kernel and have no backup in another file. But ZFS/ext3cow
has its own backup. So ZFS/ext3cow driver may provide a call something like
static grub_err_t zfs_timeback (int timeref);
And anounce it like:
add_funcs={
{"timeback", zfs_timeback},
{0, 0}
};
Then a module timeback.mod can suply a command like
timeback  
which uses the function supplied by zfs and ext3cow.
With FAT: suppose you have let's say DR-DOS and windows on the same
partition. Great their boot files have different names so they shouldn't
 conflict. But in fact they do because both require their boot files
(io.sys/msdos.sys or ibmbio.com/ibmdos.com) to be first entries in root
directory. So fat module can provide a call like
fat_put_rootfile_to_slot (char *filename, int place);

Then a module "dosprep.mod" can do something like:
put_rootfile_to ("io.sys",0);
put_rootfile_to ("msdos.sys",0);

>> [...]. So I intend to implement a call "swapfso" (FSO=File System
>> Object) at least for fat and ext2.
> 
> Do you mean a filesystem write that swaps two file references?
> 
Exactly. It's easy to implement (just exchange inode numbers and
filetype fields in dirent). It's also another usage case for first part
of my email.
Vladimir 'phcoder' Serbinenko


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

Re: [RFC] Boot parameters and geometrical stability

[phcoder]

Robert Millan wrote:
> On Wed, Sep 03, 2008 at 11:50:33AM +0200, phcoder wrote:
>> Hello, all.
>> Now when core image can be booted by multiple sources perhaps it would
>> be a good idea to recieve some boot arguments in case boot method (e.g.
>> multiboot) supports it. Probably the best way is to recieve pairs
>>  which can be easily imported to environment.
> 
> I assume you talk about GRUB loading itself;  what kind of information would
> you pass from one GRUB to the other?
Boot device, configuration file, parameters for scripts. But much more
useful this is for network boot. In this case GRUB can recieve server
info in boot parameters so when this info changes there is no need to
regenerate grub images.
> 
>> but this comprises a
>> security risk in case an attacker can plug a device (cdrom, floppy,
>> USB-memory,..) containing a partition with the same UUID. What do you
>> think about it
> 
> I think people who want this level of security (i.e. local media is not
> trusted) should use crypto checksums to verify they're loading what they
> expected, with or without UUIDs.
> 
I was thinking about the scenario when ide drives are trusted but not
USB or removable devices. Cryptographic checksums wouldn't bring much
because if attacker can modify harddrive he can also modify GRUB to skip
 checksum check.
Vladimir 'phcoder' Serbinenko


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

Re: [RFC] Boot parameters and geometrical stability

[phcoder]

Vesa Jääskeläinen wrote:
> phcoder wrote:
>> I was thinking about the scenario when ide drives are trusted but not
>> USB or removable devices. Cryptographic checksums wouldn't bring much
>> because if attacker can modify harddrive he can also modify GRUB to skip
>>  checksum check.
> 
> Then you password protect it :) Once that is supported.
> 
> But really, if attacker has access to your HDD then there is not a
> really reason why we should do defense against that one as they can
> overwrite us at will.
But consider a scenario when attacker can't overwrite the existing
harddrive but can plug new one. Then the attacker can prepare a
harddrive having a partition with the same UUID as our boot partition.
Then he plugs it and depnding on factors like order of interfaces,
devices, phase of the moon, ... GRUB can load attacker's modules. While
it's ok to use UUID on personal desktop system when attacker can't plug
his devices it shouldn't be the default.
Vladimir 'phcoder' Serbinenko


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

Re: Sendkey patch

[phcoder]

Hello. In this case we can transfer the whole functionality located in
kern/loader.c to a dedicated module boot.mod. This module will also
register "boot" command. In this way the encapsulation won't be broken
and kernel will become even smaller.
Vladimir 'phcoder' Serbinenko
Vesa Jääskeläinen wrote:
> Hi,
> 
> How about following (may not be syntaxically correct):
> 
> In kernel:
> 
> /* Variable holding pointer to preboot hook function.  */
> preboot_hook:
>   .long   0
> 
> ...
>   /* Check if there is preboot hook installed.  */
>   movlpreboot_hook, %eax
>   testl   %eax, %eax
>   jne 1f
>   call%eax
> 1:
>   /* Continue boot.  */
> 
> 
> Then in module code:
> 
> void grub_preboot_hook_handler(void)
> {
>   /* Process list of registered preboot hooks.  */
> }
> 
> void grub_preboot_register_hook(...);
> void grub_preboot_unregister_hook(...);
> 
> GRUB_MOD_INIT(preboot)
> {
>   preboot_hook = grub_preboot_hook_handler;
> }
> 
> GRUB_MOD_FINI(preboot)
> {
>   preboot_hook = 0;
> }
> 
> If preboot.mod gets loaded then it goes and registers preboot handler to
> kernel to do its tricks. Other modules then would use preboot.mod to
> register their own handlers.
> 
> This would have minimal impact for kernel.
> 
> Thanks,
> Vesa Jääskeläinen
> 
> 
> ___
> 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

Multiple partition maps

[phcoder]

Hello. I was looking at the grub code and seen that if a disk has
multiple partition tables (e.g. macintel with bootcamp) then only first
one will be detected. In some cases it can lead to unreachable
partitions if for some reason partition is present only in one table.
Does anyone has an idea how theese cases may be treated compactly and
efficiently?
Vladimir 'phcoder' Serbinenko


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

Re: Sendkey patch

[phcoder]

Vesa Jääskeläinen wrote:
> phcoder wrote:
>> Hello. In this case we can transfer the whole functionality located in
>> kern/loader.c to a dedicated module boot.mod. This module will also
>> register "boot" command. In this way the encapsulation won't be broken
>> and kernel will become even smaller.
> 
> Remember that realmode code needs to reside below < 1 MiB. That is the
> reason realmode code is embedded in kernel. In there you only see jumps
> to RM and back to PM.
> 
kern/loader.c is always executed in PM. It just chooses which
kernel-specific function to call next. RM helpers are found in
kern/i386/loader.S and kern/i386/pc/startup.S (for chainloader).

Vladimir 'phcoder' Serbinenko


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

Re: [RFC] Boot parameters and geometrical stability

[phcoder]

Vesa Jääskeläinen wrote:
> That is a valid point.
> 
> Would you prefer to use hardware path to device or what you had in mind
> then? Because this is something that we can left for expert people. Most
> common problem is that user plugs in new drive to system and
> bios/hardware order gets changed or something like that, and that
> renders system unbootable. UUID is perfect solution for that case.
> 
Yes it is, but in my opinion price is too high (shame ubuntu uses this
solution). It's somewhat similar to some solutions found in windows when
  for user convenience they open a big gate for the hackers (e.g. all
users by default are administrators in winxp)
> Possibilites are there, but basically they are limited to something like:
> 
> (ata0) (pci-X-Y-Z:ata0) (usb-X-Y:scsi0) (pci-X-Y-Z:scsi0)
> 
> I do not know if those all would be valid, but I hope you get the idea.

Yes. This is a solution found in grub legacy and I think it's a good one.
> 
> Alternative would be that you integrate some module to core that
> validates your system that there is no extra devices or such.

It's bigger since you require module and has no advantages over using
hardware names. But what we can do is to check if 2 partitions share the
same UUID and if it's the case prompt for password. The problem is that
if the same device is visible twice then it will result in a false
positive. Another solution would be to checksum modules we load. But in
this case after partial update or configuration modification a run
checksum-updater is necessary or at least user will have to enter his
password on the next boot.
> 
> Thanks,
> Vesa Jääskeläinen

Vladimir 'phcoder' Serbinenko


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

Re: [RFC] Boot parameters and geometrical stability

[phcoder]

Vesa Jääskeläinen wrote:
> phcoder wrote:
>> Yes it is, but in my opinion price is too high (shame ubuntu uses this
>> solution). It's somewhat similar to some solutions found in windows when
>>   for user convenience they open a big gate for the hackers (e.g. all
>> users by default are administrators in winxp)
> 
> Well... That is your opinion. I acknowledge that it opens another door
> for local hacker. But if you are able to do that, then you can do some
> other actions that are much more fatal...
If attacker is unable to open computer, bios is under password, boots
only from HD and grub is password-protected than I don't see which other
action can lead to the same result (complete control of computer).
> 
> But the gain can still supersede the security need. Its kinda same thing
> that you are required to change your password monthly. People start
> putting those on stickers and then the game is lost anyway.
> 
This is eternal problem of security and its cost (see B.Schneier Beyond
Fear). If someone find this compromise of security OK on his computer
then fine. Just the user has at least to be warned about security risks
it represents and have an alternative. I think a WARNING with
description of the problem with a promt after it and possibility to do
it otherwise (with hardware path or entering the disk manually) should
be enough.

Vladimir 'phcoder' Serbinenko


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

Re: [RFC]swapfso and "ioctl" function for filesystems

[phcoder]

Robert Millan wrote:
> On Wed, Sep 03, 2008 at 02:25:51PM +0200, phcoder wrote:
>> Robert Millan wrote:
>>> On Wed, Sep 03, 2008 at 11:42:44AM +0200, phcoder wrote:
>>>> Hello, all.
>>>> For some FS sometimes additional functions are needed. It could be some
>>>> type of control (e.g. in ZFS manage zpools) or preparation for OS
>>>> booting (e.g. in FAT put IO.SYS and MSDOS.SYS at the begining of the
>>>> root directory). While theese functions are quite specific to FS
>>>> sometimes are important to implement.
>>> What would be the purpose of that?  Please describe a use case.
>>>
>> With ZFS or ext3cow: Suppose you made a huge mistake and installed
>> unbootable kernel and have no backup in another file. But ZFS/ext3cow
>> has its own backup. So ZFS/ext3cow driver may provide a call something like
>> static grub_err_t zfs_timeback (int timeref);
>> And anounce it like:
>> add_funcs={
>> {"timeback", zfs_timeback},
>> {0, 0}
>> };
>> Then a module timeback.mod can suply a command like
>> timeback  
>> which uses the function supplied by zfs and ext3cow.
> 
> Could this be made more transparent?  For example, with a variable.
> 
Here perhaps it could be. But in other usage cases like putting the dos
boot files into the right place or doing swapfso it couldn't.
> Also, I'm worried that this occupies core image size for non-critical
> functionality.
> 
If filesystem module doesn't use this feature it just adds a zero
pointer to grub_fs structure. It means 4 bytes (due to alignment often
it probably be 0 bytes increase). And it would answer to all
filesystem-specific needs. And non-essential parts of the FS module
(like swapfso, dos boot files,...) may be implemented in an extra module
(like ntfscomp) or there could be 2 modules for the same filesystem:
basic and advanced one.

Vladimir 'phcoder' Serbinenko


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

Re: [RFC] Boot parameters and geometrical stability

[phcoder]

Robert Millan wrote:
> On Wed, Sep 03, 2008 at 02:31:10PM +0200, phcoder wrote:
>>> I assume you talk about GRUB loading itself;  what kind of information would
>>> you pass from one GRUB to the other?
>> Boot device,
> 
> Multiboot already handles that (although it's not reliable; I don't
> think this feature should be used anyway).
> 
Feature in multiboot is hmm..: it gives bios device and grub supports
also other devices.
>> configuration file, parameters for scripts.
> 
> This assumes the loader knows more than the loadee about this information.
> In which situation would this happen?  Note that both loader and loadee can
> obtain user input.
> 
> Which parameters do you have in mind?
> 
I thought of it more like about instruction like: boot from strange
place or enter debug mode in early stage.
>> But much more
>> useful this is for network boot. In this case GRUB can recieve server
>> info in boot parameters so when this info changes there is no need to
>> regenerate grub images.
> 
> Doesn't PXE already handle this?
> 
I'm not really familiar with it. Does it support multiple servers. If
let's say we have multiple menus like:



Then having recieved names of servers as parameters could sometimes be a
good thing. But still for me this feature is just an idea. I'm still not
persuaded myself whether it's needed.
Vladimir 'phcoder' Serbinenko


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

Re: [RFC] Boot parameters and geometrical stability

[phcoder]

Robert Millan wrote:
> On Wed, Sep 03, 2008 at 08:49:14PM +0300, Vesa Jääskeläinen wrote:
>> Possibilites are there, but basically they are limited to something like:
>>
>> (ata0) (pci-X-Y-Z:ata0) (usb-X-Y:scsi0) (pci-X-Y-Z:scsi0)
> 
> I think this is overkill, and doesn't really address the root of the problem.
> 
> The real security problem here is whether the executable code you're loading 
> is
> trusted, NOT where you load the code from.
If the code is loaded from the same place as we do then we can trust it
(if attacker could modify the code, he could also modify us)
> 
> When you use crypto checksums, if you get a match why would you care if you're
> loading from (some-safe-disk) or from (evil-place)?  It's the same data!
> 
Yes it is. But I don't know how big the crypto-checksum-check module
would be.
Vladimir 'phcoder' Serbineko


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

Re: Multiple partition maps

[phcoder]

Robert Millan wrote:
> On Wed, Sep 03, 2008 at 08:08:50PM +0200, phcoder wrote:
>> Hello. I was looking at the grub code and seen that if a disk has
>> multiple partition tables (e.g. macintel with bootcamp) then only first
>> one will be detected. In some cases it can lead to unreachable
>> partitions if for some reason partition is present only in one table.
>> Does anyone has an idea how theese cases may be treated compactly and
>> efficiently?
> 
> Strictly speaking, GPT+MSDOS hybrid tables are a violation of the GPT
> specification.  It's not clear what would be the "correct" way of handling
> them.
> 
> Since we're not a legacy program, I suppose the sane thing to do would be
> to abort MSDOS probing if a protective DOS partition (0xee) is found, and
> then only GPT will be used.

We're not a legacy application but some OS and partition tools are and
we have to work with them. I think just some maintenance tools included
in GRUB should be enough. I'll write them soon. (perhaps even tomorrow)
> 
> Isn't this what GRUB does already?  I thought it would be...
> 
It does. But I don't know if there are other cases similar to this one.

Vladimir 'phcoder' Serbinnenko



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

Re: Multiple partition maps

[phcoder]

BTW GPT module checks the protective MBR. In some cases when legay OS
modified the MBR it's no longer "protective MBR". And in theese cases
GRUB will refuse to boot. Isn't the magic number check enough?
Vladimir 'phcoder' Serbinenko
Robert Millan wrote:
> On Wed, Sep 03, 2008 at 08:08:50PM +0200, phcoder wrote:
>> Hello. I was looking at the grub code and seen that if a disk has
>> multiple partition tables (e.g. macintel with bootcamp) then only first
>> one will be detected. In some cases it can lead to unreachable
>> partitions if for some reason partition is present only in one table.
>> Does anyone has an idea how theese cases may be treated compactly and
>> efficiently?
> 
> Strictly speaking, GPT+MSDOS hybrid tables are a violation of the GPT
> specification.  It's not clear what would be the "correct" way of handling
> them.
> 
> Since we're not a legacy program, I suppose the sane thing to do would be
> to abort MSDOS probing if a protective DOS partition (0xee) is found, and
> then only GPT will be used.
> 
> Isn't this what GRUB does already?  I thought it would be...
> 



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

[PATCH] Move kern/loader.c to boot.mod and add preboot_support (was Re: Sendkey patch)

[phcoder]

Hello. As I said in another email there is no need for it. I send a
patch for it.
Vladimir 'phcoder' Serbinenko
Javier Martín wrote:
> El mié, 03-09-2008 a las 20:53 +0300, Vesa Jääskeläinen escribió:
>> phcoder wrote:
>>> Hello. In this case we can transfer the whole functionality located in
>>> kern/loader.c to a dedicated module boot.mod. This module will also
>>> register "boot" command. In this way the encapsulation won't be broken
>>> and kernel will become even smaller.
>> Remember that realmode code needs to reside below < 1 MiB. That is the
>> reason realmode code is embedded in kernel. In there you only see jumps
>> to RM and back to PM.
> We could use the relocator functionality that was once discussed here (I
> don't know if it was finally committed) so that modules could declare
> "bundles" of code+data to be deployed to RM area. Or make sure every
> single instruction in there uses 32-bit addressing, together with
> artificial EIP-relativization of addresses like in drivemap_int13.S
> 
> -Habbit
> 
> 
> 
> 
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel

Index: conf/common.rmk
===
--- conf/common.rmk	(revision 1845)
+++ conf/common.rmk	(working copy)
@@ -311,7 +311,7 @@
 scsi_mod_LDFLAGS = $(COMMON_LDFLAGS)
 
 # Commands.
-pkglib_MODULES += hello.mod boot.mod terminal.mod ls.mod	\
+pkglib_MODULES += hello.mod _boot.mod boot.mod terminal.mod ls.mod	\
 	cmp.mod cat.mod help.mod font.mod search.mod		\
 	loopback.mod fs_uuid.mod configfile.mod echo.mod	\
 	terminfo.mod test.mod blocklist.mod hexdump.mod		\
@@ -322,8 +322,13 @@
 hello_mod_CFLAGS = $(COMMON_CFLAGS)
 hello_mod_LDFLAGS = $(COMMON_LDFLAGS)
 
+# For _boot.mod.
+_boot_mod_SOURCES = commands/boot.c
+_boot_mod_CFLAGS = $(COMMON_CFLAGS)
+_boot_mod_LDFLAGS = $(COMMON_LDFLAGS)
+
 # For boot.mod.
-boot_mod_SOURCES = commands/boot.c
+boot_mod_SOURCES = commands/boot_normal.c
 boot_mod_CFLAGS = $(COMMON_CFLAGS)
 boot_mod_LDFLAGS = $(COMMON_LDFLAGS)
 
Index: conf/i386-pc.rmk
===
--- conf/i386-pc.rmk	(revision 1845)
+++ conf/i386-pc.rmk	(working copy)
@@ -41,7 +41,7 @@
 # For kernel.img.
 kernel_img_SOURCES = kern/i386/pc/startup.S kern/main.c kern/device.c \
 	kern/disk.c kern/dl.c kern/file.c kern/fs.c kern/err.c \
-	kern/misc.c kern/mm.c kern/loader.c kern/rescue.c kern/term.c \
+	kern/misc.c kern/mm.c kern/rescue.c kern/term.c \
 	kern/time.c \
 	kern/i386/dl.c kern/i386/pc/init.c kern/i386/pc/mmap.c \
 	kern/parser.c kern/partition.c \
@@ -113,11 +113,11 @@
 
 # For grub-emu.
 util/grub-emu.c_DEPENDENCIES = grub_emu_init.h
-grub_emu_SOURCES = commands/boot.c commands/cat.c commands/cmp.c	\
+grub_emu_SOURCES = commands/boot.c commands/boot_normal.c commands/cat.c commands/cmp.c	\
 	commands/configfile.c commands/echo.c commands/help.c		\
 	commands/terminal.c commands/ls.c commands/test.c 		\
 	commands/search.c commands/blocklist.c commands/hexdump.c	\
-	lib/hexdump.c commands/i386/pc/halt.c commands/reboot.c		\
+	lib/hexdump.c commands/i386/pc/halt.c  commands/reboot.c		\
 	commands/i386/cpuid.c		\
 	disk/host.c disk/loopback.c	\
 	fs/fshelp.c 	\
@@ -126,7 +126,7 @@
 	kern/device.c kern/disk.c kern/dl.c kern/elf.c kern/env.c	\
 	kern/err.c			\
 	normal/execute.c kern/file.c kern/fs.c normal/lexer.c 		\
-	kern/loader.c kern/main.c kern/misc.c kern/parser.c		\
+	kern/main.c kern/misc.c kern/parser.c		\
 	grub_script.tab.c kern/partition.c kern/rescue.c kern/term.c	\
 	normal/arg.c normal/cmdline.c normal/command.c normal/function.c\
 	normal/completion.c normal/main.c normal/color.c		\
Index: kern/loader.c
===
--- kern/loader.c	(revision 1845)
+++ kern/loader.c	(working copy)
@@ -1,75 +0,0 @@
-/*
- *  GRUB  --  GRand Unified Bootloader
- *  Copyright (C) 2002,2003,2004,2006,2007  Free Software Foundation, Inc.
- *
- *  GRUB is free software: you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation, either version 3 of the License, or
- *  (at your option) any later version.
- *
- *  GRUB is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
- *
- *  You should have received a copy of the GNU General Public License
- *  along with GRUB.  If not, see <http://www.gnu.org/licenses/>.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include

[RFC] general-usage real-mode loader

[phcoder]

Hello. A long time ago I written a C+asm code which loads any given code
at any real-mode location, then puts machine in correct state and then
launches the kernel. I can modify this code to suit GRUB2. Then loading
realmode kernel would work like this:
1) copy helper asm to last kb of lower memory
2) jump to the helper
3) helper copies from upper memory the kernel
4) turn A10 bug back on if necessary
5) go to RM
6) prepare registers
7) jump to the kernel

This protocol is very flexible and as such could be used by all loaders
which load kernel in realmode or even in PM (skip step 5, do steps 6-7
in 32-bit mode) except for changing page tables. Such a helper can be
easily implemented as module and so help us removing asm-parts of
loaders from the kernel. If I recieve greenlight for it, I implement it.
Vladimir 'phcoder' Serbinenko


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

Re: [RFC] general-usage real-mode loader

[phcoder]

BTW. This helper would allow easy addition of many different kernels
(freedos, haiku, ntldr, ...)
Vladimir 'phcoder' Serbinenko
phcoder wrote:
> Hello. A long time ago I written a C+asm code which loads any given code
> at any real-mode location, then puts machine in correct state and then
> launches the kernel. I can modify this code to suit GRUB2. Then loading
> realmode kernel would work like this:
> 1) copy helper asm to last kb of lower memory
> 2) jump to the helper
> 3) helper copies from upper memory the kernel
> 4) turn A10 bug back on if necessary
> 5) go to RM
> 6) prepare registers
> 7) jump to the kernel
> 
> This protocol is very flexible and as such could be used by all loaders
> which load kernel in realmode or even in PM (skip step 5, do steps 6-7
> in 32-bit mode) except for changing page tables. Such a helper can be
> easily implemented as module and so help us removing asm-parts of
> loaders from the kernel. If I recieve greenlight for it, I implement it.
> Vladimir 'phcoder' Serbinenko



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

Re: [RFC]swapfso and "ioctl" function for filesystems

[phcoder]

Robert Millan wrote:
> On Thu, Sep 04, 2008 at 11:27:20PM +0200, phcoder wrote:
>>> Could this be made more transparent?  For example, with a variable.
>>>
>> Here perhaps it could be. But in other usage cases like putting the dos
>> boot files into the right place or doing swapfso it couldn't.
> 
> We intentionally don't support filesystem writing.  This was discussed before,
> I think.
> 
Well I see no reason why not to allow such feature to be made by
external modules. Another usage case is ext3cow snapshots. Even if the
snapshot can be chosen by a variable to list the snapshots you need a
function.
>>> Also, I'm worried that this occupies core image size for non-critical
>>> functionality.
>>>
>> If filesystem module doesn't use this feature it just adds a zero
>> pointer to grub_fs structure.
> 
> Yes, but what if it does?
> 
then for registering the functions it needs 4+(4+d)*n bytes. Where n is
the number of functions and d the size of identifier. As such we can
choose: a 4-byte enum, a string or a GUID-like system with 8,12 (my
preferance) or 16-byte long identifier. Also if module is split into 2
(essential and not-essential) then the registering of functions can be
handled by not-essential module
>> may be implemented in an extra module
>> (like ntfscomp) or there could be 2 modules for the same filesystem:
>> basic and advanced one.
> 
> 2 modules for the same filesystem can lead to trouble;  I don't think GRUB
> can handle this situation properly (for example, if you need ext2.mod to
> access $prefix, how to you replace it with the new module, which needs to be
> loaded precisely from $prefix?).
I checked module loading code: it loads the module completely to the
memory and only then launches it. So basically it's not a problem
> 
> An extra module would be saner, IMO.
> 

I also think so

Vladimir 'phcoder' Serbinenko


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

Re: [RFC] general-usage real-mode loader

[phcoder]

I checked the archive found the thread "Idea: Move kernel to upper
memory". But what is discussed there is much more general about general
memory layout. Here I wanted to speak about just one function.
Vladimir 'phcoder' Serbinenko
Robert Millan wrote:
> On Fri, Sep 05, 2008 at 07:27:51PM +0200, phcoder wrote:
>> Hello. A long time ago I written a C+asm code which loads any given code
>> at any real-mode location, then puts machine in correct state and then
>> launches the kernel. I can modify this code to suit GRUB2. Then loading
>> realmode kernel would work like this:
>> 1) copy helper asm to last kb of lower memory
>> 2) jump to the helper
>> 3) helper copies from upper memory the kernel
>> 4) turn A10 bug back on if necessary
>> 5) go to RM
>> 6) prepare registers
>> 7) jump to the kernel
>>
>> This protocol is very flexible and as such could be used by all loaders
>> which load kernel in realmode or even in PM (skip step 5, do steps 6-7
>> in 32-bit mode) except for changing page tables. Such a helper can be
>> easily implemented as module and so help us removing asm-parts of
>> loaders from the kernel. If I recieve greenlight for it, I implement it.
> 
> Maybe I'm confusing this with something else, but isn't this what both Bean
> and Vesa implemented separately, and are currently discussing in another
> thread?
> 
> (the goal there was to move BIOS wrappers out of kern/i386/pc/startup.S)
> 



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

Re: [RFC] general-usage real-mode loader

[phcoder]

Well sometimes it's similar but most of the time isn't because your code
runs a code in RM but with hope returning back to PM and normal grub
operation. And it also loads to quite fixed place. My code would load a
kernel, that means that it will not return and so code can be loaded to
any place not needed by kernel.
Vladimir 'phcoder' Serbinenko
Vesa Jääskeläinen wrote:
> phcoder wrote:
>> I checked the archive found the thread "Idea: Move kernel to upper
>> memory". But what is discussed there is much more general about general
>> memory layout. Here I wanted to speak about just one function.
>> Vladimir 'phcoder' Serbinenko
> 
> Try: [PATCH] Move assembly code out of the kernel
> 
> 
> ___
> 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: [RFC] general-usage real-mode loader

[phcoder]

Vesa Jääskeläinen wrote:
 > It is true that code is withing grub's i386 kernel. But other than that
> same mechanism can be used to load kernel. After all kernel will take
> over the computer after it has started and it is not returning back
> anymore (eg. stack is not anymore there to be restored).
> 
In this case my rmkern helper can use this mechanism but the problem is
then that the rmkern should be able to choose where to put RM helper
since some OS need specific places in memory to be filled with specific
values
> I would prefer that if we are going to give custom register
> configurations for kernel then they all should use same structures for
> storing registers.
> 
> But anyway... Did you have some good examples where this functionaly
> would be needed :) ? For now we have specialized loaders that prepare
> system for any special OSes that needs to be supported. Especially how
> do you know what registers to fill or better yet, how user will provide
> this information so OS can be loaded.
I thought that this function can be used as general helper for any
kernel that needs to be launched in RM. In that cases RMkern
functionality is used by OS-specific wrapper which knows what to put in
the registers
Usage cases:
1) chainloader
2) zbeos: BeOS and haiku. BeOS has a good functionality for booting from
loopback but for this you need floppy, windows 9x/me or dos. On my
laptop I have neither. But zbeos (BeOS and Haiku middle-loader) is
really easy to load.
3) ecomstation: eCS is able to load from JFS but needs a specialized
loader to be installed on its own primary active partition. I think GRUB
should be able to load it directly. But perhaps also exporting of GRUB
functions to ecomstation is needed (this is discussed in another thread,
I'll write there later)
4) DOS/Win9x and freedos. Especially the second one. They use extended
chainloader functionality found in grub4dos. With rmkern loading freedos
kernel should be really easy.
5) Loading winnt (ntldr) and winvista (bootmgr)
6) Many other different proprietary and free OS. I don't know enough
about them to say that this or that one can benefit from it but suppose
many OS can be booted easier and more reliable with this functionality.
7) rmkern command. Experienced users, hobbysts and OS-developpers can
enter manually the state in which they want their kernel to be loaded.
May be handy also for reverse engineering
> 
> If there is a need for specialized loader please provide some details
> where those are needed and what is required from GRUB in order to
> support that. If there is possibility to use multiboot then that would
> supersede need for specialized loader.
Some OS have their reasons not to support multiboot. E.g. haiku and
freedos stick very near to their goal of reimplementation beos/dos and
as such they don't want anything that would be better

Vladimir 'phcoder' Serbinenko


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

Re: Multiple partition maps

[phcoder]

Robert Millan wrote:
> On Thu, Sep 04, 2008 at 11:54:43PM +0200, phcoder wrote:
>> BTW GPT module checks the protective MBR. In some cases when legay OS
>> modified the MBR it's no longer "protective MBR". And in theese cases
>> GRUB will refuse to boot. Isn't the magic number check enough?
> 
> If there's at least one protective GPT partition (0xee), I think this should
> be considered enough to accept the partmap as GPT.
> 
In GPT module if first partition is not of type 0xee then it's
considered that no GPT is present. Is think that this check is
error-prone (with e.g. bootcamp) and unnecessary
Vladimir 'phcoder' Serbinenko


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

Re: Multiple partition maps

[phcoder]

Robert Millan wrote:
> On Mon, Sep 08, 2008 at 08:27:05PM +0200, phcoder wrote:
>> Robert Millan wrote:
>>> On Thu, Sep 04, 2008 at 11:54:43PM +0200, phcoder wrote:
>>>> BTW GPT module checks the protective MBR. In some cases when legay OS
>>>> modified the MBR it's no longer "protective MBR". And in theese cases
>>>> GRUB will refuse to boot. Isn't the magic number check enough?
>>> If there's at least one protective GPT partition (0xee), I think this should
>>> be considered enough to accept the partmap as GPT.
>>>
>> In GPT module if first partition is not of type 0xee then it's
>> considered that no GPT is present. Is think that this check is
>> error-prone (with e.g. bootcamp) and unnecessary
> 
> Agreed.  Can you fix this?
> 
OK.


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

[PATCH] Re: Multiple partition maps

[phcoder]

Robert Millan wrote:
> On Mon, Sep 08, 2008 at 08:27:05PM +0200, phcoder wrote:
>> Robert Millan wrote:
>>> On Thu, Sep 04, 2008 at 11:54:43PM +0200, phcoder wrote:
>>>> BTW GPT module checks the protective MBR. In some cases when legay OS
>>>> modified the MBR it's no longer "protective MBR". And in theese cases
>>>> GRUB will refuse to boot. Isn't the magic number check enough?
>>> If there's at least one protective GPT partition (0xee), I think this should
>>> be considered enough to accept the partmap as GPT.
>>>
>> In GPT module if first partition is not of type 0xee then it's
>> considered that no GPT is present. Is think that this check is
>> error-prone (with e.g. bootcamp) and unnecessary
> 
> Agreed.  Can you fix this?
> 

I send a patch for it. However I couldn't test it because of the bug in
the make system. About the bug I'll post in appropriate thread. In that
patch the pc module explicitely checks for the absence of GPT table. IMO
it's ugly. Another alternative would be to assign priorities to the
partition tables. I also tried this way and send patch for it. Again I
couldn't test it.

Vladimir 'phcoder' Serbinenko

Index: kern/partition.c
===
--- kern/partition.c	(revision 1861)
+++ kern/partition.c	(working copy)
@@ -25,8 +25,20 @@
 void
 grub_partition_map_register (grub_partition_map_t partmap)
 {
-  partmap->next = grub_partition_map_list;
-  grub_partition_map_list = partmap;
+  grub_partition_map_t cur, prev=0;
+  for (cur=grub_partition_map_list;cur && cur->priority>partmap->priority; 
+   cur=cur->next)
+prev=cur;
+  if (!prev)
+{
+  partmap->next = grub_partition_map_list;
+  grub_partition_map_list = partmap;
+}
+  else
+{
+  partmap->next=prev->next;
+  prev->next=partmap;
+}
 }
 
 void
Index: include/grub/partition.h
===
--- include/grub/partition.h	(revision 1861)
+++ include/grub/partition.h	(working copy)
@@ -42,6 +42,9 @@
   
   /* Return the name of the partition PARTITION.  */
   char *(*get_name) (const grub_partition_t partition);
+
+  /* Partmaps with higher priorities are checked first */
+  int priority;
   
   /* The next partition map type.  */
   struct grub_partition_map *next;
Index: partmap/amiga.c
===
--- partmap/amiga.c	(revision 1861)
+++ partmap/amiga.c	(working copy)
@@ -205,7 +205,8 @@
 .name = "amiga_partition_map",
 .iterate = amiga_partition_map_iterate,
 .probe = amiga_partition_map_probe,
-.get_name = amiga_partition_map_get_name
+.get_name = amiga_partition_map_get_name,
+.priority = 0
   };
 
 GRUB_MOD_INIT(amiga_partition_map)
Index: partmap/apple.c
===
--- partmap/apple.c	(revision 1861)
+++ partmap/apple.c	(working copy)
@@ -241,7 +241,8 @@
 .name = "apple_partition_map",
 .iterate = apple_partition_map_iterate,
 .probe = apple_partition_map_probe,
-.get_name = apple_partition_map_get_name
+.get_name = apple_partition_map_get_name,
+.priority = 0
   };
 
 GRUB_MOD_INIT(apple_partition_map)
Index: partmap/acorn.c
===
--- partmap/acorn.c	(revision 1861)
+++ partmap/acorn.c	(working copy)
@@ -192,7 +192,8 @@
   .name = "Linux/ADFS partition map",
   .iterate = acorn_partition_map_iterate,
   .probe = acorn_partition_map_probe,
-  .get_name = acorn_partition_map_get_name
+  .get_name = acorn_partition_map_get_name,
+  .priority = 0
 };
 
 GRUB_MOD_INIT(acorn_partition_map)
Index: partmap/pc.c
===
--- partmap/pc.c	(revision 1861)
+++ partmap/pc.c	(working copy)
@@ -111,7 +111,7 @@
   pcdata.dos_part = -1;
   p.data = &pcdata;
   p.partmap = &grub_pc_partition_map;
-  
+
   while (1)
 {
   int i;
@@ -303,7 +303,8 @@
 .name = "pc_partition_map",
 .iterate = pc_partition_map_iterate,
 .probe = pc_partition_map_probe,
-.get_name = pc_partition_map_get_name
+.get_name = pc_partition_map_get_name,
+.priority = -10
   };
 
 GRUB_MOD_INIT(pc_partition_map)
Index: partmap/sun.c
===
--- partmap/sun.c	(revision 1861)
+++ partmap/sun.c	(working copy)
@@ -205,7 +205,8 @@
 .name = "sun_partition_map",
 .iterate = sun_partition_map_iterate,
 .probe = sun_partition_map_probe,
-.get_name = sun_partition_map_get_name
+.get_name = sun_partition_map_get_name,
+.priority = 0
   };
 
 GRUB_MOD_INIT(sun_partition_map)
Index: partmap/g

[BUG] Build system broken with i386.rmk

[phcoder]

Hello. I had conflicts in .mk files after "svn up" so I removed all the
.mk. common.mk and i386-pc.mk were regenerated correctly but not i386.mk
$ make
conf/i386-pc.mk:3394: conf/i386.mk: No such file or directory
make: *** No rule to make target `conf/i386.mk'.  Stop.
Can someone familiar with build system fix this?

Vladimir 'phcoder' Serbinenko


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

Re: [BUG] Build system broken with i386.rmk

[phcoder]

Robert Millan wrote:
> On Tue, Sep 09, 2008 at 02:50:56AM +0200, phcoder wrote:
>> Hello. I had conflicts in .mk files after "svn up" so I removed all the
>> .mk. common.mk and i386-pc.mk were regenerated correctly but not i386.mk
>> $ make
>> conf/i386-pc.mk:3394: conf/i386.mk: No such file or directory
>> make: *** No rule to make target `conf/i386.mk'.  Stop.
>> Can someone familiar with build system fix this?
> 
> Can you be more specific about what's wrong in svn?  I believe ./autogen.sh
> should fix your local tree.
> 
i386-pc.mk and common.mk are regenerated if necessary by make command
but i386.mk isn't.
Vladimir 'phcoder' Serbinenko


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

Re: [PATCH] Re: Multiple partition maps

[phcoder]

Robert Millan wrote:
> On Tue, Sep 09, 2008 at 02:47:11AM +0200, phcoder wrote:
>> Robert Millan wrote:
>>> On Mon, Sep 08, 2008 at 08:27:05PM +0200, phcoder wrote:
>>>> Robert Millan wrote:
>>>>> On Thu, Sep 04, 2008 at 11:54:43PM +0200, phcoder wrote:
>>>>>> BTW GPT module checks the protective MBR. In some cases when legay OS
>>>>>> modified the MBR it's no longer "protective MBR". And in theese cases
>>>>>> GRUB will refuse to boot. Isn't the magic number check enough?
>>>>> If there's at least one protective GPT partition (0xee), I think this 
>>>>> should
>>>>> be considered enough to accept the partmap as GPT.
>>>>>
>>>> In GPT module if first partition is not of type 0xee then it's
>>>> considered that no GPT is present. Is think that this check is
>>>> error-prone (with e.g. bootcamp) and unnecessary
>>> Agreed.  Can you fix this?
>>>
>> I send a patch for it. However I couldn't test it because of the bug in
>> the make system. About the bug I'll post in appropriate thread. In that
>> patch the pc module explicitely checks for the absence of GPT table. IMO
>> it's ugly. Another alternative would be to assign priorities to the
>> partition tables. I also tried this way and send patch for it. Again I
>> couldn't test it.
> 
> This patch looks overly complicated.  Fixing the discussed problem ought
> to be much simpler...
> 
>> -  /* Make sure the MBR is a protective MBR and not a normal MBR.  */
>> -  if (mbr.entries[0].type != GRUB_PC_PARTITION_TYPE_GPT_DISK)
>> -return grub_error (GRUB_ERR_BAD_PART_TABLE, "no GPT partition map 
>> found");
> 
> ... here, it'd be just a matter of replacing this hardcoded '0' with an
> iterator.
> 
> And maybe something similar for partmap/pc.c.
> 
I don't think that this is enough since with bootcamp you can have a MBR
 without a protective entry. This leaves us with just two option:
priorities and ugly check in partmap/pc.c. I would prefer the first one
since the second one is unextensible. With first one I'll be able to do
something similar to what you can find in other bootmanagers: ability to
have more then one "primary" partition (like in http://symon.ru ).
Vladimir 'phcoder' Serbinenko


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

Re: [PATCH] Move kern/loader.c to boot.mod and add preboot_support (was Re: Sendkey patch)

[phcoder]

Hello,all. I was busy studying so wasn't watching the list. Is there a 
particular reason why my patch still isn't incorporated?

Thanks
phcoder
Javier Martín wrote:

El lun, 08-09-2008 a las 23:25 +0300, Vesa Jääskeläinen escribió:

Javier Martín wrote:

El lun, 08-09-2008 a las 22:48 +0300, Vesa Jääskeläinen escribió:

phcoder wrote:

Hello. As I said in another email there is no need for it. I send a
patch for it.

Doesn't this break our rescue mode ?

How would it? As with other commands, there would be two versions of it,
one for rescue and one for normal. Besides, what is the point in having
the "boot" command in kernel -and thus always available- if you can't
load a kernel to boot?

You may want to chainload something?

Isn't "chainloader" also a command external to the kernel? I recall
seeing _chain.mod (rescue) and chain.mod (normal). So, as long as those
don't go with core.img, you won't chainload a thing.




___
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] Move kern/loader.c to boot.mod and add preboot_support (was Re: Sendkey patch)

[phcoder]

I did. The discussion seems to simply have died out without any official 
response

Thanks
Vladimir 'phcoder' Serbinenko
Vesa Jääskeläinen wrote:

phcoder wrote:

Hello,all. I was busy studying so wasn't watching the list. Is there a
particular reason why my patch still isn't incorporated?


Perhaps we didn't like the move of loader/boot core functionality out of
kernel?

And I do not remember you describing in detail about interfaces and
functional design of your idea.

Tip: use threaded view to browse messages.



___
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

Bugfix: no cursor on command line

[phcoder]

Testing grub I noticed this bug. Here is bugfix
Vladimir 'phcoder' Serbinenko

Index: normal/cmdline.c
===
--- normal/cmdline.c(revision 1959)
+++ normal/cmdline.c(working copy)
@@ -148,6 +148,7 @@
 {
   static char cmdline[GRUB_MAX_CMDLINE];

+  grub_setcursor (1);
   grub_print_error ();
   grub_errno = GRUB_ERR_NONE;
   cmdline[0] = '\0';


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

Re: Bugfix: no cursor on command line

[phcoder]

I do not remember seeing a problem here. So what is actually the problem
and how to reproduce it?


I booted GRUB2 by GRUB-Legacy, command prompt appeared and worked but 
there were no cursor. I think the same problem appears when the user 
opens command line from the menu.

Vladimir 'phcoder' Serbinenko


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

Re: Bugfix: no cursor on command line

[phcoder]

Sorry it seems that my fs was corrupted which caused failure at install. 
fsck and reinstall fixed the problem

Thanks
Vladimir 'phcoder' Serbinenko
Vesa Jääskeläinen wrote:

phcoder wrote:

I do not remember seeing a problem here. So what is actually the problem
and how to reproduce it?

I booted GRUB2 by GRUB-Legacy, command prompt appeared and worked but
there were no cursor. I think the same problem appears when the user
opens command line from the menu.


Still not seeing this. There is already a call to grub_setcursor (1) at
the beginning of this function... (and that was added somewhere in 2005)...

I tried both graphical and text console and none seem to be affected.


___
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

xnu support

[phcoder]

Hello, I'm working on xnu (darwin kernel, under OSI approved APSL) 
support and would like to discuss some interfaces about it.
Issue 1) First in xnu world booter hands the loading of compressed 
hibernation image. Resuming doesn't need to load the kernel conventional 
way. And trying to resume from hibernate should be done before trying to 
load kernel. So I propose the following configuration entries:

menuentry "my XNU"
{
   if ! xnu_resume ; then
xnu_kernel  
xnu_extensions --cache= --dir=
xnu_loadenv 
   fi
}

Issue 2) Also normally when hibernation succeeds kernel should 
invalidate the image. Unfortunately in some scenarios it doesn't. A 
reliable way to check the image is to compare modification timestamp of 
FS and image.
I know where to find them on FS but unfortunately now grub has no way of 
interfacing this with FS code. I propose to modify

  /* Call HOOK with each file under DIR.  */
  grub_err_t (*dir) (grub_device_t device, const char *path,
 int (*hook) (const char *filename, int dir));
to
  /* Call HOOK with each file under DIR.  */
  grub_err_t (*dir) (grub_device_t device, const char *path,
 int (*hook) (const char *filename, int dir, 
grub_time_t modtime));

Or add
grub_err_t (*file_modtime) (const char *name, grub_time_t *modtime);
and add a function for retrieving FS modification type
grub_err_t (*fs_modtime) (grub_device_t device, grub_time_t *modtime);
to grub_fs_t
This has an additional benefit of invalidating image if FS was modified 
by external tool. This may be overriden by --force option to override it.
File modification timestamp are also needed to check if the extension 
cache is up to date.
Issue 3) Kernel may theoretically request loading parts to any address. 
In practice it does it only in 1Mb-64Mb range. Is it possible to somehow 
secure this range from grub_malloc after xnu_kernel command? (I would 
like to avoid "just before boot" relocations if possible)


I send an implementation of xnu_resume. Not for inclusion of course but 
for illustration

Thanks
Any opinion is appreciated
Vladimir 'phcoder' Serbinenko
Index: conf/i386.rmk
===
--- conf/i386.rmk	(revision 1962)
+++ conf/i386.rmk	(working copy)
@@ -14,3 +14,8 @@
 vga_text_mod_SOURCES = term/i386/pc/vga_text.c term/i386/vga_common.c
 vga_text_mod_CFLAGS = $(COMMON_CFLAGS)
 vga_text_mod_LDFLAGS = $(COMMON_LDFLAGS)
+
+pkglib_MODULES += xnu.mod
+xnu_mod_SOURCES = loader/xnu_resume.c loader/i386/xnu.c
+xnu_mod_CFLAGS = $(COMMON_CFLAGS)
+xnu_mod_LDFLAGS = $(COMMON_LDFLAGS)
Index: include/grub/i386/xnu.h
===
--- include/grub/i386/xnu.h	(revision 0)
+++ include/grub/i386/xnu.h	(revision 0)
@@ -0,0 +1,9 @@
+#define XNU_MEMORY_START  0x10
+#define XNU_MEMORY_END 0x400
+#define XNU_PAGESIZE 4096
+
+grub_err_t grub_xnu_boot (void);
+extern void *grub_xnu_entry_point;
+extern void *grub_xnu_stack;
+extern void *grub_xnu_arg1;
+
Index: include/grub/xnu.h
===
--- include/grub/xnu.h	(revision 0)
+++ include/grub/xnu.h	(revision 0)
@@ -0,0 +1,18 @@
+#define XNU_HIBERNATE_MAGIC 0x73696d65
+struct xnu_hibernate_header
+{
+  grub_uint64_t image_size;
+  grub_uint8_t unknown1[8];
+  grub_uint32_t restorepage;
+  grub_uint32_t numofpages;
+  grub_uint32_t entry_point;
+  grub_uint32_t stack;
+  grub_uint8_t unknown2[20];
+  grub_uint32_t restored_checksum;
+  grub_uint8_t unknown3[20];
+  grub_uint32_t magic;
+  grub_uint8_t unknown4[28];
+  grub_uint64_t encoffset;
+  grub_uint8_t unknown5[360];
+  grub_uint32_t extmapsize;
+} __attribute__ ((packed));
Index: loader/i386/xnu.c
===
--- loader/i386/xnu.c	(revision 0)
+++ loader/i386/xnu.c	(revision 0)
@@ -0,0 +1,27 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Registers on XNU boot: eip,esp and eax*/
+void *grub_xnu_entry_point=0;
+void *grub_xnu_stack=0;
+void *grub_xnu_arg1=0;
+
+grub_err_t 
+grub_xnu_boot (void)
+{
+  /*Setup regs and launch xnu*/
+  asm volatile ("movl %0, %%eax" : : "m" (grub_xnu_arg1));
+  asm volatile ("movl %0, %%ebx" : : "m" (grub_xnu_stack));
+  asm volatile ("movl %0, %%ecx" : : "m" (grub_xnu_entry_point));
+  asm volatile ("movl %%ebx, %%esp" : : );
+  asm volatile ("jmp *%%ecx" : : );
+}
Index: loader/xnu_resume.c
===
--- loader/xnu_resume.c	(revision 0)
+++ loader/xnu_resume.c	(revision 0)
@@ -0,0 +1,141 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static grub_dl_t my_mod;
+s

Move BSD and multiboot boot helper out of the kernel to their respective modules

[phcoder]

Hello, I was looking through the code and have seen that bsd and
multiboot code uses helpers in the kernel. In this patch I propose to
move these function to their respective modules
Thanks
Vladimir 'phcoder' Serbinenko

Index: conf/i386-pc.rmk
===
--- conf/i386-pc.rmk	(revision 1962)
+++ conf/i386-pc.rmk	(working copy)
@@ -219,11 +219,13 @@
 
 # For _multiboot.mod.
 _multiboot_mod_SOURCES = loader/i386/pc/multiboot.c \
+			 loader/i386/multiboot.S \
  loader/i386/pc/multiboot2.c \
  loader/multiboot2.c \
  loader/multiboot_loader.c
 _multiboot_mod_CFLAGS = $(COMMON_CFLAGS)
 _multiboot_mod_LDFLAGS = $(COMMON_LDFLAGS)
+_multiboot_mod_ASFLAGS = $(COMMON_ASFLAGS)
 
 # For multiboot.mod.
 multiboot_mod_SOURCES = loader/multiboot_loader_normal.c 
@@ -282,10 +284,12 @@
 aout_mod_LDFLAGS = $(COMMON_LDFLAGS)
 
 # For _bsd.mod
-_bsd_mod_SOURCES = loader/i386/bsd.c
+_bsd_mod_SOURCES = loader/i386/bsd.c loader/i386/bsd_helper.S
 _bsd_mod_CFLAGS = $(COMMON_CFLAGS)
 _bsd_mod_LDFLAGS = $(COMMON_LDFLAGS)
+_bsd_mod_ASFLAGS = $(COMMON_ASFLAGS)
 
+
 # For bsd.mod
 bsd_mod_SOURCES = loader/i386/bsd_normal.c
 bsd_mod_CFLAGS = $(COMMON_CFLAGS)
Index: conf/i386-coreboot.rmk
===
--- conf/i386-coreboot.rmk	(revision 1962)
+++ conf/i386-coreboot.rmk	(working copy)
@@ -139,10 +139,12 @@
 # For _multiboot.mod.
 _multiboot_mod_SOURCES = loader/i386/pc/multiboot.c \
  loader/i386/pc/multiboot2.c \
+			 loader/i386/multiboot.S \
  loader/multiboot2.c \
  loader/multiboot_loader.c
 _multiboot_mod_CFLAGS = $(COMMON_CFLAGS)
 _multiboot_mod_LDFLAGS = $(COMMON_LDFLAGS)
+_multiboot_mod_ASFLAGS = $(COMMON_ASFLAGS)
 
 # For multiboot.mod.
 multiboot_mod_SOURCES = loader/multiboot_loader_normal.c 
Index: conf/i386-ieee1275.rmk
===
--- conf/i386-ieee1275.rmk	(revision 1962)
+++ conf/i386-ieee1275.rmk	(working copy)
@@ -113,10 +113,12 @@
 
 # For _multiboot.mod.
 _multiboot_mod_SOURCES = loader/ieee1275/multiboot2.c \
+			 loader/i386/multiboot.S \
 			 loader/multiboot2.c \
 			 loader/multiboot_loader.c
 _multiboot_mod_CFLAGS = $(COMMON_CFLAGS)
 _multiboot_mod_LDFLAGS = $(COMMON_LDFLAGS)
+_multiboot_mod_ASFLAGS = $(COMMON_ASFLAGS)
 
 # For multiboot.mod.
 multiboot_mod_SOURCES = loader/multiboot_loader_normal.c 
Index: kern/i386/loader.S
===
--- kern/i386/loader.S	(revision 1962)
+++ kern/i386/loader.S	(working copy)
@@ -117,127 +117,3 @@
 linux_setup_seg:
 	.word	0
 	.code32
-
-
-/*
- * This starts the multiboot kernel.
- */
-
-VARIABLE(grub_multiboot_payload_size)
-	.long	0
-VARIABLE(grub_multiboot_payload_orig)
-	.long	0
-VARIABLE(grub_multiboot_payload_dest)
-	.long	0
-VARIABLE(grub_multiboot_payload_entry_offset)
-	.long	0
-
-/*
- * The relocators below understand the following parameters:
- * ecx:	Size of the block to be copied.
- * esi:	Where to copy from (always lowest address, even if we're relocating
- *  backwards).
- * edi:	Where to copy to (likewise).
- * edx:	Offset of the entry point (relative to the beginning of the block).
- */
-VARIABLE(grub_multiboot_forward_relocator)
-	/* Add entry offset.  */
-	addl	%edi, %edx
-
-	/* Forward copy.  */
-	cld
-	rep
-	movsb
-
-	jmp	*%edx
-VARIABLE(grub_multiboot_forward_relocator_end)
-
-VARIABLE(grub_multiboot_backward_relocator)
-	/* Add entry offset (before %edi is mangled).  */
-	addl	%edi, %edx
-
-	/* Backward movsb is implicitly off-by-one.  compensate that.  */
-	decl	%esi
-	decl	%edi
-
-	/* Backward copy.  */
-	std
-	addl	%ecx, %esi
-	addl	%ecx, %edi
-	rep
-	movsb
-
-	jmp	*%edx
-VARIABLE(grub_multiboot_backward_relocator_end)
-
-FUNCTION(grub_multiboot_real_boot)
-	/* Push the entry address on the stack.  */
-	pushl	%eax
-	/* Move the address of the multiboot information structure to ebx.  */
-	movl	%edx,%ebx
-
-	/* Unload all modules and stop the floppy driver.  */
-	call	EXT_C(grub_dl_unload_all)
-	call	EXT_C(grub_stop_floppy)
-
-	/* Interrupts should be disabled.  */
-	cli
-
-	/* Where do we copy what from.  */
-	movl	EXT_C(grub_multiboot_payload_size), %ecx
-	movl	EXT_C(grub_multiboot_payload_orig), %esi
-	movl	EXT_C(grub_multiboot_payload_dest), %edi
-	movl	EXT_C(grub_multiboot_payload_entry_offset), %edx
-
-	/* Move the magic value into eax.  */
-	movl	$MULTIBOOT_MAGIC2, %eax
-
-	/* Jump to the relocator.  */
-	popl	%ebp
-	jmp 	*%ebp
-	
-/*
- * This starts the multiboot 2 kernel.
- */
-
-FUNCTION(grub_multiboot2_real_boot)
-/* Push the entry address on the stack.  */
-pushl   %eax
-/* Move the address of the multiboot information structure to ebx.  */
-movl%edx,%ebx
-
-/* Unload all modules and stop th

Re: Implementing commands from TODO list

[phcoder]

Bandan wrote:

(sorry phcoder and Vesa Jääskeläinen ! ).

NP
Personally, I would like to start with "uppermem" as I have already 
gone through the relevant code and it will be easier for me to start with 
it.

Uppermem is i386-bound. I propose more general format:
meminfo [-l] [-s VAR]
Which outputs total amount of memory.
If launched with -s VAR this value is stored to variable
If launched with -v it outputs complete memory map

Thank
Vladimir 'phcoder' Serbinenko


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

[PATCH] Allow to install in non-default prefixes

[phcoder]

This patch adds -p option for grub-setup on i386-pc. Without it install 
to any prefix different from /boot/grub failed

Thank
Vladimir 'phcoder' Serbinenko
Index: util/i386/pc/grub-setup.c
===
--- util/i386/pc/grub-setup.c   (revision 1964)
+++ util/i386/pc/grub-setup.c   (working copy)
@@ -94,6 +94,7 @@
 
 static void
 setup (const char *dir,
+   const char *prefix,
const char *boot_file, const char *core_file,
const char *root, const char *dest, int must_embed)
 {
@@ -373,7 +374,7 @@
   
   /* Make sure that GRUB reads the identical image as the OS.  */
   tmp_img = xmalloc (core_size);
-  core_path_dev = grub_util_get_path (DEFAULT_DIRECTORY, core_file);
+  core_path_dev = grub_util_get_path (prefix, core_file);
   
   /* It is a Good Thing to sync two times.  */
   sync ();
@@ -540,6 +541,7 @@
   -b, --boot-image=FILE   use FILE as the boot image [default=%s]\n\
   -c, --core-image=FILE   use FILE as the core image [default=%s]\n\
   -d, --directory=DIR use GRUB files in the directory DIR [default=%s]\n\
+  -p, --prefix=DIRspecify the name of GRUB directory relative to 
partition root [default=%s]\n \
   -m, --device-map=FILE   use FILE as the device map [default=%s]\n\
   -r, --root-device=DEV   use DEV as the root device [default=guessed]\n\
   -h, --help  display this message and exit\n\
@@ -548,7 +550,8 @@
 \n\
 Report bugs to <%s>.\n\
 ",
-   DEFAULT_BOOT_FILE, DEFAULT_CORE_FILE, DEFAULT_DIRECTORY,
+   DEFAULT_BOOT_FILE, DEFAULT_CORE_FILE, DEFAULT_DIRECTORY, 
+   DEFAULT_DIRECTORY,
DEFAULT_DEVICE_MAP, PACKAGE_BUGREPORT);
 
   exit (status);
@@ -575,6 +578,7 @@
   char *dev_map = 0;
   char *root_dev = 0;
   char *dest_dev;
+  char *prefix = 0;
   int must_embed = 0;
   
   progname = "grub-setup";
@@ -582,7 +586,7 @@
   /* Check for options.  */
   while (1)
 {
-  int c = getopt_long (argc, argv, "b:c:d:m:r:hVv", options, 0);
+  int c = getopt_long (argc, argv, "p:b:c:d:m:r:hVv", options, 0);
 
   if (c == -1)
break;
@@ -603,6 +607,14 @@
core_file = xstrdup (optarg);
break;
 
+ case 'p':
+   if (prefix)
+ free (prefix);
+
+   prefix = xstrdup (optarg);
+   break;
+
+
  case 'd':
if (dir)
  free (dir);
@@ -723,6 +735,7 @@
   for (i = 0; devicelist[i]; i++)
{
  setup (dir ? : DEFAULT_DIRECTORY,
+prefix ? : DEFAULT_DIRECTORY,
 boot_file ? : DEFAULT_BOOT_FILE,
 core_file ? : DEFAULT_CORE_FILE,
 root_dev, grub_util_get_grub_dev (devicelist[i]), 1);
@@ -732,6 +745,7 @@
 #endif
   /* Do the real work.  */
 setup (dir ? : DEFAULT_DIRECTORY,
+  prefix ? : DEFAULT_DIRECTORY,
   boot_file ? : DEFAULT_BOOT_FILE,
   core_file ? : DEFAULT_CORE_FILE,
   root_dev, dest_dev, must_embed);
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Allow to install in non-default prefixes

[phcoder]

After speaking with daChaac on IRC some problems with patch were 
identified. Fixed now

Thanks daChaac.
phcoder

phcoder wrote:
This patch adds -p option for grub-setup on i386-pc. Without it install 
to any prefix different from /boot/grub failed

Thank
Vladimir 'phcoder' Serbinenko



Index: ChangeLog
===
--- ChangeLog   (revision 1966)
+++ ChangeLog   (working copy)
@@ -1,3 +1,9 @@
+2009-02-01  Vladimir Serbinenko  
+
+   Add prefix option for grub-setup
+
+   * util/i386/pc/grub-setup.c (grub_video_vbe_scroll): Add -p option.
+
 2009-02-01  Vesa Jääskeläinen  
 
Base on patch on bug #24154 created by Tomas Tintera

Index: util/i386/pc/grub-setup.c
===
--- util/i386/pc/grub-setup.c   (revision 1966)
+++ util/i386/pc/grub-setup.c   (working copy)
@@ -94,6 +94,7 @@
 
 static void
 setup (const char *dir,
+   const char *prefix_dir,
const char *boot_file, const char *core_file,
const char *root, const char *dest, int must_embed)
 {
@@ -373,7 +374,7 @@
   
   /* Make sure that GRUB reads the identical image as the OS.  */
   tmp_img = xmalloc (core_size);
-  core_path_dev = grub_util_get_path (DEFAULT_DIRECTORY, core_file);
+  core_path_dev = grub_util_get_path (prefix_dir, core_file);
   
   /* It is a Good Thing to sync two times.  */
   sync ();
@@ -540,6 +541,7 @@
   -b, --boot-image=FILE   use FILE as the boot image [default=%s]\n\
   -c, --core-image=FILE   use FILE as the core image [default=%s]\n\
   -d, --directory=DIR use GRUB files in the directory DIR [default=%s]\n\
+  -p, --prefix=DIRspecify the name of GRUB directory relative to 
partition root [default=%s]\n \
   -m, --device-map=FILE   use FILE as the device map [default=%s]\n\
   -r, --root-device=DEV   use DEV as the root device [default=guessed]\n\
   -h, --help  display this message and exit\n\
@@ -548,7 +550,8 @@
 \n\
 Report bugs to <%s>.\n\
 ",
-   DEFAULT_BOOT_FILE, DEFAULT_CORE_FILE, DEFAULT_DIRECTORY,
+   DEFAULT_BOOT_FILE, DEFAULT_CORE_FILE, DEFAULT_DIRECTORY, 
+   DEFAULT_DIRECTORY,
DEFAULT_DEVICE_MAP, PACKAGE_BUGREPORT);
 
   exit (status);
@@ -575,6 +578,7 @@
   char *dev_map = 0;
   char *root_dev = 0;
   char *dest_dev;
+  char *prefix_dir = 0;
   int must_embed = 0;
   
   progname = "grub-setup";
@@ -582,7 +586,7 @@
   /* Check for options.  */
   while (1)
 {
-  int c = getopt_long (argc, argv, "b:c:d:m:r:hVv", options, 0);
+  int c = getopt_long (argc, argv, "p:b:c:d:m:r:hVv", options, 0);
 
   if (c == -1)
break;
@@ -603,6 +607,13 @@
core_file = xstrdup (optarg);
break;
 
+ case 'p':
+   if (prefix_dir)
+ free (prefix_dir);
+
+   prefix_dir = xstrdup (optarg);
+   break;
+
  case 'd':
if (dir)
  free (dir);
@@ -723,6 +734,7 @@
   for (i = 0; devicelist[i]; i++)
{
  setup (dir ? : DEFAULT_DIRECTORY,
+prefix_dir ? : DEFAULT_DIRECTORY,
 boot_file ? : DEFAULT_BOOT_FILE,
 core_file ? : DEFAULT_CORE_FILE,
 root_dev, grub_util_get_grub_dev (devicelist[i]), 1);
@@ -732,6 +744,7 @@
 #endif
   /* Do the real work.  */
 setup (dir ? : DEFAULT_DIRECTORY,
+  prefix_dir ? : DEFAULT_DIRECTORY,
   boot_file ? : DEFAULT_BOOT_FILE,
   core_file ? : DEFAULT_CORE_FILE,
   root_dev, dest_dev, must_embed);
@@ -743,6 +756,7 @@
   free (boot_file);
   free (core_file);
   free (dir);
+  free (prefix_dir);
   free (dev_map);
   free (root_dev);
   free (dest_dev);
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

[Bugfix] Hang on new mac laptops

[phcoder]

Hello. On new mac laptops waiting for keyboard event causes random 
hangs. Bugfix attached

Thanks
Vladimir 'phcoder' Serbinenko

Index: ChangeLog
===
--- ChangeLog   (revision 1967)
+++ ChangeLog   (working copy)
@@ -1,3 +1,10 @@
+2009-02-03  Vladimir Serbinenko 
+
+   Don't rely on event for keyboard on EFI. It causes random hangs
+	Great thanks to Florian Idelberger for testing and helping finding 
this bug

+
+   * term/efi/console.c: Replace wait for event with grub_millisleep (10)
+   
 2009-02-01  Felix Zielcke  

* INSTALL: Note that we now require at least autconf 2.59 and that LZO
Index: term/efi/console.c
===
--- term/efi/console.c  (revision 1967)
+++ term/efi/console.c  (working copy)
@@ -226,9 +226,10 @@

   do
 {
-  status = efi_call_3 (b->wait_for_event, 1, &(i->wait_for_key), 
&index);
+  /*  status = efi_call_3 (b->wait_for_event, 1, 
&(i->wait_for_key), &index);

   if (status != GRUB_EFI_SUCCESS)
-return -1;
+return -1;*/
+  grub_millisleep (10);

   grub_console_checkkey ();
 }


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

Re: [Bugfix] Hang on new mac laptops

[phcoder]

Fixed
Pavel Roskin wrote:

On Tue, 2009-02-03 at 22:30 +0100, phcoder wrote:
-  status = efi_call_3 (b->wait_for_event, 1, &(i->wait_for_key), 
&index);
+  /*  status = efi_call_3 (b->wait_for_event, 1, 
&(i->wait_for_key), &index);

if (status != GRUB_EFI_SUCCESS)
-return -1;
+return -1;*/
+  grub_millisleep (10);


Please don't leave commented out code.  If you want a comment to be
there, you can write something.  If you want to preserve the file
history, Subversion does it already.



Index: ChangeLog
===
--- ChangeLog	(revision 1967)
+++ ChangeLog	(working copy)
@@ -1,3 +1,10 @@
+2009-02-04  Vladimir Serbinenko 
+
+	Don't rely on event for keyboard on EFI. It causes random hangs
+	Great thanks to Florian Idelberger for testing and helping finding this bug 
+
+	* term/efi/console.c: Replace wait for event with grub_millisleep (10)
+	
 2009-02-01  Felix Zielcke  
 
 	* INSTALL: Note that we now require at least autconf 2.59 and that LZO
Index: term/efi/console.c
===
--- term/efi/console.c	(revision 1967)
+++ term/efi/console.c	(working copy)
@@ -226,9 +226,9 @@
 
   do
 {
-  status = efi_call_3 (b->wait_for_event, 1, &(i->wait_for_key), &index);
-  if (status != GRUB_EFI_SUCCESS)
-return -1;
+  /* Don't use wait_for_event it's known 
+	 to cause hangs on some mac models */
+  grub_millisleep (10);
   
   grub_console_checkkey ();
 }
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Remove trailing space from FAT label

[phcoder]

Hello. Here is the patch to remove trailing spaces from FAT label. These 
spaces generally aren't considiered to be part of label

Thanks
Vladimir 'phcoder' Serbinenko
Index: fs/fat.c
===
--- fs/fat.c	(revision 1973)
+++ fs/fat.c	(working copy)
@@ -809,7 +809,13 @@
 
   if (dir.attr == GRUB_FAT_ATTR_VOLUME_ID)
 	{
-	  *label = grub_strndup ((char *) dir.name, 11);
+	  int labellen = 0, i;
+	  for (i = 0; i < 11; i++)
+	if (dir.name[i] != ' ')
+	  labellen = i + 1;
+
+	  *label = grub_strndup ((char *) dir.name, labellen);
+	  
 	  return GRUB_ERR_NONE;
 	}
 }
Index: ChangeLog
===
--- ChangeLog	(revision 1973)
+++ ChangeLog	(working copy)
@@ -1,3 +1,9 @@
+2009-02-04  Vladimir Serbinenko  
+
+	Remove trailing spaces from FAT label
+
+	* fs/fat.c (grub_fat_label): Remove trailing spaces
+
 2009-02-04  Felix Zielcke  
 
 	util/getroot.c (grub_util_get_grub_dev): Add support for /dev/mdNpN and
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: Move BSD and multiboot boot helper out of the kernel to their respective modules

[phcoder]

Hello. On the IRC discussion it was said that removing call to 
grub_dl_unload_all_modules isn't a good thing. I would like to discuss 
this on the list

1) Call to this functon is present only on i386-pc
2) I would suggest an interface for preboot hooks if modules needs to do 
something before booting
3) If it's really needed to unload modules one could add a function 
grub_dl_unload_all_modules_except (grub_dl_t *mod)
Then the module before booting kernel would call this function and after 
it no external calls are allowed.
4) Not being able to add a new kernel type by module alone is IMHO a 
severe limitation to module infrastructure

Thanks
Vladimir 'phcoder' Serbinenko
phcoder wrote:

Hello, I was looking through the code and have seen that bsd and
multiboot code uses helpers in the kernel. In this patch I propose to
move these function to their respective modules
Thanks
Vladimir 'phcoder' Serbinenko





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

Re: [PATCH] Allow to install in non-default prefixes

[phcoder]

Sorry, Changelog entry was wrong:
+2009-02-04  Vladimir Serbinenko  
+
+   Add prefix option for grub-setup
+
+   * util/i386/pc/grub-setup.c (main): Add -p option.
+   (setup): additional argument prefix_dir

Thanks
Vladimir 'phcoder' Serbinenko

phcoder wrote:
After speaking with daChaac on IRC some problems with patch were 
identified. Fixed now

Thanks daChaac.
phcoder

phcoder wrote:
This patch adds -p option for grub-setup on i386-pc. Without it 
install to any prefix different from /boot/grub failed

Thank
Vladimir 'phcoder' Serbinenko







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

Re: Remove trailing space from FAT label

[phcoder]

Hello
Suppose the label is "DOS \0", 
Such a label is incorrect. But I agree with you that we should reuse the 
 code and be fault-tolerant (I regularly see FAT volumes breaking the 
specifications). Additionally there is a mechanism of nice fat label 
which works the same way as long names (supported only by some OS). 
Unifying the code would make these labels accessible. So I'll write a 
new proposition soon.

Thanks
Vladimir 'phcoder' Serbinenko




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

copyright assignment

[phcoder]

Hello I'm writing a large chunk of code: xnu support and EFI runtime 
emulator. It will probably not be finished for at least another week or 
two. But could I already recieve a copyright assignment? Also I would 
like to retain the right of relicensing the same code under other licence

Thanks
Vladimir 'phcoder' Serbinenko


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

[Bugfix] vbetest doesn't return to text mode

[phcoder]

Hello. In text mode bits_per_pixel isn't set. Because of it 
grub_vbe_set_video_mode refuses to go back to text mode after vbetest 
command. Here is a bugfix

Thanks
Vladimir 'phcoder' Serbinenko
Index: video/i386/pc/vbe.c
===
--- video/i386/pc/vbe.c	(revision 1973)
+++ video/i386/pc/vbe.c	(working copy)
@@ -215,6 +215,8 @@
 case 15: framebuffer.bytes_per_pixel = 2; break;
 case 8: framebuffer.bytes_per_pixel = 1; break;
 default:
+  if (mode <= 3 || mode ==  7)
+	break; 
   grub_vbe_bios_set_mode (old_mode, 0);
   return grub_error (GRUB_ERR_BAD_DEVICE,
  "cannot set VBE mode %x",
Index: ChangeLog
===
--- ChangeLog	(revision 1973)
+++ ChangeLog	(working copy)
@@ -1,3 +1,10 @@
+2009-02-05  Vladimir Serbinenko  
+
+	Don't check bits_per_pixel in text mode
+
+	* video/i386/pc/vbe.c (grub_vbe_set_video_mode): Don't check 
+	bits_per_pixel in text mode
+
 2009-02-04  Felix Zielcke  
 
 	util/getroot.c (grub_util_get_grub_dev): Add support for /dev/mdNpN and
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Framebuffer address and kernel video mode

[phcoder]

Hello. First of all some good news: I managed to boot xnu kernel. To do 
so I need to set it to video mode and pass video mode info to kernel. 
Now I do it in adapter-specific way which is bad and ugly. So I would 
like to propose an interface to set video mode before loading kernel and 
then retrieve information:
For this I propose to put grub_gfxterm_init lines 253 (modevar = 
grub_env_get ("gfxmode"))-482 (grub_video_fill_rect (...)) into video.c as

grub_video_setup_by_var (char *varname)
The informations I need is:

framebuffer address, bytes_per_scan_line, resolution, color depth

Unfortunately framebuffer_address and bytes_per_scanline is missing from 
 struct grub_video_mode_info. I propose to add it to this structure


Thanks
Vladimir 'phcoder' Serbinenko


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

Re: [PATCH] try to avoid false positives on FAT filesystem

[phcoder]

If I understood you correctly you propose to use partition table 
information to determine filesystem. I'm personally against it. First of 
all it isn't portable - it probably wouldn't work on GPT. Second if you 
just do mkfs.*  the partition type isn't changed. Linux ignores 
partition type and so if your patch is applied there will be many bug 
reports like "hey, *FS isn't detected". Finally sometimes you 
intentionally change partition type in the technics like partition 
hiding. IMO the correct solution to this problem is to make sure that 
fat and ntfs are probed at last. Should we add a priority field for this?

Thanks
Vladimir 'phcoder' Serbinenko
Felix Zielcke wrote:

Here's a little patch to check if
bpb.version_specific.fat12_or_fat16.fstype or
bpb.version_specific.fat32.fstype has the string FAT12/FAT16/FAT32
As can be seen on [0] and [1] Dell PCs have a small FAT partition
containing some utilities.
It seems like mkfs.ext2 isn't always clearing the first 512 bytes.
Good for us is that fstype is set to .AT16 on these Dell partitions, so
it can be easily avoided.
Are there any objections?

[0] http://bugs.debian.org/514263
[1] http://bugs.debian.org/505137




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

Re: Framebuffer address and kernel video mode

[phcoder]

Colin D Bennett wrote:

feature.  That is, potentially future video drivers might not use a
framebuffer. (OpenGL driver? :-) 


In this context I would think more about X11 or vnc driver

> The VBE driver can return the

framebuffer address, but if another driver can't provide it, then maybe
NULL is returned instead, and this would have to be handled by clients
of the video API.
That's why I proposed to pass variable name to the parameter. Not having 
a framebuffer address means that xnu will boot in blind mode. So one 
should be able to specify video drivers for grub and xnu separately:

E.g
gfxmode=vnc
[..]
menuentry "Darwin" {
xnugfx=vbe
[...]
}
Thanks
Vladimir 'phcoder' Serbinenko


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

Re: [PATCH] try to avoid false positives on FAT filesystem

[phcoder]

Currently GRUB tries first the filesystem which was loaded at last. If 
you do

rmmod ext2
insmod ext2
then ext2 will be probed first. If we want reliable ordering we need 
priority field.

Thanks
Vladimir 'phcoder' Serbinenko

Felix Zielcke wrote:

Am Freitag, den 06.02.2009, 07:07 +0100 schrieb phcoder:
If I understood you correctly you propose to use partition table 
information to determine filesystem. I'm personally against it. First of 
all it isn't portable - it probably wouldn't work on GPT. Second if you 
just do mkfs.*  the partition type isn't changed. Linux ignores 
partition type and so if your patch is applied there will be many bug 
reports like "hey, *FS isn't detected". Finally sometimes you 
intentionally change partition type in the technics like partition 
hiding. IMO the correct solution to this problem is to make sure that 
fat and ntfs are probed at last. Should we add a priority field for this?

No I don't want to check the partition type.
FAT partitions normally have the string FAT12/FAT16/FAT32 at the
beginning of 512 bytes of the partition. But these DELL FAT partions
have there the string .AT16 so it would be a solution for the Debian bug
report we got.
But yes the best would be to probe for FAT at last but I don't know how
to change the order, in fs.lst FAT is listed after ext2 but it seems
that FAT is checked before ext2.





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

Re: Implementing commands from TODO list

[phcoder]

You might want to have a look at lsmmap function
Vladimir 'phcoder' Serbinenko
Bandan wrote:
First thing's first; I finally realized while getting my daily dose of grub2 
that I had unintentionally tried to post my message in a wrong thread 
here :
http://lists.gnu.org/archive/html/grub-devel/2009-01/msg00157.html 

It was very careless on my part and I sincerely apologize for the noise 
(sorry phcoder and Vesa Jääskeläinen ! ).


Now to my point:

I was looking at the TODO list here http://grub.enbug.org/TodoList into 
the list of missing commands http://grub.enbug.org/CommandList. As I 
see that there is not much talk about  them on the list, I would like to 
track the missing commands and start adding them to Grub2. 
Personally, I would like to start with "uppermem" as I have already 
gone through the relevant code and it will be easier for me to start with 
it.


Any ideas/suggestions would be greatly appreciated.

Thanks,
Bandan
 




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

Re: [PATCH] Move kern/loader.c to boot.mod and add preboot_support (was Re: Sendkey patch)

[phcoder]

A version with biosdisk, pc and ext2
before: 24800
after: 24687
But another matter is expandability - preboot hooks are important. 
Without them implementation of sendkey or map is impossible. And adding 
preboot hooks to kernel would increase its size by 150-200 bytes.
Also I don't see how this change would prevent integrating e.g. _linux 
in the core. But modules for loading kernels are often reltively big 
since they have to treat multiple versions of boot protocol.
It also seems that some parts of my patch were missing. I send a 
completed version.

Thanks
Vladimir 'phcoder' Serbinenko
Robert Millan wrote:

On Mon, Sep 08, 2008 at 10:11:33PM +0200, Javier Martín wrote:

El lun, 08-09-2008 a las 22:48 +0300, Vesa Jääskeläinen escribió:

phcoder wrote:

Hello. As I said in another email there is no need for it. I send a
patch for it.

Doesn't this break our rescue mode ?

How would it? As with other commands, there would be two versions of it,
one for rescue and one for normal. Besides, what is the point in having
the "boot" command in kernel -and thus always available- if you can't
load a kernel to boot?


Vladimir, you're proposing an important change because it modifies the goals
of the rescue mode, but I see there's neither significant support for or
against your proposal.

I think it would help if you provide numbers on how much size do kernel and
boot.mod have before and after the proposed change (on i386-pc).



Index: conf/common.rmk
===
--- conf/common.rmk	(revision 1967)
+++ conf/common.rmk	(working copy)
@@ -325,7 +325,7 @@
 scsi_mod_LDFLAGS = $(COMMON_LDFLAGS)
 
 # Commands.
-pkglib_MODULES += hello.mod boot.mod terminal.mod ls.mod	\
+pkglib_MODULES += hello.mod _boot.mod boot.mod terminal.mod ls.mod	\
 	cmp.mod cat.mod help.mod search.mod	\
 	loopback.mod fs_uuid.mod configfile.mod echo.mod	\
 	terminfo.mod test.mod blocklist.mod hexdump.mod		\
@@ -336,8 +336,13 @@
 hello_mod_CFLAGS = $(COMMON_CFLAGS)
 hello_mod_LDFLAGS = $(COMMON_LDFLAGS)
 
+# For _boot.mod.
+_boot_mod_SOURCES = commands/boot.c
+_boot_mod_CFLAGS = $(COMMON_CFLAGS)
+_boot_mod_LDFLAGS = $(COMMON_LDFLAGS)
+
 # For boot.mod.
-boot_mod_SOURCES = commands/boot.c
+boot_mod_SOURCES = commands/boot_normal.c
 boot_mod_CFLAGS = $(COMMON_CFLAGS)
 boot_mod_LDFLAGS = $(COMMON_LDFLAGS)
 
Index: conf/i386-pc.rmk
===
--- conf/i386-pc.rmk	(revision 1967)
+++ conf/i386-pc.rmk	(working copy)
@@ -41,7 +41,7 @@
 # For kernel.img.
 kernel_img_SOURCES = kern/i386/pc/startup.S kern/main.c kern/device.c \
 	kern/disk.c kern/dl.c kern/file.c kern/fs.c kern/err.c \
-	kern/misc.c kern/mm.c kern/loader.c kern/rescue.c kern/term.c \
+	kern/misc.c kern/mm.c kern/rescue.c kern/term.c \
 	kern/time.c \
 	kern/i386/dl.c kern/i386/pc/init.c kern/i386/pc/mmap.c \
 	kern/parser.c kern/partition.c \
@@ -52,7 +52,7 @@
 	term/i386/pc/console.c term/i386/vga_common.c \
 	symlist.c
 kernel_img_HEADERS = arg.h boot.h cache.h device.h disk.h dl.h elf.h elfload.h \
-	env.h err.h file.h fs.h kernel.h loader.h misc.h mm.h net.h parser.h \
+	env.h err.h file.h fs.h kernel.h misc.h mm.h net.h parser.h \
 	partition.h pc_partition.h rescue.h symbol.h term.h time.h types.h \
 	machine/biosdisk.h machine/boot.h machine/console.h machine/init.h \
 	machine/memory.h machine/loader.h machine/vga.h machine/vbe.h \
@@ -112,7 +112,7 @@
 
 # For grub-emu.
 util/grub-emu.c_DEPENDENCIES = grub_emu_init.h
-grub_emu_SOURCES = commands/boot.c commands/cat.c commands/cmp.c	\
+grub_emu_SOURCES = commands/boot.c commands/boot_normal.c commands/cat.c commands/cmp.c	\
 	commands/configfile.c commands/echo.c commands/help.c		\
 	commands/terminal.c commands/ls.c commands/test.c 		\
 	commands/search.c commands/blocklist.c commands/hexdump.c	\
@@ -125,7 +125,7 @@
 	kern/device.c kern/disk.c kern/dl.c kern/elf.c kern/env.c	\
 	kern/err.c			\
 	normal/execute.c kern/file.c kern/fs.c normal/lexer.c 		\
-	kern/loader.c kern/main.c kern/misc.c kern/parser.c		\
+	kern/main.c kern/misc.c kern/parser.c		\
 	grub_script.tab.c kern/partition.c kern/rescue.c kern/term.c	\
 	normal/arg.c normal/cmdline.c normal/command.c normal/function.c\
 	normal/completion.c normal/main.c normal/color.c		\
Index: conf/i386-efi.rmk
===
--- conf/i386-efi.rmk	(revision 1967)
+++ conf/i386-efi.rmk	(working copy)
@@ -49,7 +49,7 @@
 	kern/device.c kern/disk.c kern/dl.c kern/elf.c kern/env.c	\
 	kern/err.c			\
 	normal/execute.c kern/file.c kern/fs.c normal/lexer.c 		\
-	kern/loader.c kern/main.c kern/misc.c kern/parser.c		\
+	kern/main.c kern/misc.c kern/parser.c		\
 	grub_script.tab.c kern/partition.c kern/rescue.c kern/term.c	\
 	normal/arg.c normal/cmdline.c normal/command.c normal/function.c\
 	normal/completion.c normal/context.c normal/main.c		\
@@ -82,7 +82,7 @@
 kerne

Re: Move BSD and multiboot boot helper out of the kernel to their respective modules

[phcoder]

This is small enough that it could make sense to use inline asm instead,
so we can avoid a separate file.  What do you think?
I agree with this. Actually in similar place in my xnu booting I used 4 
lines of inline assembly. The only reason I kept it in .S is that I was 
in one of my lazy states. In few days I'll send two patches with your 
suggestions

Also, it'd be better if you can submit two separate patches, one for BSD
and one for Multiboot.


Thanks
Vladimir 'phcoder' Serbinenko



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

Re: Move BSD and multiboot boot helper out of the kernel to their respective modules

[phcoder]

I agree. Such workarounds take boot time and create situations when 
first action of kernel is to undo last action of booter.
Sometimes it can't be avoided but if we can we should try. Also it adds 
some flexibility since last action of booter is
performed in nice unix-like environment and kernel starts in "tabula 
rasa". An example is my system with widescreen. To init
widescreen special commands specific to my framebuffer controller are 
necessary. So if grub2 sets it kernel can start in

undistorted video mode.

Thanks
Vladimir 'phcoder' Serbinenko



Or perhaps we could avoid grub_dl_unload_all_modules altogether.  For example,
gfxterm might think that graphical mode needs to be disabled when it's
unloaded, but the OS loader knows better.  You could want to tell your OS
about the framebuffer state so it can be used by it without glitches.

The same would apply, for example, to stopping the floppy drive.  Instead
of waiting for the drive to tell us it has stopped, we could tell the OS
it's still spinning if our loader knows how to do that (and the OS knows
how to receive this information).





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

[Bugfix] Characters disappearing in gfxterm

[phcoder]

Hello. I've run into the bug that when editing menu entry in gfxterm 
characters disappear after cursor moves away from its position. Here is 
bugfix


Thanks
Vladimir 'phcoder' Serbinenko
Index: term/gfxterm.c
===
--- term/gfxterm.c  (revision 1974)
+++ term/gfxterm.c  (working copy)
@@ -744,6 +744,8 @@
   /* Render cursor to text layer.  */
   grub_video_set_active_render_target (text_layer);
   grub_video_fill_rect (color, x, y, width, height);
+  if (! show)
+write_char ();
   grub_video_set_active_render_target (GRUB_VIDEO_RENDER_TARGET_DISPLAY);
 
   /* Mark cursor to be redrawn.  */
@@ -1176,6 +1178,6 @@
 
 GRUB_MOD_FINI(term_gfxterm)
 {
-  grub_unregister_command ("bgimage");
+  grub_unregister_command ("background_image");
   grub_term_unregister_output (&grub_video_term);
 }
Index: ChangeLog
===
--- ChangeLog   (revision 1974)
+++ ChangeLog   (working copy)
@@ -1,3 +1,24 @@
+2009-02-07  Vladimir Serbinenko  
+
+   Redraw character so it doesn't disappear after cursor moves from it
+
+   * term/gfterm.c (draw_cursor): Redraw character so it 
+   doesn't disappear after cursor moves from it
+   (GRUB_MOD_FINI): correct the name of the command
+
 2009-02-05  Vesa Jääskeläinen  
 
Fixes problem when running vbetest command as reported by 
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Bugfix: directories: not reported as such on case-insensitive fs

[phcoder]

Bugfix. Patch attached
Vladimir 'phcoder' Serbinenko
Index: fs/hfsplus.c
===
--- fs/hfsplus.c	(revision 1985)
+++ fs/hfsplus.c	(working copy)
@@ -899,8 +899,8 @@
 grub_fshelp_node_t node)
 {
   grub_free (node);
-  
-  if (filetype == GRUB_FSHELP_DIR)
+
+  if ((filetype & GRUB_FSHELP_TYPE_MASK) == GRUB_FSHELP_DIR)
 	return hook (filename, 1);
   else 
 	return hook (filename, 0);
Index: ChangeLog
===
--- ChangeLog	(revision 1985)
+++ ChangeLog	(working copy)
@@ -1,0 +1,8 @@
+2009-02-09  Vladimir Serbinenko  
+
+	Bugfix: directories not reported as such on case-insensitive hfs+
+
+	* include/grub/fshelp.h: included definition of GRUB_FSHELP_TYPE_MASK 
+	and GRUB_FSHELP_FLAGS_MASK
+	* fs/hfsplus.c (grub_hfsplus_dir): ignore filetype flags
+
Index: include/grub/fshelp.h
===
--- include/grub/fshelp.h	(revision 1985)
+++ include/grub/fshelp.h	(working copy)
@@ -27,6 +27,8 @@
 typedef struct grub_fshelp_node *grub_fshelp_node_t;
 
 #define GRUB_FSHELP_CASE_INSENSITIVE	0x100
+#define GRUB_FSHELP_TYPE_MASK	0xff
+#define GRUB_FSHELP_FLAGS_MASK	0x100
 
 enum grub_fshelp_filetype
   {
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [PATCH] Long linux kernel command lines

[phcoder]

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

[Patch] remove bsd asm helper functions

[phcoder]

Hello. Asm helper functions for bsd aren't really needed. Actually BSD 
entry point may be called directly as cdecl function. With this approach 
theese helper functions don't take place in kernel anymore. Tested with 
freebsd, openbsd and netbsd. However my tests were limited to launching 
kernel and see if it complains about not being able to mount root. Can 
someone test it with complete system?

Thanks
Vladimir 'phcoder' Serbinenko
Index: kern/i386/loader.S
===
--- kern/i386/loader.S	(revision 1989)
+++ kern/i386/loader.S	(working copy)
@@ -117,23 +117,0 @@
-/*
- * Use cdecl calling convention for *BSD kernels.
- */
-
-FUNCTION(grub_unix_real_boot)
-
-callEXT_C(grub_dl_unload_all)
-callEXT_C(grub_stop_floppy)
-
-	/* Interrupts should be disabled.  */
-cli
-
-	/* Discard `grub_unix_real_boot' return address.  */
-popl%eax
-
-/* Fetch `entry' address ...  */
-popl	%eax
-
-/*
- * ... and put our return address in its place. The kernel will
- * ignore it, but it expects %esp to point to it.
- */
-call	*%eax
Index: include/grub/i386/loader.h
===
--- include/grub/i386/loader.h	(revision 1989)
+++ include/grub/i386/loader.h	(working copy)
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 
 extern grub_uint32_t EXPORT_VAR(grub_linux_prot_size);
 extern char *EXPORT_VAR(grub_linux_tmp_addr);
@@ -33,22 +32,21 @@
 void EXPORT_FUNC(grub_multiboot2_real_boot) (grub_addr_t entry,
  struct grub_multiboot_info *mbi)
  __attribute__ ((noreturn));
-void EXPORT_FUNC(grub_unix_real_boot) (grub_addr_t entry, ...)
- __attribute__ ((cdecl,noreturn));
 
 extern grub_addr_t EXPORT_VAR(grub_multiboot_payload_orig);
 extern grub_addr_t EXPORT_VAR(grub_multiboot_payload_dest);
 extern grub_size_t EXPORT_VAR(grub_multiboot_payload_size);
 extern grub_uint32_t EXPORT_VAR(grub_multiboot_payload_entry_offset);
 
 /* It is necessary to export these functions, because normal mode commands
reuse rescue mode commands.  */
 void grub_rescue_cmd_linux (int argc, char *argv[]);
 void grub_rescue_cmd_initrd (int argc, char *argv[]);
 
 extern grub_uint8_t EXPORT_VAR(grub_multiboot_forward_relocator);
 extern grub_uint8_t EXPORT_VAR(grub_multiboot_forward_relocator_end);
 extern grub_uint8_t EXPORT_VAR(grub_multiboot_backward_relocator);
 extern grub_uint8_t EXPORT_VAR(grub_multiboot_backward_relocator_end);
+void EXPORT_FUNC(grub_stop_floppy) (void);
 
 #define RELOCATOR_SIZEOF(x)	(&grub_multiboot_##x##_relocator_end - &grub_multiboot_##x##_relocator)

 #endif /* ! GRUB_LOADER_CPU_HEADER */
Index: loader/i386/bsd.c
===
--- loader/i386/bsd.c	(revision 1989)
+++ loader/i386/bsd.c	(working copy)
@@ -302,9 +302,17 @@
 
   bi.bi_kernend = kern_end;
 
-  grub_unix_real_boot (entry, bootflags | FREEBSD_RB_BOOTINFO, bootdev,
-		   0, 0, 0, &bi, bi.bi_modulep, kern_end);
+  grub_stop_floppy ();
 
+  asm volatile ("cli");
+
+  ((void (* __attribute__ ((cdecl,regparm (0  
+(grub_uint32_t, grub_uint32_t, grub_uint32_t, grub_uint32_t, 
+ grub_uint32_t, struct grub_freebsd_bootinfo *,
+ grub_addr_t, grub_addr_t))entry)
+(bootflags | FREEBSD_RB_BOOTINFO, bootdev,
+ 0, 0, 0, &bi, bi.bi_modulep, kern_end);
+  
   /* Not reached.  */
   return GRUB_ERR_NONE;
 }
@@ -348,10 +356,18 @@
   bootdev = (OPENBSD_B_DEVMAGIC + (unit << OPENBSD_B_UNITSHIFT) +
 	 (part << OPENBSD_B_PARTSHIFT));
 
-  grub_unix_real_boot (entry, bootflags, bootdev, OPENBSD_BOOTARG_APIVER,
-		   0, grub_upper_mem >> 10, grub_lower_mem >> 10,
-		   (char *) pa - buf, buf);
+  grub_stop_floppy ();
 
+  asm volatile ("cli");
+
+  ((void (* __attribute__ ((cdecl,regparm (0  
+(grub_uint32_t, grub_uint32_t, grub_uint32_t, grub_uint32_t, 
+ grub_uint32_t, grub_uint32_t,
+ grub_uint32_t, char *)) entry) 
+(bootflags, bootdev, OPENBSD_BOOTARG_APIVER,
+ 0, grub_upper_mem >> 10, grub_lower_mem >> 10,
+ (char *) pa - buf, buf);
+
   /* Not reached.  */
   return GRUB_ERR_NONE;
 }
@@ -376,9 +392,16 @@
   bootinfo->bi_count = 1;
   bootinfo->bi_data[0] = rootdev;
 
-  grub_unix_real_boot (entry, bootflags, 0, bootinfo,
-		   0, grub_upper_mem >> 10, grub_lower_mem >> 10);
+  grub_stop_floppy ();
 
+  asm volatile ("cli");
+
+  ((void (* __attribute__ ((cdecl,regparm (0  
+(grub_uint32_t, grub_uint32_t, struct grub_netbsd_bootinfo *, 
+ grub_uint32_t, grub_uint32_t, grub_uint32_t)) entry) 
+(bootflags, 0, bootinfo,
+ 0, grub_upper_mem >> 10, grub_lower_mem >> 10);
+
   /* Not reached.  */
   return GRUB_ERR_NONE;
 }
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: [Patch] remove bsd asm helper functions

[phcoder]

Sorry, forgot changelog entry. Here it is:
2009-02-11  Vladimir Serbinenko  

Move BSD helper out of kernel

* conf/i386-pc.rmk: Add loader/i386/bsd_helper.S to _bsd.mod
* kern/i386/loader.S: Removed BSD helpers
* include/grub/i386/loader.h: Removed declaration of
grub_unix_real_boot
* loader/i386/bsd.c (grub_freebsd_boot): Replaced call to
grub_unix_real_boot by direct call of kernel
(grub_netbsd_boot): Likewise
(grub_openbsd_boot): Likewise

phcoder wrote:
Hello. Asm helper functions for bsd aren't really needed. Actually BSD 
entry point may be called directly as cdecl function. With this approach 
theese helper functions don't take place in kernel anymore. Tested with 
freebsd, openbsd and netbsd. However my tests were limited to launching 
kernel and see if it complains about not being able to mount root. Can 
someone test it with complete system?

Thanks
Vladimir 'phcoder' Serbinenko





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

[Patch] Move multiboot helpers out of the kernel

[phcoder]

Hello. multiboot helpers have no real reason to stay in kernel. So here 
is the proposition to move them out of it to _multiboot.mod.

Changelog:
2009-02-11  Vladimir Serbinenko  

Move multiboot helper out of kernel

* conf/i386-pc.rmk: Add loader/i386/multiboot.S to
_multiboot.mod
* conf/i386-coreboot.rmk: Likewise
* conf/i386-ieee1275.rmk: Likewise
* kern/i386/loader.S: Move multiboot helpers from here...
* loader/i386/multiboot.S: ...moved here
* include/grub/i386/loader.h: Move declarations of multiboot
helpers from here...
* include/grub/i386/multiboot.h: ...moved here
* loader/i386/pc/multiboot.c: Added include of
grub/cpu/multiboot.h

Thanks
Vladimir 'phcoder' Serbinenko
Index: conf/i386-pc.rmk
===
--- conf/i386-pc.rmk	(revision 1989)
+++ conf/i386-pc.rmk	(working copy)
@@ -236,11 +248,13 @@
 
 # For _multiboot.mod.
 _multiboot_mod_SOURCES = loader/i386/pc/multiboot.c \
+			 loader/i386/multiboot.S \
  loader/i386/pc/multiboot2.c \
  loader/multiboot2.c \
  loader/multiboot_loader.c
 _multiboot_mod_CFLAGS = $(COMMON_CFLAGS)
 _multiboot_mod_LDFLAGS = $(COMMON_LDFLAGS)
+_multiboot_mod_ASFLAGS = $(COMMON_ASFLAGS)
 
 # For multiboot.mod.
 multiboot_mod_SOURCES = loader/multiboot_loader_normal.c 
Index: conf/i386-coreboot.rmk
===
--- conf/i386-coreboot.rmk	(revision 1989)
+++ conf/i386-coreboot.rmk	(working copy)
@@ -150,10 +150,12 @@
 # For _multiboot.mod.
 _multiboot_mod_SOURCES = loader/i386/pc/multiboot.c \
  loader/i386/pc/multiboot2.c \
+			 loader/i386/multiboot.S \
  loader/multiboot2.c \
  loader/multiboot_loader.c
 _multiboot_mod_CFLAGS = $(COMMON_CFLAGS)
 _multiboot_mod_LDFLAGS = $(COMMON_LDFLAGS)
+_multiboot_mod_ASFLAGS = $(COMMON_ASFLAGS)
 
 # For multiboot.mod.
 multiboot_mod_SOURCES = loader/multiboot_loader_normal.c 
Index: conf/i386-ieee1275.rmk
===
--- conf/i386-ieee1275.rmk	(revision 1989)
+++ conf/i386-ieee1275.rmk	(working copy)
@@ -124,10 +124,12 @@
 
 # For _multiboot.mod.
 _multiboot_mod_SOURCES = loader/ieee1275/multiboot2.c \
+			 loader/i386/multiboot.S \
 			 loader/multiboot2.c \
 			 loader/multiboot_loader.c
 _multiboot_mod_CFLAGS = $(COMMON_CFLAGS)
 _multiboot_mod_LDFLAGS = $(COMMON_LDFLAGS)
+_multiboot_mod_ASFLAGS = $(COMMON_ASFLAGS)
 
 # For multiboot.mod.
 multiboot_mod_SOURCES = loader/multiboot_loader_normal.c 
Index: kern/i386/loader.S
===
--- kern/i386/loader.S	(revision 1989)
+++ kern/i386/loader.S	(working copy)
@@ -117,104 +117,3 @@
 linux_setup_seg:
 	.word	0
 	.code32
-
-
-/*
- * This starts the multiboot kernel.
- */
-
-VARIABLE(grub_multiboot_payload_size)
-	.long	0
-VARIABLE(grub_multiboot_payload_orig)
-	.long	0
-VARIABLE(grub_multiboot_payload_dest)
-	.long	0
-VARIABLE(grub_multiboot_payload_entry_offset)
-	.long	0
-
-/*
- * The relocators below understand the following parameters:
- * ecx:	Size of the block to be copied.
- * esi:	Where to copy from (always lowest address, even if we're relocating
- *  backwards).
- * edi:	Where to copy to (likewise).
- * edx:	Offset of the entry point (relative to the beginning of the block).
- */
-VARIABLE(grub_multiboot_forward_relocator)
-	/* Add entry offset.  */
-	addl	%edi, %edx
-
-	/* Forward copy.  */
-	cld
-	rep
-	movsb
-
-	jmp	*%edx
-VARIABLE(grub_multiboot_forward_relocator_end)
-
-VARIABLE(grub_multiboot_backward_relocator)
-	/* Add entry offset (before %edi is mangled).  */
-	addl	%edi, %edx
-
-	/* Backward movsb is implicitly off-by-one.  compensate that.  */
-	decl	%esi
-	decl	%edi
-
-	/* Backward copy.  */
-	std
-	addl	%ecx, %esi
-	addl	%ecx, %edi
-	rep
-	movsb
-
-	jmp	*%edx
-VARIABLE(grub_multiboot_backward_relocator_end)
-
-FUNCTION(grub_multiboot_real_boot)
-	/* Push the entry address on the stack.  */
-	pushl	%eax
-	/* Move the address of the multiboot information structure to ebx.  */
-	movl	%edx,%ebx
-
-	/* Unload all modules and stop the floppy driver.  */
-	call	EXT_C(grub_dl_unload_all)
-	call	EXT_C(grub_stop_floppy)
-
-	/* Interrupts should be disabled.  */
-	cli
-
-	/* Where do we copy what from.  */
-	movl	EXT_C(grub_multiboot_payload_size), %ecx
-	movl	EXT_C(grub_multiboot_payload_orig), %esi
-	movl	EXT_C(grub_multiboot_payload_dest), %edi
-	movl	EXT_C(grub_multiboot_payload_entry_offset), %edx
-
-	/* Move the magic value into eax.  */
-	movl	$MULTIBOOT_MAGIC2, %eax
-
-	/* Jump to the relocator.  */
-	popl	%ebp
-	jmp 	*%ebp
-	
-/*
- * This starts the multiboot 2 kernel.
- */
-
-FUNCTION(grub_multiboot2_real_boot)
-/* Push the entry address on the stack.  */
- 

[PATCH] mtools-like FAT-label behaviour

[phcoder]

Hello. Now the handling of FAT-labels keeps the trailing spaces and 
ignores VFAT label generated by mlabel tool. Here is the patch to 
correct this. Unfortunately m$ when user set a mixed case label only 
uppercase one is saved to FS, moreover m$ keeps the mixed case label in 
the registry fooling  the user. So no way to read these. To test mixed 
case labels be sure that mlabel reports it as mixed case.

Thanks
Vladimir 'phcoder' Serbinenko
Index: ChangeLog
===
--- ChangeLog	(revision 1989)
+++ ChangeLog	(working copy)
@@ -1,0 +1,8 @@
+2009-02-11  Vladimir Serbinenko  
+
+	Trim trailing spaces in FAT label and support mtools-like labels
+	
+	* fs/fat.c (grub_fat_iterate_dir): New function based 
+	on grub_fat_find_dir
+	(grub_fat_find_dir): use grub_fat_iterate_dir
+	(grub_fat_label): likewise
Index: fs/fat.c
===
--- fs/fat.c	(revision 1989)
+++ fs/fat.c	(working copy)
@@ -45,7 +45,8 @@
  | GRUB_FAT_ATTR_HIDDEN \
  | GRUB_FAT_ATTR_SYSTEM \
  | GRUB_FAT_ATTR_DIRECTORY \
- | GRUB_FAT_ATTR_ARCHIVE)
+ | GRUB_FAT_ATTR_ARCHIVE \
+ | GRUB_FAT_ATTR_VOLUME_ID)
 
 struct grub_fat_bpb
 {
@@ -467,51 +468,21 @@
   return ret;
 }
 
-/* Find the underlying directory or file in PATH and return the
-   next path. If there is no next path or an error occurs, return NULL.
-   If HOOK is specified, call it with each file name.  */
-static char *
-grub_fat_find_dir (grub_disk_t disk, struct grub_fat_data *data,
-		   const char *path,
-		   int (*hook) (const char *filename, int dir))
+static grub_err_t
+grub_fat_iterate_dir (grub_disk_t disk, struct grub_fat_data *data,
+		  int (*hook) (const char *filename, 
+   struct grub_fat_dir_entry *dir))
 {
   struct grub_fat_dir_entry dir;
-  char *dirname, *dirp;
   char *filename, *filep = 0;
   grub_uint16_t *unibuf;
   int slot = -1, slots = -1;
   int checksum = -1;
   grub_ssize_t offset = -sizeof(dir);
-  int call_hook;
   
   if (! (data->attr & GRUB_FAT_ATTR_DIRECTORY))
-{
-  grub_error (GRUB_ERR_BAD_FILE_TYPE, "not a directory");
-  return 0;
-}
+return grub_error (GRUB_ERR_BAD_FILE_TYPE, "not a directory");
   
-  /* Extract a directory name.  */
-  while (*path == '/')
-path++;
-
-  dirp = grub_strchr (path, '/');
-  if (dirp)
-{
-  unsigned len = dirp - path;
-  
-  dirname = grub_malloc (len + 1);
-  if (! dirname)
-	return 0;
-
-  grub_memcpy (dirname, path, len);
-  dirname[len] = '\0';
-}
-  else
-/* This is actually a file.  */
-dirname = grub_strdup (path);
-
-  call_hook = (! dirp && hook);
-  
   /* Allocate space enough to hold a long name.  */
   filename = grub_malloc (0x40 * 13 * 4 + 1);
   unibuf = (grub_uint16_t *) grub_malloc (0x40 * 13 * 2);
@@ -519,7 +490,6 @@
 {
   grub_free (filename);
   grub_free (unibuf);
-  grub_free (dirname);
   return 0;
 }
   
@@ -533,15 +503,8 @@
   /* Read a directory entry.  */
   if ((grub_fat_read_data (disk, data, 0,
 			   offset, sizeof (dir), (char *) &dir)
-	   != sizeof (dir))
-	  || dir.name[0] == 0)
-	{
-	  if (grub_errno == GRUB_ERR_NONE && ! call_hook)
-	grub_error (GRUB_ERR_FILE_NOT_FOUND, "file not found");
-
-	  break;
-	}
-
+	   != sizeof (dir) || dir.name[0] == 0))
+	break;
   /* Handle long name entries.  */
   if (dir.attr == GRUB_FAT_ATTR_LONG_NAME)
 	{
@@ -594,22 +557,11 @@
 	  *grub_utf16_to_utf8 ((grub_uint8_t *) filename, unibuf,
    slots * 13) = '\0';
 	  
-	  if (*dirname == '\0' && call_hook)
-		{
-		  if (hook (filename, dir.attr & GRUB_FAT_ATTR_DIRECTORY))
-		break;
-		  
-		  checksum = -1;
-		  continue;
-		}
-
-	  if (grub_strcmp (dirname, filename) == 0)
-		{
-		  if (call_hook)
-		hook (filename, dir.attr & GRUB_FAT_ATTR_DIRECTORY);
-		  
-		  break;
-		}
+	  if (hook (filename, &dir))
+		break;
+	  
+	  checksum = -1;
+	  continue;
 	}
 
 	  checksum = -1;
@@ -617,44 +569,109 @@
 
   /* Convert the 8.3 file name.  */
   filep = filename;
-  
-  for (i = 0; i < 8 && dir.name[i] && ! grub_isspace (dir.name[i]); i++)
-	*filep++ = grub_tolower (dir.name[i]);
-  
-  *filep = '.';
-  
-  for (i = 8; i < 11 && dir.name[i] && ! grub_isspace (dir.name[i]); i++)
-	*++filep = grub_tolower (dir.name[i]);
-
-  if (*filep != '.')
-	filep++;
-  
-  *filep = '\0';
-
-  if (*dirname == '\0' && call_hook)
+  if (dir.attr & GRUB_FAT_ATTR_VOLUME_ID)
 	{
-	  if (hook (filename, dir.attr & GRUB_FAT_ATTR_DIRECTORY))
-	break;
+	  for (i = 0; i < sizeof (dir.name) && dir.name[i] 
+		 && ! gr

[PATCH] make partition active

[phcoder]

Here's the patch to add a replacement for old "makeactive" command
New syntax is
activate PARTITION
E.g.
activate hd0,1

Regards
Vladimir 'phcoder' Serbinenko
Index: ChangeLog
===
--- ChangeLog	(revision 1989)
+++ ChangeLog	(working copy)
@@ -1,3 +1,11 @@
+2009-02-11  Vladimir Serbinenko  
+
+	New command: "activate" replacement for makeactive of grub1
+	
+	* commands/i386/pc/activate.c: new file
+	* conf/i386-pc.rmk: new module activate.mod
+	add commands/i386/pc/activate.c to grub-emu sources
+
 2009-02-11  Robert Millan  
 
 	* util/grub.d/00_header.in: Update old reference to `font' command.
Index: conf/i386-pc.rmk
===
--- conf/i386-pc.rmk	(revision 1989)
+++ conf/i386-pc.rmk	(working copy)
@@ -145,4 +145,4 @@
 	\
 	disk/raid.c disk/raid5_recover.c disk/raid6_recover.c		\
 	disk/mdraid_linux.c disk/dmraid_nvidia.c disk/lvm.c		\
-	grub_emu_init.c
+	grub_emu_init.c  commands/i386/pc/activate.c

 grub_emu_LDFLAGS = $(LIBCURSES) 
 
 ifeq ($(enable_grub_emu_usb), yes)
@@ -171,3 +170,3 @@
 	vbe.mod vbetest.mod vbeinfo.mod play.mod serial.mod	\
 	ata.mod vga.mod memdisk.mod pci.mod lspci.mod \
 	aout.mod _bsd.mod bsd.mod pxe.mod pxecmd.mod datetime.mod date.mod \
	datehook.mod lsmmap.mod \
-	usb.mod uhci.mod ohci.mod usbtest.mod usbms.mod
+	usb.mod uhci.mod ohci.mod usbtest.mod usbms.mod activate.mod
 
+# For activate.mod.
+activate_mod_SOURCES = commands/i386/pc/activate.c
+activate_mod_CFLAGS = $(COMMON_CFLAGS)
+activate_mod_LDFLAGS = $(COMMON_LDFLAGS)
+
 # For biosdisk.mod.
 biosdisk_mod_SOURCES = disk/i386/pc/biosdisk.c
 biosdisk_mod_CFLAGS = $(COMMON_CFLAGS)
Index: commands/i386/pc/activate.c
===
--- commands/i386/pc/activate.c	(revision 0)
+++ commands/i386/pc/activate.c	(revision 0)
@@ -0,0 +1,114 @@
+/* activate.c - activate pc partition */
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2003  Free Software Foundation, Inc.
+ *  Copyright (C) 2003  NIIBE Yutaka 
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static grub_err_t
+grub_cmd_activate (struct grub_arg_list *state __attribute__ ((unused)),
+		int argc, char **args)
+{
+
+  grub_device_t dev;
+  struct grub_pc_partition_mbr mbr;
+  grub_partition_t part;
+  
+  int i, index;
+
+  if (argc > 1)
+return grub_error (GRUB_ERR_BAD_ARGUMENT, "too many arguments");
+
+  if (!argc)
+return grub_error (GRUB_ERR_BAD_ARGUMENT, "too few arguments");
+
+  dev = grub_device_open (args[0]); 
+
+  if (!dev)
+return grub_errno;
+
+  if (!dev->disk)
+{
+  grub_device_close (dev);
+  return grub_error (GRUB_ERR_BAD_ARGUMENT, "not a disk");
+}
+
+  if (!dev->disk->partition)
+{
+  grub_device_close (dev);
+  return grub_error (GRUB_ERR_BAD_ARGUMENT, "not a partition");
+}
+
+  if (grub_strcmp (dev->disk->partition->partmap->name, "pc_partition_map"))
+{
+  grub_device_close (dev);
+  return grub_error (GRUB_ERR_BAD_ARGUMENT, "not a pc partition");
+}
+
+  if (dev->disk->partition->offset)
+{
+  grub_device_close (dev);
+  return grub_error (GRUB_ERR_BAD_ARGUMENT, "not a primary partition");
+}
+
+  index = dev->disk->partition->index;
+  part = dev->disk->partition;
+  dev->disk->partition = 0;
+
+  /* Read the MBR.  */
+  if (grub_disk_read (dev->disk, 0, 0, sizeof (mbr), (char *) &mbr))
+{
+  dev->disk->partition = part;
+  grub_device_close (dev);
+  return grub_errno;
+}
+
+  for (i = 0; i < 4; i++)
+mbr.entries[i].flag = 0x0;
+
+  mbr.entries[index].flag = 0x80;  
+
+   /* Write the MBR.  */
+  grub_disk_write (dev->disk, 0, 0, sizeof (mbr), (char *) &mbr);
+  dev->disk->partition = part;
+  grub_device_close (dev);
+  return grub_errno;
+  
+}
+
+GRUB_MOD_INIT(activate)
+{
+  (void)mod;			/* To stop warning. */
+  grub_register_comm

Re: [PATCH] mtools-like FAT-label behaviour

[phcoder]

With this patch fat became case-sensitive which is probably wrong. 
Corrected version of patch attached

Sorry
Vladimir 'phcoder' Serbinenko
phcoder wrote:
Hello. Now the handling of FAT-labels keeps the trailing spaces and 
ignores VFAT label generated by mlabel tool. Here is the patch to 
correct this. Unfortunately m$ when user set a mixed case label only 
uppercase one is saved to FS, moreover m$ keeps the mixed case label in 
the registry fooling  the user. So no way to read these. To test mixed 
case labels be sure that mlabel reports it as mixed case.

Thanks
Vladimir 'phcoder' Serbinenko



Index: ChangeLog
===
--- ChangeLog	(revision 1989)
+++ ChangeLog	(working copy)
@@ -1,0 +1,8 @@
+2009-02-11  Vladimir Serbinenko  
+
+	Trim trailing spaces in FAT label and support mtools-like labels
+	
+	* fs/fat.c (grub_fat_iterate_dir): New function based 
+	on grub_fat_find_dir
+	(grub_fat_find_dir): use grub_fat_iterate_dir
+	(grub_fat_label): likewise
Index: fs/fat.c
===
--- fs/fat.c	(revision 1989)
+++ fs/fat.c	(working copy)
@@ -45,7 +45,8 @@
  | GRUB_FAT_ATTR_HIDDEN \
  | GRUB_FAT_ATTR_SYSTEM \
  | GRUB_FAT_ATTR_DIRECTORY \
- | GRUB_FAT_ATTR_ARCHIVE)
+ | GRUB_FAT_ATTR_ARCHIVE \
+ | GRUB_FAT_ATTR_VOLUME_ID)
 
 struct grub_fat_bpb
 {
@@ -467,51 +468,21 @@
   return ret;
 }
 
-/* Find the underlying directory or file in PATH and return the
-   next path. If there is no next path or an error occurs, return NULL.
-   If HOOK is specified, call it with each file name.  */
-static char *
-grub_fat_find_dir (grub_disk_t disk, struct grub_fat_data *data,
-		   const char *path,
-		   int (*hook) (const char *filename, int dir))
+static grub_err_t
+grub_fat_iterate_dir (grub_disk_t disk, struct grub_fat_data *data,
+		  int (*hook) (const char *filename, 
+   struct grub_fat_dir_entry *dir))
 {
   struct grub_fat_dir_entry dir;
-  char *dirname, *dirp;
   char *filename, *filep = 0;
   grub_uint16_t *unibuf;
   int slot = -1, slots = -1;
   int checksum = -1;
   grub_ssize_t offset = -sizeof(dir);
-  int call_hook;
   
   if (! (data->attr & GRUB_FAT_ATTR_DIRECTORY))
-{
-  grub_error (GRUB_ERR_BAD_FILE_TYPE, "not a directory");
-  return 0;
-}
+return grub_error (GRUB_ERR_BAD_FILE_TYPE, "not a directory");
   
-  /* Extract a directory name.  */
-  while (*path == '/')
-path++;
-
-  dirp = grub_strchr (path, '/');
-  if (dirp)
-{
-  unsigned len = dirp - path;
-  
-  dirname = grub_malloc (len + 1);
-  if (! dirname)
-	return 0;
-
-  grub_memcpy (dirname, path, len);
-  dirname[len] = '\0';
-}
-  else
-/* This is actually a file.  */
-dirname = grub_strdup (path);
-
-  call_hook = (! dirp && hook);
-  
   /* Allocate space enough to hold a long name.  */
   filename = grub_malloc (0x40 * 13 * 4 + 1);
   unibuf = (grub_uint16_t *) grub_malloc (0x40 * 13 * 2);
@@ -519,7 +490,6 @@
 {
   grub_free (filename);
   grub_free (unibuf);
-  grub_free (dirname);
   return 0;
 }
   
@@ -533,15 +503,8 @@
   /* Read a directory entry.  */
   if ((grub_fat_read_data (disk, data, 0,
 			   offset, sizeof (dir), (char *) &dir)
-	   != sizeof (dir))
-	  || dir.name[0] == 0)
-	{
-	  if (grub_errno == GRUB_ERR_NONE && ! call_hook)
-	grub_error (GRUB_ERR_FILE_NOT_FOUND, "file not found");
-
-	  break;
-	}
-
+	   != sizeof (dir) || dir.name[0] == 0))
+	break;
   /* Handle long name entries.  */
   if (dir.attr == GRUB_FAT_ATTR_LONG_NAME)
 	{
@@ -594,22 +557,11 @@
 	  *grub_utf16_to_utf8 ((grub_uint8_t *) filename, unibuf,
    slots * 13) = '\0';
 	  
-	  if (*dirname == '\0' && call_hook)
-		{
-		  if (hook (filename, dir.attr & GRUB_FAT_ATTR_DIRECTORY))
-		break;
-		  
-		  checksum = -1;
-		  continue;
-		}
-
-	  if (grub_strcmp (dirname, filename) == 0)
-		{
-		  if (call_hook)
-		hook (filename, dir.attr & GRUB_FAT_ATTR_DIRECTORY);
-		  
-		  break;
-		}
+	  if (hook (filename, &dir))
+		break;
+	  
+	  checksum = -1;
+	  continue;
 	}
 
 	  checksum = -1;
@@ -617,44 +569,109 @@
 
   /* Convert the 8.3 file name.  */
   filep = filename;
-  
-  for (i = 0; i < 8 && dir.name[i] && ! grub_isspace (dir.name[i]); i++)
-	*filep++ = grub_tolower (dir.name[i]);
-  
-  *filep = '.';
-  
-  for (i = 8; i < 11 && dir.name[i] && ! grub_isspace (dir.name[i]); i++)
-	*++filep = grub_tolower (dir.name[i]);
-
-  if (*filep != '.')
-	filep++;
-  
-  *filep = '\0';
-
-  if (*dirname == '\0' && call_hook)
+  if (dir.attr & GRUB_FAT_A

Re: [PATCH] make partition active

[phcoder]

Pavel Roskin wrote:

On Wed, 2009-02-11 at 14:43 +0100, phcoder wrote:

Here's the patch to add a replacement for old "makeactive" command
New syntax is
activate PARTITION
E.g.
activate hd0,1


Is it necessary to change the name?  I think "makeactive" is a better
name for what it does.
Actually I don't really care but on http://grub.enbug.org/CommandList it 
was suggested to change the name. But what I dislike is having this 
command without argument which always activates current root partition


Maybe we could use a more generic solution, e.g. a command for setting
different flags (or "attributes" in GPT terminology), such as bootable,
read-only, hidden (that would apply only to some partition types in the
PC partition table) and so on.


It's a good possibility but I don't want to encumber the partition 
module with non-essential functions since they're often integrated into 
core.img. But it's possible to have something like


pctool hd0,1 boot+ hidden-
gpttool hd0,1 ro+

(Actually I find the name "pc" unfortunate, IMO "fdisk" would be much 
better)

It's also possible to write a wrapper
parttool hd0,1 boot+

Which chooses the correct tool and launches it (a tool can be easily 
registered as a pair of partition style name and a function). In this 
case we wouldn't even need separate command for different partition 
style. We have however to find a way to list all available flags in


help parttool

Regards
Vladimir 'phcoder' Serbinenko




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

[PATCH] mtime support

[phcoder]

Hello. Here is the patch to support mtime. This is a prerequisite for 
-nt test which can be very useful for e.g. finding last compiled kernel

Also in the same time it makes the dir call easily extendable

Regards
Vladimir 'phcoder' Serbinenko
Index: conf/common.rmk
===
--- conf/common.rmk	(revision 1989)
+++ conf/common.rmk	(working copy)
@@ -352,7 +358,7 @@ terminal_mod_CFLAGS = $(COMMON_CFLAGS)
 terminal_mod_LDFLAGS = $(COMMON_LDFLAGS)
 
 # For ls.mod.
-ls_mod_SOURCES = commands/ls.c
+ls_mod_SOURCES = commands/ls.c lib/datetime.c
 ls_mod_CFLAGS = $(COMMON_CFLAGS)
 ls_mod_LDFLAGS = $(COMMON_LDFLAGS)
 
Index: conf/i386-coreboot.rmk
===
--- conf/i386-coreboot.rmk	(revision 1989)
+++ conf/i386-coreboot.rmk	(working copy)
@@ -87,7 +87,7 @@ grub_emu_SOURCES = commands/boot.c commands/cat.c
 	\
 	disk/raid.c disk/raid5_recover.c disk/raid6_recover.c		\
 	disk/mdraid_linux.c disk/dmraid_nvidia.c disk/lvm.c		\
-	grub_emu_init.c
+	grub_emu_init.c lib/datetime.c
 
 grub_emu_LDFLAGS = $(LIBCURSES)
 
@@ -127,7 +127,7 @@ normal_mod_SOURCES = normal/arg.c normal/cmdline.c
 	normal/menu_viewer.c normal/menu_entry.c			\
 	normal/misc.c grub_script.tab.c \
 	normal/script.c			\
-	normal/i386/setjmp.S
+	normal/i386/setjmp.S lib/datetime.c
 normal_mod_CFLAGS = $(COMMON_CFLAGS)
 normal_mod_ASFLAGS = $(COMMON_ASFLAGS)
 normal_mod_LDFLAGS = $(COMMON_LDFLAGS)
Index: conf/i386-efi.rmk
===
--- conf/i386-efi.rmk	(revision 1989)
+++ conf/i386-efi.rmk	(working copy)
@@ -64,7 +64,7 @@ grub_emu_SOURCES = commands/boot.c commands/cat.c
 	\
 	disk/raid.c disk/raid5_recover.c disk/raid6_recover.c		\
 	disk/mdraid_linux.c disk/dmraid_nvidia.c disk/lvm.c		\
-	grub_emu_init.c
+	grub_emu_init.c lib/datetime.c
 
 grub_emu_LDFLAGS = $(LIBCURSES)
 
@@ -124,7 +124,7 @@ normal_mod_SOURCES = normal/arg.c normal/cmdline.c
 	normal/menu_viewer.c normal/menu_entry.c			\
 	normal/misc.c grub_script.tab.c \
 	normal/script.c			\
-	normal/i386/setjmp.S
+	normal/i386/setjmp.S lib/datetime.c
 normal_mod_CFLAGS = $(COMMON_CFLAGS)
 normal_mod_ASFLAGS = $(COMMON_ASFLAGS)
 normal_mod_LDFLAGS = $(COMMON_LDFLAGS)
Index: conf/i386-ieee1275.rmk
===
--- conf/i386-ieee1275.rmk	(revision 1989)
+++ conf/i386-ieee1275.rmk	(working copy)
@@ -117,8 +117,8 @@ normal_mod_SOURCES = normal/arg.c normal/cmdline.c
 	normal/menu_viewer.c normal/menu_entry.c			\
 	normal/misc.c grub_script.tab.c \
 	normal/script.c			\
-	normal/i386/setjmp.S
+	normal/i386/setjmp.S lib/datetime.c
 normal_mod_CFLAGS = $(COMMON_CFLAGS)
 normal_mod_ASFLAGS = $(COMMON_ASFLAGS)
 normal_mod_LDFLAGS = $(COMMON_LDFLAGS)
 
Index: conf/i386-pc.rmk
===
--- conf/i386-pc.rmk	(revision 1989)
+++ conf/i386-pc.rmk	(working copy)
@@ -145,8 +145,7 @@ grub_emu_SOURCES = commands/boot.c commands/cat.c
 	\
 	disk/raid.c disk/raid5_recover.c disk/raid6_recover.c		\
 	disk/mdraid_linux.c disk/dmraid_nvidia.c disk/lvm.c		\
-	grub_emu_init.c
-
+	grub_emu_init.c lib/datetime.c
 grub_emu_LDFLAGS = $(LIBCURSES) 
 
 ifeq ($(enable_grub_emu_usb), yes)
Index: conf/powerpc-ieee1275.rmk
===
--- conf/powerpc-ieee1275.rmk	(revision 1989)
+++ conf/powerpc-ieee1275.rmk	(working copy)
@@ -69,7 +69,7 @@ grub_emu_SOURCES = commands/boot.c commands/cat.c
 	\
 	disk/raid.c disk/raid5_recover.c disk/raid6_recover.c		\
 	disk/mdraid_linux.c disk/dmraid_nvidia.c disk/lvm.c		\
-	grub_script.tab.c grub_emu_init.c
+	grub_script.tab.c grub_emu_init.c lib/datetime.c
 
 grub_emu_LDFLAGS = $(LIBCURSES)
 
@@ -137,7 +137,7 @@ normal_mod_SOURCES = normal/arg.c normal/cmdline.c
 	normal/menu_viewer.c normal/menu_entry.c			\
 	normal/misc.c grub_script.tab.c \
 	normal/script.c			\
-	normal/powerpc/setjmp.S
+	normal/powerpc/setjmp.S lib/datetime.c
 normal_mod_CFLAGS = $(COMMON_CFLAGS)
 normal_mod_ASFLAGS = $(COMMON_ASFLAGS)
 normal_mod_LDFLAGS = $(COMMON_LDFLAGS)
Index: conf/sparc64-ieee1275.rmk
===
--- conf/sparc64-ieee1275.rmk	(revision 1989)
+++ conf/sparc64-ieee1275.rmk	(working copy)
@@ -64,7 +64,7 @@ grub_mkimage_SOURCES = util/sparc64/ieee1275/grub-
 #	partmap/acorn.c			\
 #	util/console.c util/grub-emu.c util/misc.c			\
 #	util/hostdisk.c util/getroot.c	\
-#	util/sparc64/ieee1275/misc.c
+#	util/sparc64/ieee1275/misc.c lib/datetime.c
 
 grub_emu_LDFLAGS = $(LIBCURSES)
 
@@ -170,7 +170,7 @@ normal_mod_SOURCES = normal/arg.c normal/cmdline.c
 	normal/menu_viewer.c normal/menu_entry.c			\
 	normal/misc.c grub_script.tab.c \
 	normal/script.c			\
-	normal/sparc64/setjmp.S
+	normal/sparc64/setjmp.S lib/datetime.c
 normal_mod_CFLAGS = $(COM

Re: [PATCH] mtime support

[phcoder]

Made corrections to issues pointed by Vesa Jääskeläinen
Regards
Vladimir 'phcoder' Serbinenko

phcoder wrote:
Hello. Here is the patch to support mtime. This is a prerequisite for 
-nt test which can be very useful for e.g. finding last compiled kernel

Also in the same time it makes the dir call easily extendable

Regards
Vladimir 'phcoder' Serbinenko



Index: conf/common.rmk
===
Index: conf/i386-coreboot.rmk
===
--- conf/i386-coreboot.rmk	(revision 1989)
+++ conf/i386-coreboot.rmk	(working copy)
@@ -75,7 +75,7 @@
 	kern/loader.c kern/main.c kern/misc.c kern/parser.c		\
 	grub_script.tab.c kern/partition.c kern/rescue.c kern/term.c	\
 	normal/arg.c normal/cmdline.c normal/command.c normal/function.c\
-	normal/completion.c normal/main.c\
+	normal/completion.c normal/datetime.c normal/main.c		\
 	normal/menu.c normal/menu_entry.c normal/menu_viewer.c		\
 	normal/misc.c normal/script.c	\
 	normal/color.c			\
@@ -121,7 +121,7 @@
 # keep it simpler to update to different architectures.
 #
 normal_mod_SOURCES = normal/arg.c normal/cmdline.c normal/command.c	\
-	normal/completion.c normal/execute.c		 		\
+	normal/completion.c normal/datetime.c normal/execute.c		\
 	normal/function.c normal/lexer.c normal/main.c normal/menu.c	\
 	normal/color.c			\
 	normal/menu_viewer.c normal/menu_entry.c			\
Index: conf/i386-efi.rmk
===
--- conf/i386-efi.rmk	(revision 1989)
+++ conf/i386-efi.rmk	(working copy)
@@ -52,7 +52,8 @@
 	kern/loader.c kern/main.c kern/misc.c kern/parser.c		\
 	grub_script.tab.c kern/partition.c kern/rescue.c kern/term.c	\
 	normal/arg.c normal/cmdline.c normal/command.c normal/function.c\
-	normal/completion.c normal/context.c normal/main.c		\
+	normal/completion.c normal/datetime.c normal/context.c 		\
+	normal/main.c		\
 	normal/menu.c normal/menu_entry.c normal/menu_viewer.c		\
 	normal/misc.c normal/script.c	\
 	normal/color.c			\
@@ -118,9 +119,9 @@
 # keep it simpler to update to different architectures.
 #
 normal_mod_SOURCES = normal/arg.c normal/cmdline.c normal/command.c	\
-	normal/completion.c normal/execute.c		 		\
+	normal/completion.c normal/datetime.c normal/execute.c 		\
 	normal/function.c normal/lexer.c normal/main.c normal/menu.c	\
 	normal/color.c			\
 	normal/menu_viewer.c normal/menu_entry.c			\
 	normal/misc.c grub_script.tab.c \
 	normal/script.c			\
	normal/i386/setjmp.S
 normal_mod_CFLAGS = $(COMMON_CFLAGS)
 normal_mod_ASFLAGS = $(COMMON_ASFLAGS)
 normal_mod_LDFLAGS = $(COMMON_LDFLAGS)
@@ -175,7 +176,7 @@
 lspci_mod_LDFLAGS = $(COMMON_LDFLAGS)
 
 # For datetime.mod
-datetime_mod_SOURCES = lib/datetime.c lib/efi/datetime.c
+datetime_mod_SOURCES = lib/efi/datetime.c
 datetime_mod_CFLAGS = $(COMMON_CFLAGS)
 datetime_mod_LDFLAGS = $(COMMON_LDFLAGS)
 
Index: conf/i386-ieee1275.rmk
===
--- conf/i386-ieee1275.rmk	(revision 1989)
+++ conf/i386-ieee1275.rmk	(working copy)
@@ -74,7 +74,7 @@
 	kern/loader.c kern/main.c kern/misc.c kern/parser.c		\
 	grub_script.tab.c kern/partition.c kern/rescue.c kern/term.c	\
 	normal/arg.c normal/cmdline.c normal/command.c normal/function.c\
-	normal/completion.c normal/main.c\
+	normal/completion.c normal/datetime.c normal/main.c		\
 	normal/menu.c normal/menu_entry.c normal/menu_viewer.c		\
 	normal/misc.c normal/script.c	\
 	normal/color.c			\
@@ -111,7 +111,7 @@
 # keep it simpler to update to different architectures.
 #
 normal_mod_SOURCES = normal/arg.c normal/cmdline.c normal/command.c	\
-	normal/completion.c normal/execute.c		 		\
+	normal/completion.c normal/datetime.c normal/execute.c 		\
 	normal/function.c normal/lexer.c normal/main.c normal/menu.c	\
 	normal/color.c			\
 	normal/menu_viewer.c normal/menu_entry.c			\
@@ -190,7 +192,7 @@
 lspci_mod_LDFLAGS = $(COMMON_LDFLAGS)
 
 # For datetime.mod
-datetime_mod_SOURCES = lib/datetime.c lib/i386/datetime.c
+datetime_mod_SOURCES = lib/i386/datetime.c
 datetime_mod_CFLAGS = $(COMMON_CFLAGS)
 datetime_mod_LDFLAGS = $(COMMON_LDFLAGS)
 
Index: conf/i386-pc.rmk
===
--- conf/i386-pc.rmk	(revision 1989)
+++ conf/i386-pc.rmk	(working copy)
@@ -128,7 +128,8 @@
 	kern/loader.c kern/main.c kern/misc.c kern/parser.c		\
 	grub_script.tab.c kern/partition.c kern/rescue.c kern/term.c	\
 	normal/arg.c normal/cmdline.c normal/command.c normal/function.c\
-	normal/completion.c normal/main.c normal/color.c		\
+	normal/completion.c normal/datetime.c normal/main.c 		\
+	normal/color.c		\
 	normal/menu.c normal/menu_entry.c normal/menu_viewer.c		\
 	normal/misc.c normal/script.c	\
 	partmap/amiga.c	partmap/apple.c partmap/pc.c partmap/sun.c	\
@@ -208,7 +228,7 @@
 # keep it simpler to update to different architectures.
 #

Re: [PATCH] Allow to install in non-default prefixes

[phcoder]

Here I attach updated version
Regards
Vladimir 'phcoder' Serbinenko
phcoder wrote:

Sorry, Changelog entry was wrong:
+2009-02-04  Vladimir Serbinenko  
+
+Add prefix option for grub-setup
+
+* util/i386/pc/grub-setup.c (main): Add -p option.
+(setup): additional argument prefix_dir

Thanks
Vladimir 'phcoder' Serbinenko

phcoder wrote:
After speaking with daChaac on IRC some problems with patch were 
identified. Fixed now

Thanks daChaac.
phcoder

phcoder wrote:
This patch adds -p option for grub-setup on i386-pc. Without it 
install to any prefix different from /boot/grub failed

Thank
Vladimir 'phcoder' Serbinenko







Index: util/i386/pc/grub-install.in
===
--- util/i386/pc/grub-install.in(revision 1989)
+++ util/i386/pc/grub-install.in(working copy)
@@ -295,7 +295,7 @@
 $grub_mkimage --output=${grubdir}/core.img 
--prefix=${prefix_drive}${relative_grubdir} $modules || exit 1
 
 # Now perform the installation.
-$grub_setup ${setup_verbose} --directory=${grubdir} 
--device-map=${device_map} \
+$grub_setup ${setup_verbose} --directory=${grubdir} 
--prefix=${relative_grubdir} --device-map=${device_map} \
 ${install_device} || exit 1
 else
 $grub_mkimage -d ${pkglibdir} --output=/boot/multiboot.img 
--prefix=${prefix_drive}${relative_grubdir} $modules || exit 1
Index: util/i386/pc/grub-setup.c
===
--- util/i386/pc/grub-setup.c   (revision 1989)
+++ util/i386/pc/grub-setup.c   (working copy)
@@ -94,6 +94,7 @@
 
 static void
 setup (const char *dir,
+   const char *prefix_dir,
const char *boot_file, const char *core_file,
const char *root, const char *dest, int must_embed)
 {
@@ -373,7 +374,7 @@
   
   /* Make sure that GRUB reads the identical image as the OS.  */
   tmp_img = xmalloc (core_size);
-  core_path_dev = grub_util_get_path (DEFAULT_DIRECTORY, core_file);
+  core_path_dev = grub_util_get_path (prefix_dir, core_file);
   
   /* It is a Good Thing to sync two times.  */
   sync ();
@@ -518,6 +519,7 @@
 {"core-image", required_argument, 0, 'c'},
 {"directory", required_argument, 0, 'd'},
 {"device-map", required_argument, 0, 'm'},
+{"prefix", required_argument, 0, 'p'},
 {"root-device", required_argument, 0, 'r'},
 {"help", no_argument, 0, 'h'},
 {"version", no_argument, 0, 'V'},
@@ -540,6 +542,7 @@
   -b, --boot-image=FILE   use FILE as the boot image [default=%s]\n\
   -c, --core-image=FILE   use FILE as the core image [default=%s]\n\
   -d, --directory=DIR use GRUB files in the directory DIR [default=%s]\n\
+  -p, --prefix=DIRspecify the name of GRUB directory relative to 
partition root [default=%s]\n \
   -m, --device-map=FILE   use FILE as the device map [default=%s]\n\
   -r, --root-device=DEV   use DEV as the root device [default=guessed]\n\
   -h, --help  display this message and exit\n\
@@ -548,7 +551,8 @@
 \n\
 Report bugs to <%s>.\n\
 ",
-   DEFAULT_BOOT_FILE, DEFAULT_CORE_FILE, DEFAULT_DIRECTORY,
+   DEFAULT_BOOT_FILE, DEFAULT_CORE_FILE, DEFAULT_DIRECTORY, 
+   DEFAULT_DIRECTORY,
DEFAULT_DEVICE_MAP, PACKAGE_BUGREPORT);
 
   exit (status);
@@ -575,6 +579,7 @@
   char *dev_map = 0;
   char *root_dev = 0;
   char *dest_dev;
+  char *prefix_dir = 0;
   int must_embed = 0;
   
   progname = "grub-setup";
@@ -582,7 +587,7 @@
   /* Check for options.  */
   while (1)
 {
-  int c = getopt_long (argc, argv, "b:c:d:m:r:hVv", options, 0);
+  int c = getopt_long (argc, argv, "p:b:c:d:m:r:hVv", options, 0);
 
   if (c == -1)
break;
@@ -603,6 +608,13 @@
core_file = xstrdup (optarg);
break;
 
+ case 'p':
+   if (prefix_dir)
+ free (prefix_dir);
+
+   prefix_dir = xstrdup (optarg);
+   break;
+
  case 'd':
if (dir)
  free (dir);
@@ -723,6 +735,7 @@
   for (i = 0; devicelist[i]; i++)
{
  setup (dir ? : DEFAULT_DIRECTORY,
+prefix_dir ? : DEFAULT_DIRECTORY,
 boot_file ? : DEFAULT_BOOT_FILE,
 core_file ? : DEFAULT_CORE_FILE,
 root_dev, grub_util_get_grub_dev (devicelist[i]), 1);
@@ -732,6 +745,7 @@
 #endif
   /* Do the real work.  */
 setup (dir ? : DEFAULT_DIRECTORY,
+  prefix_dir ? : DEFAULT_DIRECTORY,
   boot_file ? : DEFAULT_BOOT_FILE,
   core_file ? : DEFAULT_CORE_FILE,
   root_dev, dest_dev, must_embed);
@@ -743,6 +757,7 @@
   free (boot_file);
   free (core_file);
   free (dir);
+  free (prefix_dir);
   free (dev_map);
   free (root_dev);
   

Re: Where?

[phcoder]

./configure:577:PACKAGE_VERSION='1.96'
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 it.


Thanks,
Pat






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

Test command

[phcoder]

Hello. Here is an implementation of bash-like "test" command. Many file 
tests are omitted because they are useless in grub (e.g. -c test). I 
also added 3 extension: lexicographical comparing, prefixed -gt and -lt 
(it skips common prefix. Useful for comparing versions. e.g. [ vmlinuz-3 
-plt vmlinuz-11 ] is true) and biased -nt/-ot which adds s specified 
amount of seconds to mtime.

Regards
Vladimir 'phcoder' Serbinenko


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

[PATCH] Test command

[phcoder]

Sorry forgot to attach the file
phcoder wrote:
Hello. Here is an implementation of bash-like "test" command. Many file 
tests are omitted because they are useless in grub (e.g. -c test). I 
also added 3 extension: lexicographical comparing, prefixed -gt and -lt 
(it skips common prefix. Useful for comparing versions. e.g. [ vmlinuz-3 
-plt vmlinuz-11 ] is true) and biased -nt/-ot which adds s specified 
amount of seconds to mtime.

Regards
Vladimir 'phcoder' Serbinenko


Index: commands/test.c
===
--- commands/test.c	(revision 1989)
+++ commands/test.c	(working copy)
@@ -23,33 +23,385 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
+/* A simple implementation for signed numbers*/
+static int
+grub_strtosl (char *arg, char **end, int base)
+{
+  if (arg[0] == '-')
+return -grub_strtoul (arg + 1, end, base);
+  return grub_strtoul (arg, end, base);
+}
+
+/* Parse a test expression startion from *argn*/
+static int
+test_parse (char **args, int *argn, int argc)
+{
+  int ret = 0, discard = 0, invert = 0;
+  int file_exists;
+  struct grub_dirhook_info file_info;
+
+  auto void update_val (int val);
+  auto void get_fileinfo (char *pathname);
+
+  /*Take care of discarding and inverting*/
+  void update_val (int val)
+  {
+if (!discard)
+  ret = invert ? !val : val;
+invert = discard = 0;
+  }
+
+  /* Check if file exists and fetch its information */
+  void get_fileinfo (char *pathname)
+  {
+char *filename, *path;
+char *device_name;
+grub_fs_t fs;
+grub_device_t dev;
+
+/* A hook for iterating directories */
+auto int find_file (const char *cur_filename, 
+			struct grub_dirhook_info info);
+int find_file (const char *cur_filename, struct grub_dirhook_info info)
+{
+  if (info.case_insensitive ? !grub_strcasecmp (cur_filename, filename)
+	  :!grub_strcmp (cur_filename, filename))
+	{
+	  file_info = info;
+	  file_exists = 1;
+	  return 1;
+	}
+  return 0;
+}
+
+
+file_exists = 0;
+device_name = grub_file_get_device_name (pathname);
+dev = grub_device_open (device_name);
+if (! dev)
+  {
+	grub_free (device_name);
+	return;
+  }
+
+fs = grub_fs_probe (dev);
+path = grub_strchr (pathname, ')');
+if (! path)
+  path = pathname;
+else
+  path++;
+
+/* Remove trailing / */
+while (*pathname && pathname[grub_strlen (pathname) - 1] == '/')
+  pathname[grub_strlen (pathname) - 1] = 0;
+
+/* Split into path and filename*/
+filename = grub_strrchr (pathname, '/');
+if (!filename)
+  {
+	path = grub_strdup ("/");
+	filename = pathname;
+  }
+else
+  {
+	filename++;
+	path = grub_strdup (pathname);
+	path[filename - pathname] = 0;
+  }
+
+/* It's the whole device*/
+if (!*pathname)
+  {
+	file_exists = 1;
+	grub_memset (&file_info, 0, sizeof (file_info));
+	/* Root is always a directory */
+	file_info.dir = 1;
+
+	/* Fetch writing time */
+	file_info.mtimeset = 0;
+	if (fs->mtime)
+	  {
+	if (! fs->mtime (dev, &file_info.mtime))
+	  file_info.mtimeset = 1;
+	grub_errno = GRUB_ERR_NONE;
+	  }
+  }
+else
+  (fs->dir) (dev, path, find_file);
+
+grub_device_close (dev); 
+grub_free (path);
+grub_free (device_name);
+  }
+
+  /* Here we have the real parsing */
+  while (*argn < argc)
+{
+  /* First try 3 argument tests */
+  /* String tests */
+  if (*argn + 2 < argc && (!grub_strcmp (args[*argn + 1], "=")
+			   || !grub_strcmp (args[*argn + 1], "==")))
+	{
+	  update_val (grub_strcmp (args[*argn], args[*argn + 2]) == 0);
+	  (*argn) += 3;
+	  continue;
+	}
+
+  if (*argn + 2 < argc && !grub_strcmp (args[*argn + 1], "!="))
+	{
+	  update_val (grub_strcmp (args[*argn], args[*argn + 2]) != 0);
+	  (*argn) += 3;
+	  continue;
+	}
+
+  /* GRUB extension: lexicographical sorting */
+  if (*argn + 2 < argc && !grub_strcmp (args[*argn + 1], "<"))
+	{
+	  update_val (grub_strcmp (args[*argn], args[*argn + 2]) < 0);
+	  (*argn) += 3;
+	  continue;
+	}
+
+  if (*argn + 2 < argc && !grub_strcmp (args[*argn + 1], "<="))
+	{
+	  update_val (grub_strcmp (args[*argn], args[*argn + 2]) <= 0);
+	  (*argn) += 3;
+	  continue;
+	}
+
+  if (*argn + 2 < argc && !grub_strcmp (args[*argn + 1], ">"))
+	{
+	  update_val (grub_strcmp (args[*argn], args[*argn + 2]) > 0);
+	  (*argn) += 3;
+	  continue;
+	}
+
+  if (*argn + 2 < argc && !grub_strcmp (args[*argn + 1], ">="))
+	{
+	  update_val (grub_strcmp (args[*argn], args[*argn + 2]) >= 0);
+	  (*argn) += 3;
+	  continue;
+	}
+
+  /* Number tests */
+  if (*argn + 2 < argc && !grub_strc

Design: partitions in partitions

[phcoder]

Hello I would like to implement partition in partitions support (it's on 
the TODO list) and necessary as a pre-requisite to access solaris' zfs 
partitions. I would also like to integrate current bsd partition support 
to it. I propose the following design:

Unified naming scheme: purely numerical. It means that
(hd0,1,a) becomes (hd0,1,1)

get_name is removed from grub_partition_map

Unlimited depth support. It means that partitions like
fdisk in sun in apple in gpt will be detected (silly but is 
theoretically possible)
Partitions describing whole parent partition or laying outside of parent 
partition will be filtered

An arbitrary limit may be put to avoid endless loop

Add pointer to struct grub_disk * in struct grub_partition.
Then the prototypes in grub_partition_map are:
  /* Call HOOK with each partition, until HOOK returns non-zero.  */
  grub_err_t (*iterate) (grub_partition_t parent,
 int (*hook) (struct grub_disk *disk,
  const grub_partition_t partition));

  /* Return the partition NUM on the partition PARENT.  */
  grub_partition_t (*probe) (grub_partition_t parent,
 int num);

For the first level a fake grub_partition_t describing the whole disk 
will be created


What do you think about such a design?
Regards
Vladimir 'phcoder' Serbinenko


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

Bugfix: ata pass-through broke compilation

[phcoder]

Hello. Here is bugfix
Regards
Vladimir 'phcoder' Serbinenko
Index: kern/disk.c
===
--- kern/disk.c (revision 1994)
+++ kern/disk.c (working copy)
@@ -47,7 +47,7 @@
 int grub_disk_firmware_is_tainted;
 
 grub_err_t (* grub_disk_ata_pass_through) (grub_disk_t,
-   struct grub_ata_pass_through_cmd *);
+   struct grub_disk_ata_pass_through_parms *);
 
 
 #if 0
Index: ChangeLog
===
--- ChangeLog   (revision 1994)
+++ ChangeLog   (working copy)
@@ -1,3 +1,120 @@
+2009-02-13  Vladimir Serbinenko  
+
+   Corrected wrong declaration
+
+   * kern/disk.c: corrected declaration of grub_disk_ata_pass_through
+   
 2009-02-14  Christian Franke  
 
* gendistlist.sh: Ignore `.svn' directories.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

grub_machine_fini on efi systems

[phcoder]

Hello. I found a serious problem which may be the cause of linux not 
booting on some efi systems. grub_machine_fini is called before 
grub_linux_boot. grub_machine_fini returns all memory allocated by grub2 
to efi. This includes all memory used to load modules. So actually efi 
can rightfully destroy linux module before it has slightest chance to do 
its job. I asked step21 to declare linux boot as returnable to stop 
grub_machine_fini. However it's nothing more then a workaround. I hope 
that someone will find a way to fix this nicely because for the moment I 
see none. (perhaps tomorrow I'll find sth)

Regards
Vladimir 'phcoder' Serbinenko


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

Re: grub_machine_fini on efi systems

[phcoder]

Remark 1: when loading OS grub has to call grub_efi_exit_boot_services 
which unloads efi nearly completely. On the other hand it shouldn't be 
called when returning with exit command. Perhaps we should split 
grub_machine_fini in two: one for preparing for OS and other for 
exiting. But then when one chainloads then grub_efi_exit_boot_services 
shouldn't be called. So I propose that loader function should cope with 
environment preparation. For cases when some preparation is needed 
independently of the type of loaded os (like setting 'map' hook) the 
best solution IMO would be preboot hooks.
Remark 2: it should be clearly stated somewhere what the boot function 
may and may not use (e.g. boot function isn't allowed to read from disk, 
boot function may use grub_printf but not and so on) so that boot 
function conflicts neither with grub_machine_fini nor with preboot hooks
Remark 3: in case of an error the non-returning boot function may 
return. I see 3 possible solution:

a) forbid such an action. Use grub_fatal if really necessary
b) loader should call a special function at point of noreturn
c) delete the separation between returnable and not returnable booters. 
 grub_machine_prepare_for_os and preboot_hooks in my proposition patch 
would then be extended with second function which is called upon the 
return to undo the action of the hook itself

Regards
Vladimir 'phcoder' Serbinenko
phcoder wrote:
Hello. I found a serious problem which may be the cause of linux not 
booting on some efi systems. grub_machine_fini is called before 
grub_linux_boot. grub_machine_fini returns all memory allocated by grub2 
to efi. This includes all memory used to load modules. So actually efi 
can rightfully destroy linux module before it has slightest chance to do 
its job. I asked step21 to declare linux boot as returnable to stop 
grub_machine_fini. However it's nothing more then a workaround. I hope 
that someone will find a way to fix this nicely because for the moment I 
see none. (perhaps tomorrow I'll find sth)

Regards
Vladimir 'phcoder' Serbinenko




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

Re: Booting Xen dom0 with Grub2

[phcoder]

Hello. multiboot implementation of grub2 isn't complete yet. This is one 
possible reason. Can you supply us with the output of displaymem under 
grub1 and of lsmmap under grub2

Regards
Vladimir 'phcoder' Serbinenko
Emmanuel Jeanvoine wrote:

Hi all,

I try to boot a Xen dom0 with grub2 on a Lenny box and it doesn't work.
After a few seconds of booting, the following message appears :
"Panic on CPU0:
 Cannot access memory beyond end of bootstrap direct-map area"

I tried with Grub-legacy and all works fine.

Here is the grub.cfg entry:
menuentry "Xen 3.2-1-i386 / Debian GNU/Linux, kernel 2.6.26-1-xen-686" {
  set root=(hd0,1)
  multiboot /boot/xen-3.2-1-i386.gz
  module /boot/vmlinuz-2.6.26-1-686 root=/dev/hda1 ro
console=tty0
   module /boot/initrd.img-2.6.26-1-686
}


Do you have an idea ?

Thanks,

Emmanuel Jeanvoine.


___
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

[phcoder]

I don't know much about TPM but from example that I read at 
TreacherousGrub website actual verification is done by TreachorousGrub. 
I don't see how such a verification can protect against anything.
If you suppose that your attacker is unable to tamper the hardware then 
bios and grub password is all you need. If you suppose that he can then 
you can't even trust your ram modules. It can be tampered in many ways 
like serving hacked bootloader or just being non-volatile then an 
attacker can read the key from memory.
FSF acknowledges that treacherouscomputing may offer minor advantages 
but dissmisses the technology as whole and I agree with them.

However, I'm neither a grub maintainer nor fsf representative.
Regards
Vladimir 'phcoder' Serbinenko
Alex Besogonov wrote:

I know that TPM has been mentioned several times on this list. With
absolutely inadequate knee-jerk reactions from GRUB developers :(

Currently I have a problem - I need to protect confidential private
data (we try to protect privacy of our customers) from the _physical_
theft of the server. A simple full hard drive encryption should work
just fine except for one small detail - there's nobody to enter the
password when server reboots.

I've solved this by adding an intermediate system which connects to
another server (which I consider physically secure), retrieves
decryption key and does kexec into the real OS passing this key as a
parameter. So I can just delete the key from the secure server to stop
the physically insecure sever from booting, it'll then be useless for
attackers since there's no decryption key present on it.

However, it would be fairly trivial for attacker to steal the server
and/or make a full copy of its hard drive and then modify intermediate
system to print the decryption key. Not good. And there's no way to
solve it in software, since attacker can trivially change the
bootloader.

So I've added another layer of security - I use TPM to remotely attest
that the bootloader and the intermediate system is not modified. It
requires chain of trust from BIOS to the intermediate system. So if
attacker tries to modify bootloader or intermediate system image - TPM
will not provide keys for communication with the secure server.

Please note, that if TPM chip is blocked/kicked/de-soldered/sacrificed
to GNU gods then I can still retrieve all data because the main
decryption key is NOT kept in the TPM module (TPM is only used to
attest integrity of the system). Also, this is not a DRM scheme.

So... Why not add TPM patches into the mainline GRUB2 project? GPLv3
protects nicely against the possible DRM misuse of GRUB2 and TPM. Also
I can assist in forward-porting of 'Trusted GRUB' patch.


___
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

[phcoder]

First of all your system is still totally vulnerable to emanation and 
power analysis or hw tampering. By reflashing bios one can bypass all 
tpm protections (don't say it's difficult because it's closed source and 
so on. Look at all closed source obfuscations/pseudo-protections that 
get cracked every day)
Personally if tpm support is merged into mainline grub2 I'll stop using 
it. However what you request doesn't need tpm. Authenticity of modules, 
configuration files and so on can be verified by one of 4 methods:

1) internal signatures
2) file in signed gpg container
3) detached signatures
4) signed hash file
First three goals can be achieved by adding a layer similar to gzio
behaviour of checking can be controlled by environment variables and 
flags passed to

grub_signed_file_open (filename, flags);
First advantage is that you can override it manually supplying grub password
When signature module isn't loaded then this function is available as a 
dummy (all files are unsigned/wrong signature).
Public key can be embedded in signature module. When loaded signature 
module sets strict signing policy which can be then overriden by 
variable (to set such a variable you need either password or a command 
in signed grub.cfg)
Then these modules can be embedded in core.img. In this case if core.img 
is untampered everything is verified. Ensuring integrity of core.img is 
platform-dependent. Some platforms (openfirmware, efi, ...) load 
core.img directly and if they have an ability to check the boot image 
it's straightforward. I haven't thought yet how to do it in limited 
space of mbr. In coreboot scenario it's even the best bet. You can put 
grub2 in rom and if you use rom instead of flashrom it's a wonderful 
solution. But even if you use flash rom your security is similar to 
scenario you propose  since as I said at the begining modyfiing flash 
bios you can bypass tpm scenario

Advantage of this approach is the ability to safely update over network
Forth goal can be achieved with usage of first part and function similar 
to sha1sum or whirlpoolsum (my prefered hash)
Another idea: for some partitions (e.g. system partitions) signatures or 
mac can be much better. btrfs supports checksumming of data and 
metadata. Add mac support is easy. Signatures are more delicate I'm 
looking for compact and fast signatures.
I personally would be interested in implementing security features in 
grub2 as long as tpm stays away


Regards
Vladimir 'phcoder' Serbinenko
Alex Besogonov wrote:

On Wed, Feb 18, 2009 at 11:05 PM, Jan Alsenz  wrote:

I've recently started porting TrustedGRUB (
http://sourceforge.net/projects/trustedgrub ) to GRUB2.
I didn't get too far as I don't have too much time right now, but I managed to
complete the MBR bootloader.

Great! MBR is the most scary part :)


I agree with you on the usefulness of a TPM for disk encryption and have a
similar scheme planned.
Regardless of the outcome of the discussion on the mailing list I would be
interested in a "trusted" GRUB2 version. Maybe we could join forces?

Absolutely. I just hate doing work that won't appear in the mainline version :(


BTW, the "manufacturer key" everyone is talking about is usually referred to as
"endorsement key", which is generated during production (and whose private part
is considered possibly in the possession of the manufacturer). I heard, that
some newer TPM versions support reinitializing this key, but I'm not sure of
that.

Uhm... TPM_CreateEndorsementKeyPair can be used to create the
endorsement key pair, and the spec also says that TPM chip _must_ ship
with empty endorsement key. It also can later be changed.


And you do loose the ability to do remote attestation with "official"
entities, if you do it.

Well, I don't care about that. And in any case, no-one uses TPM for
'official' purposes.


___
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

[phcoder]

The hard part is initializing the hardware without the use of the
original BIOS - the specifics of initializing various chips are not
public, and probably depend on companion hardware and/or trace length
on the particular board as well.
It's not actually needed. If one can nop tpm code in bios then he can 
boot from anything and read tpm keys. You don't need to understand the 
whole bios to do it. Of course it's obfuscated but obfuscation isn't a 
security in any way. Also if you write completely different code to 
flash bios you don't need to be able to initialise the whole hardware 
all you need is being able to read tpm and write to serial port. Then 
you can simply read the key at your serial console. Actually bios isn't 
protected. It's just obfuscated.

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

[phcoder]

As I understand from his letters and from a quick look at tgrub all he 
needs is to ensure the chain of verification. It seems that tgrub never 
reads tpm key. Even if we one finds tpm acceptable way to check OS 
integrity I don't see why we would rely on it if more universal approach 
is possible
I outlined how it can be checked that if core.img is untampered then OS 
isn't tampered with. I also think I might have a way to extend this 
chain back to mbr by using following ideas:
1) padding in sha1 isn't necessarry in this case since we always load 
fixed amount of sectors.
2) BPB blocks can be reclaimed. If grub boot is in partition then mbr 
may haven't checked it
3) only one read is necessary in first sector. All real reading function 
can be moved to loaded sector. So only sha1 implementation is really 
needed to be done in mbr.
4) I find it very important that the verification can be overriden by 
manually giving password. This probably won't be possible so I propose 
to make 2 mbrs: one with all features current mbr has (the default one) 
and another basic one (e.g. no chs) but with sha1 in it. Default to use 
is the first one but a user may explicitely override it



1. The disk must be encrypted.
2. The system must be able to boot without human interaction.  That is,
   a user cannot be prompted for a passphrase or key.
The both goals together are theoretically unachievable technics like 
replacing ram (or gpu memory) with non-volatile storage is always 
available or the method of additional energy. All tpm does is to store 
it in obfuscated way and providing access to it in clear way if some 
conditions are met.

Ideally this condition is B="my system is untampered"
BIOS has the duty to verify the condition A="mbr is untampered"

So actually what he needs is that grub ensures (A=>B)
Intermediary condition is "core.img" is untampered. I already outlined 
how to ensure C=>B without any sacrifices. Ensuring A=>C may require 
some sacrifices that's why I propose to have two versions of mbr sector.
I find that the feature A=>B / C=>B is useful also in many ways not 
limited to tpm scenarios. Look at the following case:
One has installed grub locally on small disk or in flash memory (e.g. 
coreboot) in otherwise lightweight terminal. Now he wants to boot the OS 
from remote server over unsecure network.


In the same time he can always choose to boot unsigned OS by providing 
his password

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

[phcoder]

Alex Besogonov wrote:

First of all your system is still totally vulnerable to emanation and
power analysis or hw tampering.

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

And what about cache attack?


By reflashing bios one can bypass all
tpm protections (don't say it's difficult because it's closed source and
so on. Look at all closed source obfuscations/pseudo-protections that
get cracked every day)

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"



Personally if tpm support is merged into mainline grub2 I'll stop using
it.

Why?
Because I don't want support this technology. 
TPM=obfuscation=unsecurity. 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

Won't work.

For example, attacker can run everything inside a hypervisor and then
just dump memory and extract decryption keys. You have no reliable
ways to detect hypervisor from inside the running OS. You can pile
layers upon layers of integrity checks, but they are useless if
hardware itself is not trusted.  TPM allows me to establish this
trust.
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. 
Actually you can trust tpm only as much as you trust in obfuscation 
power of bios. Only obfuscation prevents attacker from disconnecting tpm 
and reading keys from it. And there are only few types of tpm. Sooner or 
later someone will figure their interface. Then it can be read by 
special usb adapter


Actually, I can probably even formally prove this assumption.

I really don't see you point. With my proposition mbr still can be 
verified by tpm but grub2 needs to know nothing about tpm as long as it 
ensures it doesn't load any unsigned modules. This approach is more 
versatile. It can be used also for e.g. checking that debian install is 
really from debian. And having experience with manufacturers supplying 
buggy hw and sw  tend to avoid solutions directly relying on hardware 
when another implementation is possible
Which collaboration other than not loading anything unchecked does your 
scheme need from grub?

From readme of trustedgrub the only thing it does is checking integrity

First advantage is that you can override it manually supplying grub password

Administrator can manually override TPM by supplying the decryption
key directly instead of fetching them from my key server.

[skipped because this scheme just won't work]


I personally would be interested in implementing security features in
grub2 as long as tpm stays away

Then that's a religion, not engineering.
Tell it what you want but I don't trust code that I can't verify. And 
tpm is root of obfuscation.


PS: please, can you CC me when you answer my posts?

Could you come to irc channel or meet me at jabber/gtalk?
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

[phcoder]

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

Regards
Vladimir 'phcoder' Serbinenko
Michael Gorven wrote:

On Friday 20 February 2009 02:29:50 Jan Alsenz wrote:

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.


Last year I implemented support for encrypted partitions in GRUB2 [1], which 
means that it can load kernels and ramdisks off encrypted partitions. TPM 
support in GRUB2 would allow the key to be stored in the TPM and only 
provided to GRUB once the system has checked that GRUB hasn't been tampered 
with.


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? TPM has the 
potential to make Linux even more secure.


Regards
Michael

[1] My work is yet to be merged into GRUB2.





___
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

SHA-1 MBR

[phcoder]

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
/* -*-Asm-*- */
/*
 *  GRUB  --  GRand Unified Bootloader
 *  Copyright (C) 2009  Free Software Foundation, Inc.
 *
 *  GRUB is free software: you can redistribute it and/or modify
 *  it under the terms of the GNU General Public License as published by
 *  the Free Software Foundation, either version 3 of the License, or
 *  (at your option) any later version.
 *
 *  GRUB is distributed in the hope that it will be useful,
 *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *  GNU General Public License for more details.
 *
 *  You should have received a copy of the GNU General Public License
 *  along with GRUB.  If not, see <http://www.gnu.org/licenses/>.
 */

/* The signature for bootloader.  */
#define GRUB_BOOT_MACHINE_SIGNATURE 0xaa55

/* The offset of a magic number used by Windows NT.  */
#define GRUB_BOOT_MACHINE_WINDOWS_NT_MAGIC  0x1b8

/* The offset of the start of the partition table.  */
#define GRUB_BOOT_MACHINE_PART_START0x1be

/* The offset of the end of the partition table.  */
#define GRUB_BOOT_MACHINE_PART_END  0x1fe

/* The stack segment.  */
#define GRUB_BOOT_MACHINE_STACK_SEG 0x2000

/* The segment of disk buffer. The disk buffer MUST be 32K long and
   cannot straddle a 64K boundary.  */
#define GRUB_BOOT_MACHINE_BUFFER_SEG0x7000

/* The flag for BIOS drive number to designate a hard disk vs. a
   floppy.  */
#define GRUB_BOOT_MACHINE_BIOS_HD_FLAG  0x80

/* The segment where the kernel is loaded.  */
#define GRUB_BOOT_MACHINE_KERNEL_SEG0x800

/* The address where the kernel is loaded.  */
#define GRUB_BOOT_MACHINE_KERNEL_ADDR   (GRUB_BOOT_MACHINE_KERNEL_SEG << 4)

/* The size of a block list used in the kernel startup code.  */
#define GRUB_BOOT_MACHINE_LIST_SIZE 12


#define ABS(x) (x-_start+0x7c00)

.code16

.globl _start; _start:
jmp real_start
stack:
packet:
.byte 0x10
.byte 0
.word 1
.word 0,GRUB_BOOT_MACHINE_KERNEL_SEG
kernel_sector:
.long   1, 0
h1:
.long 0xefcdab89
h2:
.long 0x98badcfe
h3:
.long 0x10325476
h4:
.long 0xc3d2e1f0
h0:
.long 0x67452301
real_start: 
cli
xorw%ax, %ax
movb$0x80, %dl
movw%ax, %ds
movw%ax, %es
movw%ax, %ss
mov $ABS(stack), %sp
movw%sp, %si
movb$0x42, %ah
int $0x13
add $0x10,%sp
mov ABS(byteshashed), %si
block32:
movw$GRUB_BOOT_MACHINE_KERNEL_SEG, %ax
movw%ax, %ds
incb%ah
movw%ax, %es
xor %ax,%ax
mov %ax, %di
mov $0x40, %cx
push %cx
cld
rep movsb
pop %cx
movw$(GRUB_BOOT_MACHINE_KERNEL_SEG+0x100), %ax
movw%ax, %ds
expand: 
movl -12(%di), %eax
xorl -32(%di), %eax
xorl -56(%di), %eax
xorl -64(%di), %eax
shl  $1, %eax
adc $0, %al
mov %eax, (%di)
add $4, %di
decw %cx
test %cx, %cx
jnz expand
xor %ax, %ax
mov %ax, %ds
mov %ax, %es
movb $0x14, %cl
movw %sp, %si
subw %cx, %sp
movw %sp, %di
cld
rep movsb
mov %sp, %bp
xor %ax, %ax
mov %ax, %si

main_loop:
pop %eax
pop %ebx
pop %ecx
push %ecx
push %ebx
push %eax
cmp $320, %si
je hashed64 
cmp $240, %si
jge phase4
cmp $160, %si
jge phase3
cmp $80, %si
jge phase2
phase1:
//(b&c)|(~b & d)
and %eax, %ebx
not %eax
and %ecx, %eax
or %ebx, %eax
add $0x5a827999, %eax
jmp sharedphase
phase2: 
xor %ebx, %eax
xor %ecx, %eax
add $0x6ed9eba1, %eax
jmp sharedphase
phase3:
mov %eax, %edx
and %ebx, %edx
and %ecx, %eax
and %ecx, %ebx
or %ebx, %eax
or %edx, %eax
add $0x8f1bbcdc, %eax
jmp sharedphase
phase4: 
xor %ebx, %eax
xor %ecx, %eax
add $0xca62c1d6, %eax
sharedphase:
// here we have on sta

Design: first sector of core.img

[phcoder]

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)

Regards
Vladimir 'phcoder' Serbinenko


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

Re: SHA-1 MBR

[phcoder]

Hello
Jan Alsenz wrote:

Hi!

Wow, cool work!

Thanks

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)


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.

> 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.


Greets,

Jan


Regards
Vladimir 'phcoder' Serbinenko



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

Re: SHA-1 MBR

[phcoder]

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: SHA-1 MBR

[phcoder]

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

[phcoder]

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: SHA-1 MBR

[phcoder]

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

[phcoder]

Well I don't understand you. When someone speaks about an attack on tpm 
you always consider it not-applicable in your environment. Most of them 
actually are. Like power analysis is able to recover keys in $1000 
margin. With firewire attack you can do it with $10. You can't seriously 
assume an attacker which has less then $100 budget in any application. 
Reading directly from tpm in its current state is just a matter of time. 
However you consider any attack on the scheme coreboot+grub+boot or boot 
virus protection+sha-1+grub+boot with the encryption key in flash memory 
relevant. In both of these scenarios an attacker is unable to read the 
key without a hardware tampering level comparable to the one required to 
recover the key from tpm.
TPM is dangerous and once we use it it's difficult to come back. If it 
could provide something over the two mentioned schemes then I would say 
that it's worth investigating. But as it isn't I say smash you tpm chip.


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". I 
suppose companies and engineers know that their claims are false still 
say it because their salaries depend on how well their product is sold

Regards
Vladimir 'phcoder' Serbinenko
Alex Besogonov wrote:

On Sat, Feb 21, 2009 at 3:46 PM, Robert Millan  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




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

Re: A _good_ and valid use for TPM

[phcoder]

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  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

[PATCH] efi_emu

[phcoder]

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_pnvram 
efiemu_acpi [-x ] 
efiemu_prepare
linux_efiemu 
initrd_efiemu 
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