Re: GRUB2 on OpenBSD 5.3-amd64: linking problem

Re: GRUB2 on OpenBSD 5.3-amd64: linking problem

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 13.08.2013 23:03, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 09.08.2013 15:37, Ilya Bakulin wrote:
>> Could you please help me to solve the linking problem?
>> What else do you need from me?
> Sounds like your gcc doesn't pass -m32 to linker. Try at configue stage
> set TARGET_LDFLAGS=-melf_i386
Sorry, I meant:
TARGET_LDFLAGS=-Wl,-melf_i386

Re: GRUB2 on OpenBSD 5.3-amd64: linking problem

[Ilya Bakulin]

On Wednesday 14 August 2013 10:59:24 Vladimir 'φ-coder/phcoder' Serbinenko 
wrote:
> On 13.08.2013 23:03, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> > On 09.08.2013 15:37, Ilya Bakulin wrote:
> >> Could you please help me to solve the linking problem?
> >> What else do you need from me?
> >
> > Sounds like your gcc doesn't pass -m32 to linker. Try at configue stage
> > set TARGET_LDFLAGS=-melf_i386
>
> Sorry, I meant:
> TARGET_LDFLAGS=-Wl,-melf_i386

Yeah, that did the trick!

> On 09.08.2013 15:37, Ilya Bakulin wrote:
> > ./configure CFLAGS=-ftrampolines -fno-stack-protector
> > LEX=/usr/local/bin/gflex TARGET_CFLAGS=-ftrampolines -fno-stack-protector
>
> You don't need -ftrampolines. Also you forgot quotes.

I cannot compile code without 
TARGET_CFLAGS='-ftrampolines -fno-stack-protector' -- more precisely, without 
trampolines. Configure fails with this message:

...
checking whether `gcc' generates calls to `__enable_execute_stack()'... 
configure: error: gcc failed to produce assembly code

The message from config.log says:
conftest.c: In function 'g':
conftest.c:282: error: trampoline code generation is not allowed 
without -ftrampolines
configure:20492: $? = 1
configure:20496: error: gcc failed to produce assembly code


If I configure without -ftrampolines in CFLAGS, configure finishes just OK,
but compilation later fails:
gcc -DHAVE_CONFIG_H -I.   -Wall -W -I./include -DGRUB_UTIL=1 -DGRUB_LIBDIR=\"/usr/local/lib/grub\" -DLOCALEDIR=\"/usr/local/share/locale\" -DGRUB_FILE=\"grub-core/kern/device.c\" -I. -I. -I. -I. -I./include -I./include  -I./grub-core/gnulib -I./grub-core/gnulib                -fno-builtin-gettext -Wall -W -Wshadow -Wold-style-definition -Wpointer-arith -Wundef -Wextra -Waddress -Wattributes -Wcast-align -Wchar-subscripts -Wcomment -Wdeprecated-declarations -Wdisabled-optimization -Wdiv-by-zero -Wendif-labels -Wfloat-equal -Wformat-extra-args -Wformat-security -Wformat-y2k -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Winit-self -Wint-to-pointer-cast -Winvalid-pch -Wmain -Wmissing-braces -Wmissing-field-initializers -Wmissing-format-attribute -Wmissing-noreturn -Wmultichar -Wnonnull -Woverflow -Wparentheses -Wpointer-arith -Wpointer-to-int-cast -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare -Wstrict-aliasing -Wswitch -Wtrigraphs -Wundef -Wunknown-pragmas -Wunused -Wunused-function -Wunused-label -Wunused-parameter -Wunused-value  -Wunused-variable -Wvariadic-macros -Wvolatile-register-var -Wwrite-strings -Wnested-externs -Wstrict-prototypes -Wpointer-sign -Werror  -Wno-undef -Wno-sign-compare -Wno-unused -Wno-unused-parameter -Wno-redundant-decls -Wno-unreachable-code -Wno-conversion -Wno-old-style-definition -Wno-unsafe-loop-optimizations               -MT 
grub-core/kern/libgrubkern_a-device.o -MD -MP -MF 
grub-core/kern/.deps-util/libgrubkern_a-device.Tpo -c -o 
grub-core/kern/libgrubkern_a-device.o `test -f 'grub-core/kern/device.c' || 
echo './'`grub-core/kern/device.c
grub-core/kern/device.c: In function 'grub_device_iterate':
grub-core/kern/device.c:178: error: trampoline code generation is not allowed 
without -ftrampolines
grub-core/kern/device.c:178: error: trampoline code generation is not allowed 
without -ftrampolines
gmake[2]: *** [grub-core/kern/libgrubkern_a-device.o] Error 1


So for proper compilation I _have_ to pass -ftrampolines in both CFLAGS and 
TARGET_CFLAGS.

By the way, is there any way to define which GRUB modules to build?
Right now I get a compile error on squash4_module, which I'm not going to use 
anyway...

The compile error is as follows:
gmake[3]: Entering directory `/data/home/ibaku/grub2/grub-2.00/grub-core'
gcc -DHAVE_CONFIG_H -I. -I..  -Wall -W -I../include -I../include  -DGRUB_MACHINE_PCBIOS=1 -DGRUB_MACHINE=I386_PC -DGRUB_TARGET_CPU_I386=1 -m32 -DGRUB_FILE=\"fs/squash4.c\" -I. -I. -I.. -I.. -I../include -I../include   -I./lib/posix_wrap -I./lib/xzembed -I./lib/minilzo -DMINILZO_HAVE_CONFIG_H   -ftrampolines -fno-stack-protector -Wall -W -Wshadow -Wold-style-definition -Wpointer-arith -Wundef -Wextra -Waddress -Wattributes -Wcast-align -Wchar-subscripts -Wcomment -Wdeprecated-declarations -Wdisabled-optimization -Wdiv-by-zero -Wendif-labels -Wfloat-equal -Wformat-extra-args -Wformat-security -Wformat-y2k -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Winit-self -Wint-to-pointer-cast -Winvalid-pch -Wmain -Wmissing-braces -Wmissing-field-initializers -Wmissing-format-attribute -Wmissing-noreturn -Wmultichar -Wnonnull -Woverflow -Wparentheses -Wpointer-arith -Wpointer-to-int-cast -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare -Wstrict-aliasing -Wswitch -Wtrigraphs -Wundef -Wunknown-pragmas -Wunused -Wunused-function -Wunused-label -Wunused-parameter -Wunused-value  -Wunused-variable -Wvariadic-macros -Wvolatile-register-var -Wwrite-strings -Wnested-externs -Wstrict-prototypes -Wpointer-sign -g -Wredundant-decls -Wmissing-prototypes -Wmissing-declarations -falign-jumps=1 -falign-loops=1 -falign-functions=1 -mno-mmx -mno-sse -mno-sse2 -mno-3dnow -m32 -fno-PIE -fno-PIC -fno-stack-protector -mno-stack-arg-probe -Wno-trampolines   -mrtd -mregparm=3       -ffreestanding -fno-builtin -Wno-undef  -ftrampolines -fno-stack-protector -MT 
fs/squash4_module-squash4.o -MD -MP -MF 
fs/.deps-core/squash4_module-squash4.Tpo -c -o fs/squash4_module-squash4.o 
`test -f 'fs/squash4.c' || echo './'`fs/squash4.c
In file included from ./lib/posix_wrap/stdint.h:1,
                 from ./lib/xzembed/xz.h:27,
                 from fs/squash4.c:31:
./lib/posix_wrap/sys/types.h:25: error: conflicting types for 'size_t'
/usr/include/stddef.h:48: error: previous declaration of 'size_t' was here
gmake[3]: *** [fs/squash4_module-squash4.o] Error 1
gmake[3]: Leaving directory `/data/home/ibaku/grub2/grub-2.00/grub-core'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory `/data/home/ibaku/grub2/grub-2.00/grub-core'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/data/home/ibaku/grub2/grub-2.00'
gmake: *** [all] Error 2

Thank you!

--
Ilya

Re: GRUB2 on OpenBSD 5.3-amd64: linking problem

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 14.08.2013 15:09, Ilya Bakulin wrote:
>
> So for proper compilation I_have_  to pass -ftrampolines in both CFLAGS and
> TARGET_CFLAGS.
Please use latest bzr version.

Re: GRUB2 on OpenBSD 5.3-amd64: linking problem

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 14.08.2013 15:09, Ilya Bakulin wrote:
> ./lib/posix_wrap/sys/types.h:25: error: conflicting types for 'size_t'
> /usr/include/stddef.h:48: error: previous declaration of 'size_t' was here
> gmake[3]: *** [fs/squash4_module-squash4.o] Error 1
You need to modify following:
#ifndef __APPLE__
typedef grub_size_t size_t;
#else
#include <stddef.h>
#endif
to
#if !defined (__APPLE__) && !defined (__OPENBSD__)

Re: GRUB2 on OpenBSD 5.3-amd64: linking problem

[Grégoire Sutre]

On 08/14/2013 03:31 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 14.08.2013 15:09, Ilya Bakulin wrote:
>> ./lib/posix_wrap/sys/types.h:25: error: conflicting types for 'size_t'
>> /usr/include/stddef.h:48: error: previous declaration of 'size_t' was
>> here
>> gmake[3]: *** [fs/squash4_module-squash4.o] Error 1
> You need to modify following:
> #ifndef __APPLE__
> typedef grub_size_t size_t;
> #else
> #include <stddef.h>
> #endif
> to
> #if !defined (__APPLE__) && !defined (__OPENBSD__)

For the record, this is also needed for NetBSD (when building
within the pkgsrc framework -- see pkgsrc's sysutils/grub2 package).

A similar patch (for NetBSD, but maybe also for OpenBSD?) is:

--- grub-core/lib/posix_wrap/wchar.h.orig	2012-02-08 20:34:24.000000000 
+0000
+++ grub-core/lib/posix_wrap/wchar.h
@@ -29,7 +29,11 @@ enum
    };

  /* UCS-4.  */
+#if !defined(__NetBSD__)
  typedef grub_int32_t wchar_t;
+#else
+#include <stddef.h>
+#endif

  typedef struct mbstate {
    grub_uint32_t code;


Grégoire

Re: GRUB2 on OpenBSD 5.3-amd64: linking problem

[Ilya Bakulin]

Hi,

On Wednesday 14 August 2013 15:49:03 Grégoire Sutre wrote:
> On 08/14/2013 03:31 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> > You need to modify following:
> > #ifndef __APPLE__
> > typedef grub_size_t size_t;
> > #else
> > #include <stddef.h>
> > #endif
> > to
> > #if !defined (__APPLE__) && !defined (__OPENBSD__)
Yes, this works!

>
> For the record, this is also needed for NetBSD (when building
> within the pkgsrc framework -- see pkgsrc's sysutils/grub2 package).
>
> A similar patch (for NetBSD, but maybe also for OpenBSD?) is:
>
> --- grub-core/lib/posix_wrap/wchar.h.orig	2012-02-08 20:34:24.000000000
> +0000
> +++ grub-core/lib/posix_wrap/wchar.h
> @@ -29,7 +29,11 @@ enum
>     };
>
>   /* UCS-4.  */
> +#if !defined(__NetBSD__)
>   typedef grub_int32_t wchar_t;
> +#else
> +#include <stddef.h>
> +#endif
>
>   typedef struct mbstate {
>     grub_uint32_t code;

Unfortunately, this doesn't seem to be enough, because stddef.h on OpenBSD 
already has the definition for mbstate_t. So if I let wchar.h define its own 
version, there is a definition conflict. And omitting stddef.h inclusion also 
doesn't work, because stddef.h seems to be already included from elsewhere.
If I move the "typedef mbstate .. mbstate_t" into '#if !defined(__OpenBSD__)',
then the code uses the version from stddef.h, which lacks "code" and "count" 
fields. It is defined as follows:

/*
 * mbstate_t is an opaque object to keep conversion state, during multibyte
 * stream conversions. The content must not be referenced by user programs.
 */
typedef union {
        char __mbstate8[128];
        __int64_t __mbstateL;                   /* for alignment */
} __mbstate_t;


Anyway, I'm going to try the version from Bazaar. Will report the results 
tomorrow.
Thank you all for your help!

--
Ilya

Re: GRUB2 on OpenBSD 5.3-amd64: linking problem

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 14.08.2013 17:16, Ilya Bakulin wrote:
> If I move the "typedef mbstate .. mbstate_t" into '#if !defined(__OpenBSD__)',
> then the code uses the version from stddef.h, which lacks "code" and "count"
> fields. It is defined as follows:
Try:
#ifdef __OpenBSD__
#define mbstate_t grub_posix_mbstate_t
#endif

Re: GRUB2 on OpenBSD 5.3-amd64: linking problem

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 14.08.2013 15:49, Grégoire Sutre wrote:
> On 08/14/2013 03:31 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> On 14.08.2013 15:09, Ilya Bakulin wrote:
>>> ./lib/posix_wrap/sys/types.h:25: error: conflicting types for 'size_t'
>>> /usr/include/stddef.h:48: error: previous declaration of 'size_t' was
>>> here
>>> gmake[3]: *** [fs/squash4_module-squash4.o] Error 1
>> You need to modify following:
>> #ifndef __APPLE__
>> typedef grub_size_t size_t;
>> #else
>> #include <stddef.h>
>> #endif
>> to
>> #if !defined (__APPLE__) && !defined (__OPENBSD__)
>
> For the record, this is also needed for NetBSD (when building
> within the pkgsrc framework -- see pkgsrc's sysutils/grub2 package).
>
> A similar patch (for NetBSD, but maybe also for OpenBSD?) is:
>
> --- grub-core/lib/posix_wrap/wchar.h.orig    2012-02-08
> 20:34:24.000000000 +0000
> +++ grub-core/lib/posix_wrap/wchar.h
> @@ -29,7 +29,11 @@ enum
>     };
>
>   /* UCS-4.  */
> +#if !defined(__NetBSD__)
>   typedef grub_int32_t wchar_t;
> +#else
> +#include <stddef.h>
> +#endif
>
This is not right fix. Many systems incorrectly define wchar_t as 16-bit 
type whil GRUB needs at least 21 as we handle all unicode characters. 
Please try:
=== modified file 'grub-core/lib/posix_wrap/wchar.h'
--- grub-core/lib/posix_wrap/wchar.h	2012-02-09 13:24:55 +0000
+++ grub-core/lib/posix_wrap/wchar.h	2013-08-15 14:55:59 +0000
@@ -21,6 +21,11 @@

  #include <grub/charset.h>

+#if defined(__NetBSD__) || defined(__OPENBSD__)
+#define wchar_t grub_posix_wchar_t
+#define mbstate_t grub_posix_mbstate_t
+#endif
+
  /* UCS-4.  */
  typedef grub_int32_t wint_t;
  enum

Re: GRUB2 on OpenBSD 5.3-amd64: linking problem

[Grégoire Sutre]

On 08/15/2013 05:00 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:

> This is not right fix. Many systems incorrectly define wchar_t as 16-bit
> type whil GRUB needs at least 21 as we handle all unicode characters.
> Please try:
> === modified file 'grub-core/lib/posix_wrap/wchar.h'
> --- grub-core/lib/posix_wrap/wchar.h 2012-02-09 13:24:55 +0000
> +++ grub-core/lib/posix_wrap/wchar.h 2013-08-15 14:55:59 +0000
> @@ -21,6 +21,11 @@
>
> #include <grub/charset.h>
>
> +#if defined(__NetBSD__) || defined(__OPENBSD__)
> +#define wchar_t grub_posix_wchar_t
> +#define mbstate_t grub_posix_mbstate_t
> +#endif
> +
> /* UCS-4. */
> typedef grub_int32_t wint_t;
> enum

Yes, this patch fixes the build problem on NetBSD.

Grégoire

Re: GRUB2 on OpenBSD 5.3-amd64: linking problem

[Ilya Bakulin]

Hi Vladimir,

so I'm trying the latest version from BZR now. Running ./configure without 
CFLAGS succeeds now, thanks!

On Wednesday 14 August 2013 18:28:45 Vladimir 'φ-coder/phcoder' Serbinenko 
wrote:
> #ifdef __OpenBSD__
> #define mbstate_t grub_posix_mbstate_t
> #endif

Yes, this seems to help!
The correct way to detect OpenBSD system is __OpenBSD__, not  __OPENBSD__.

Now I have the following error:
gmake[3]: Entering directory `/home/kibab/repos/grub/grub-core'
gcc -DHAVE_CONFIG_H -I. -I..   -Wall -W -I../include -I../include  -DGRUB_MACHINE_PCBIOS=1 -DGRUB_MACHINE=I386_PC -DGRUB_TARGET_CPU_I386=1 -m32 -DGRUB_FILE=\"gnulib/regex.c\" -I. -I. -I.. -I.. -I../include -I../include -I../grub-core/lib/libgcrypt-grub/include -I../grub-core/lib/libgcrypt-grub/src/  -I../grub-core/lib/posix_wrap -I../grub-core/gnulib -I../grub-core/gnulib                  -Os -Wall -W -Wshadow -Wold-style-definition -Wpointer-arith -Wundef -Wextra -Waddress -Wattributes -Wcast-align -Wchar-subscripts -Wcomment -Wdeprecated-declarations -Wdisabled-optimization -Wdiv-by-zero -Wendif-labels -Wfloat-equal -Wformat-extra-args -Wformat-security -Wformat-y2k -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Winit-self -Wint-to-pointer-cast -Winvalid-pch -Wmain -Wmissing-braces -Wmissing-field-initializers -Wmissing-format-attribute -Wmissing-noreturn -Wmultichar -Wnonnull -Woverflow -Wparentheses -Wpointer-arith -Wpointer-to-int-cast -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare -Wstrict-aliasing -Wswitch -Wtrigraphs -Wundef -Wunknown-pragmas -Wunused -Wunused-function -Wunused-label -Wunused-parameter -Wunused-value  -Wunused-variable -Wvariadic-macros -Wvolatile-register-var -Wwrite-strings -Wnested-externs -Wstrict-prototypes -Wpointer-sign -g -Wredundant-decls -Wmissing-prototypes -Wmissing-declarations -falign-jumps=1 -falign-loops=1 -falign-functions=1 -mno-mmx -mno-sse -mno-sse2 -mno-3dnow -m32 -fno-PIE -fno-PIC -fno-stack-protector -Werror -Wtrampolines  -mrtd -mregparm=3        -Dfloat=__grub_poision -Ddouble=__grub_poision -fno-builtin -fno-builtin -Wno-undef -Wno-sign-compare -Wno-unused -Wno-unused-parameter -Wno-redundant-decls -Wno-unreachable-code -Wno-conversion -Wno-old-style-definition -Wno-unsafe-loop-optimizations                 -MT 
gnulib/libgnulib_a-regex.o -MD -MP -MF 
gnulib/.deps-core/libgnulib_a-regex.Tpo -c -o gnulib/libgnulib_a-regex.o 
`test -f 'gnulib/regex.c' || echo './'`gnulib/regex.c
In file included from /usr/include/sys/_types.h:37,
                 from /usr/include/stddef.h:39,
                 from ../grub-core/lib/posix_wrap/sys/types.h:27,
                 from ../grub-core/gnulib/regex.h:24,
                 from gnulib/regex.c:67:
/usr/include/machine/_types.h:122: error: expected '=', ',', ';', 'asm' 
or '__attribute__' before '__double_t'
/usr/include/machine/_types.h:123: error: expected '=', ',', ';', 'asm' 
or '__attribute__' before '__float_t'
gmake[3]: *** [gnulib/libgnulib_a-regex.o] Error 1
gmake[3]: Leaving directory `/home/kibab/repos/grub/grub-core'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory `/home/kibab/repos/grub/grub-core'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/home/kibab/repos/grub'
gmake: *** [all] Error 2

Lines 122 and 123 in /usr/include/sys/_types.h are:
typedef double                  __double_t;
typedef float                   __float_t;

So the types "double" and "float" are not recognized.

Could you please help me to debug this?


Good news is that the tools like grub-bios-setup and grub-mkimage already 
work, I was able to install GRUB into MBR just fine.

--
Ilya

Re: GRUB2 on OpenBSD 5.3-amd64: linking problem

[Grégoire Sutre]

On 08/16/2013 04:33 PM, Ilya Bakulin wrote:

> So the types "double" and "float" are not recognized.
>
> Could you please help me to debug this?

I get the exact same problem on NetBSD.  A simple (temporary)
work-around is to remove the flags:

-Dfloat=__grub_poision -Ddouble=__grub_poision

Those are set in conf/Makefile.common.

Grégoire

Re: GRUB2 on OpenBSD 5.3-amd64: linking problem

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 811 bytes --]

On 16.08.2013 16:41, Grégoire Sutre wrote:
> On 08/16/2013 04:33 PM, Ilya Bakulin wrote:
> 
>> So the types "double" and "float" are not recognized.
>>
>> Could you please help me to debug this?
> 
> I get the exact same problem on NetBSD.  A simple (temporary)
> work-around is to remove the flags:
> 
> -Dfloat=__grub_poision -Ddouble=__grub_poision
> 
> Those are set in conf/Makefile.common.
> 
The problem is that OpenBSD and NetBSD insist on using floating-point
types which if used in GRUB (or any other code designed to run in
integer-only environment) would cause crash. This insistance is bad and
dangerous.
> Grégoire
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]

Re: GRUB2 on OpenBSD 5.3-amd64: linking problem

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 995 bytes --]

On 23.08.2013 11:26, Ilya Bakulin wrote:
> On Thursday 22 August 2013 20:16:48 Vladimir 'φ-coder/phcoder' Serbinenko 
> wrote:
>> On 21.08.2013 21:06, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>> Based on your work, current WIP patch. I've committed some parts of your
>>> patch as well as my own fixes. Remainder is attached
>>> Current problems:
>>> -double/float is mostly a kludge
>>> -build-grub-mkfont
>>> -nm on OpenBSD doesn't accept same options as GNU one.
>>
>> Only the first problem still remains.
> 
> I have just tested the compilation of the latest revision (5148) and confirm 
> that it compiles OK!
> There is a warning about random generator not being secure in 
> util/grub-mkpasswd-pbkdf2.c, which may be supressed by adding "&& ! defined 
> (__OpenBSD__)" to the defines list.
To do this we need a confirmation that reading from /dev/urandom is
indeed the right way to access PRNG on OpenBSD and that it gives us
cryptographically good random.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]

Re: GRUB2 on OpenBSD 5.3-amd64: linking problem

[Ilya Bakulin]

On Friday 23 August 2013 11:31:06 Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> > There is a warning about random generator not being secure in
> > util/grub-mkpasswd-pbkdf2.c, which may be supressed by adding "&& !
> > defined (__OpenBSD__)" to the defines list.
>
> To do this we need a confirmation that reading from /dev/urandom is
> indeed the right way to access PRNG on OpenBSD and that it gives us
> cryptographically good random.

On OpenBSD, all random pseudo-devices (random, arandom, srandom, urandom) 
provide cryptographically good random.
From the random(4) man page:

DESCRIPTION
     The various random devices produce high quality random output data.
     Entropy data is collected from system activity (like disk, network, and
     clock device interrupts and such), and then run through various hash or
     message digest functions to generate the output.  All the random devices
     are expected to provide high quality pseudo-random output data.

     The arc4random(3) function in userland libraries seeds itself from this
     device (or with the sysctl(3) interface), providing a second level of
     ARC4 hashed data without the need to access these devices every time.

--
Ilya

Re: GRUB2 on OpenBSD 5.3-amd64: linking problem

[Douglas Ray]

[-- Attachment #1: Type: text/plain, Size: 2143 bytes --]

On 23/08/13 7:31 PM, Vladimir '?-coder/phcoder' Serbinenko wrote:
> On 23.08.2013 11:26, Ilya Bakulin wrote:
>> On Thursday 22 August 2013 20:16:48 Vladimir '?-coder/phcoder' Serbinenko
>> wrote:
>>> On 21.08.2013 21:06, Vladimir '?-coder/phcoder' Serbinenko wrote:
>>>> Based on your work, current WIP patch. I've committed some parts of your
>>>> patch as well as my own fixes. Remainder is attached
>>>> Current problems:
>>>> -double/float is mostly a kludge
>>>> -build-grub-mkfont
>>>> -nm on OpenBSD doesn't accept same options as GNU one.
>>> Only the first problem still remains.
>> I have just tested the compilation of the latest revision (5148) and confirm
>> that it compiles OK!
>> There is a warning about random generator not being secure in
>> util/grub-mkpasswd-pbkdf2.c, which may be supressed by adding "&& ! defined
>> (__OpenBSD__)" to the defines list.
> To do this we need a confirmation that reading from /dev/urandom is
> indeed the right way to access PRNG on OpenBSD and that it gives us
> cryptographically good random.
>
What would you consider adequate confirmation?

I understand there was a problem with random and urandom in
OpenBSD up to 4.9, though arandom was good.

calomel.org asserts that, as of OpenBSD 5.1, all their random devices
use the arc4 library;  /dev/urandom now gives as good as /dev/arandom.

The following 'ent' analysis is presented for /dev/arandom:
-----------------------------------------------------

user@machine:  ./ent output
Entropy = 7.999956 bits per byte.

Optimum compression would reduce the size
of this 419430400 byte file by 0 percent.

Chi square distribution for 419430400 samples is 257.21, and randomly
would exceed this value 44.95 percent of the times.

Arithmetic mean value of data bytes is 127.5178 (127.5 = random).
Monte Carlo value for Pi is 3.144255776 (error 0.08 percent).
Serial correlation coefficient is -0.000120 (totally uncorrelated = 0.0).

-----------------------------------------------------
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel


[-- Attachment #2: Type: text/html, Size: 3333 bytes --]

Re: GRUB2 on OpenBSD 5.3-amd64: linking problem

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 412 bytes --]

On 30.08.2013 19:33, Douglas Ray wrote:
> 
> calomel.org asserts that, as of OpenBSD 5.1, all their random devices
> use the arc4 library;  /dev/urandom now gives as good as /dev/arandom.
This is good enough. We are not crypto society which goes into security
holes in other software. Also impact of bad random is minor in GRUB
case. If X is considered the right to get random on given OS then it's ok.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]

Re: GRUB2 on OpenBSD 5.3-amd64: linking problem

[Ilya Bakulin]

[-- Attachment #1: Type: text/plain, Size: 2017 bytes --]

Hi Vladimir,
So I'm preparing a OpenBSD port of GRUB2. I have chosen a revision 5152
for the initial version of the port.
Unfortunately, the build fails when using -Werror.
I suspect that the ports framework overrides some values that are usually 
guessed by ./configure, and this causes build to fail.

The build log are available here:
Build with -Werror:
http://dl.bakulin.de/openbsd/grub-build/make_werror.log

Build without -Werror: 
http://dl.bakulin.de/openbsd/grub-build/make_no_werror.log

Build using ./configure --disable-silent-rules LEX=/usr/local/bin/gflex, out 
of ports framework (in this case ./configure doesn't use any cached values):
http://dl.bakulin.de/openbsd/grub-build/make_standalone.log

I am not familiar with the GNU configure, but AFAIK the product of ./configure
is the set of config-*.h files. If it is right, there are two files for GRUB2,
config.h and config-util.h. Here is a diff between config-util.h generated 
during standalone and port build:

$ diff config-util.h_standalone  config-util.h_portbuild                                                                                                                        
1040c1040
< /* #undef HAVE_SYS_MOUNT_H */
---
> #define HAVE_SYS_MOUNT_H 1
1518c1518
< #define restrict __restrict
---
> #define restrict __restrict__

That is, HAVE_SYS_MOUNT_H is defined when building the port, and "restrict" is 
__restrict__.

Could you please help me to debug this error?

--
Ilya

On Wednesday 18 September 2013 13:49:38 Vladimir 'φ-coder/phcoder' Serbinenko 
wrote:
> On 30.08.2013 19:33, Douglas Ray wrote:
> > calomel.org asserts that, as of OpenBSD 5.1, all their random devices
> > use the arc4 library;  /dev/urandom now gives as good as /dev/arandom.
>
> This is good enough. We are not crypto society which goes into security
> holes in other software. Also impact of bad random is minor in GRUB
> case. If X is considered the right to get random on given OS then it's ok.


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: GRUB2 on OpenBSD 5.3-amd64: linking problem

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]

On 23.09.2013 17:59, Ilya Bakulin wrote:
> Hi Vladimir,
> So I'm preparing a OpenBSD port of GRUB2. I have chosen a revision 5152
> for the initial version of the port.
I already did couple revisions ago. After that I made further
simplifications to multi-OS mess and it's possible that there is minor
brokenness
The issue I didn't solve yet is OpenBSD using double/float in the
headers (but you can comment out those 2 lines in Makefile.common).
Other than that it should work.
Checking out r5152 and porting it would be you duplicating my work,
please don't.
Rather help us testing, look into a way to avoid double/float for sure
on OpenBSD and identify which other features are needed/helpful for
OpenBSD (RAID? LFS?)



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]

Re: GRUB2 on OpenBSD 5.3-amd64: linking problem

[Ilya Bakulin]

On Monday 23 September 2013 18:16:15 Vladimir 'φ-coder/phcoder' Serbinenko 
wrote:
> On 23.09.2013 17:59, Ilya Bakulin wrote:
> > Hi Vladimir,
> > So I'm preparing a OpenBSD port of GRUB2. I have chosen a revision 5152
> > for the initial version of the port.
>
> I already did couple revisions ago. After that I made further
> simplifications to multi-OS mess and it's possible that there is minor
> brokenness

Hi Vladimir,
as already discussed on IRC, by "port" I meant an entry in OpenBSD Ports 
Collection. That is like meta-information used to build a package to be 
installed later by OpenBSD package framework.

> The issue I didn't solve yet is OpenBSD using double/float in the
> headers (but you can comment out those 2 lines in Makefile.common).
Not sure which 2 lines you're talking about, currently I'm just using the 
patch you've proposed earlier (#undef double/#define double signed long).

Another issue I've found is that on OpenBSD/i386 the wrong linker format is 
used, this patch fixes that:
$ bzr diff
=== modified file 'configure.ac'
--- configure.ac        2013-09-23 11:48:10 +0000
+++ configure.ac        2013-10-07 10:57:23 +0000
@@ -655,6 +655,14 @@
       TARGET_LDFLAGS="$TARGET_LDFLAGS -Wl,-melf_x86_64_fbsd"
     fi
     ;;
+  openbsd*)
+    if test x"$target_cpu" = xi386; then
+      TARGET_LDFLAGS="$TARGET_LDFLAGS -Wl,-melf_i386_obsd"
+    fi
+    if test x"$target_cpu" = xx86_64; then
+      TARGET_LDFLAGS="$TARGET_LDFLAGS -Wl,-melf_x86_64_obsd"
+    fi
+    ;;
   *)
     if test x"$target_cpu" = xi386; then
       TARGET_LDFLAGS="$TARGET_LDFLAGS -Wl,-melf_i386"

> Other than that it should work.
> Checking out r5152 and porting it would be you duplicating my work,
> please don't.
So it makes sense for me to update to the later revision, doesn't it?
The reason why I'm asking is that I should provide an URL to download the code 
snapshot from. Currently, as there is no GRUB2 release which includes the 
OpenBSD-related patches, I have to run ./autogen, pack the tarball myself and 
put it on my server. 
> Rather help us testing, look into a way to avoid double/float for sure
> on OpenBSD and identify which other features are needed/helpful for
> OpenBSD (RAID? LFS?)
I have one more patch for cmd_loopback that I find useful for certain cases.
I will post it in the separate email later.

--
Ilya