GRUB and Google Summer of Code

GRUB and Google Summer of Code

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

Hello, all. As every year GNU participates as umbrella organisation at
Google Summer of Code. So if you willing to be a student or a mentor
feel free to discuss the ideas here. Just few ideas to start with:
-USB. It needs a lot of fixing and EHCI port.
-AHCI. Really needed
-Some other hardware which may contain something bootable. We will
probably have a network subsystem contributed by IBM before Summer so
making more cards to work would be a good project
-Multiboot mission. Port widespread payloads to multiboot (FreeBSD,
Linux, ...)
-New port. The best idea now is probably ARM. More info follow in
separate e-mail
-Better video cards support
-Native windows and ReactOS loading (not chainloading)
-Parted integration
-Booting time reductions by various means like using multicore and
parallely loading and decompressing
Have a look at https://savannah.gnu.org/task/?group=grub
This list is only an entry point into discussion. Feel free to propose.
Also some of items may be too small for a SoC. They can be bundled together

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



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

Re: GRUB and Google Summer of Code

[Michal Suchanek]

2010/3/29 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:

> -Some other hardware which may contain something bootable. We will
> probably have a network subsystem contributed by IBM before Summer so

Is there some more information about this network  subsystem available?

This sounds interesting.

Thanks

Michal

Re: GRUB and Google Summer of Code

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

Michal Suchanek wrote:
> 2010/3/29 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>
>   
>> -Some other hardware which may contain something bootable. We will
>> probably have a network subsystem contributed by IBM before Summer so
>>     
>
> Is there some more information about this network  subsystem available?
>
>   
No, I don't know more details myself except that I provided few
skeletons for it. When IBM is ready we'll  hear from them. Until
thentrying to push would only have negative results
> This sounds interesting.
>   
Yes, it does
> Thanks
>
> Michal
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



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

Re: GRUB and Google Summer of Code

[Alex Zanetti de Lima]

On Tue 30 Mar 2010 (14:26) Vladimir 'φ-coder/phcoder' Serbinenko said 
> Michal Suchanek wrote:
> > 2010/3/29 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
> >> -Some other hardware which may contain something bootable. We will
> >> probably have a network subsystem contributed by IBM before Summer so
> >
> > Is there some more information about this network  subsystem available?
> 
> No, I don't know more details myself except that I provided few
> skeletons for it. When IBM is ready we'll  hear from them. Until
> thentrying to push would only have negative results

Hi, I'm one of the guys working with grub2 at IBM. That's my first mail to the 
list :)

The default bootloader for PPC machines is still Yaboot (at least on RHEL and 
SLES), and our main goal here at IBM is to contribute code to grub2 to make it 
Yaboot's replacement for PPC systems (specifically IBM POWER5, POWER6 and POWER7 
machines).

The most important feature that we were lacking in grub2, from a PPC 
perspective, was netboot. We ported bootp/tftp support from yaboot to grub2, but 
the implementation was PPC specific, relying upon OFW's obp-tftp package to 
handle all network communication.

We discussed that with Vladimir, who pointed out the following drawbacks:
1) Current implementation was BOOTP/TFTP only. No support for other protocols.
2) Almost no shared code between architectures.
3) 100% dependent on OFW.

We are now working on a network infrastructure that could be shared by all 
platforms, including protocols, device drivers, etc. Gpxe project is a good 
start point, and most of things are being developed based on it.

Chances are that we'll have something working on x86 soon, and then we'll start 
adding support for PPC (access to PCI bus via OFW, VIO, device drivers for some 
very specific cards like ehea, etc).

So far Manoel Abranches is the only person (part-time) actually developing code 
and he's doing that based on the skeletons created by Vladimir (am still getting 
some approvals from IBM legal to contribute code...).

Cheers,
--
Alex Zanetti de Lima (trustlix)

> 
> > This sounds interesting.
> 
> Yes, it does
> 
> > Thanks
> >
> > Michal
> >
> >
> > _______________________________________________
> > Grub-devel mailing list
> > Grub-devel@gnu.org
> > http://lists.gnu.org/mailman/listinfo/grub-devel
> 

Re: GRUB and Google Summer of Code

[Michal Suchanek]

On 30 March 2010 20:46, Alex Zanetti de Lima
<trustlix@linux.vnet.ibm.com> wrote:
> On Tue 30 Mar 2010 (14:26) Vladimir 'φ-coder/phcoder' Serbinenko said
>> Michal Suchanek wrote:
>> > 2010/3/29 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>> >> -Some other hardware which may contain something bootable. We will
>> >> probably have a network subsystem contributed by IBM before Summer so
>> >
>> > Is there some more information about this network  subsystem available?
>>
>> No, I don't know more details myself except that I provided few
>> skeletons for it. When IBM is ready we'll  hear from them. Until
>> thentrying to push would only have negative results
>
> Hi, I'm one of the guys working with grub2 at IBM. That's my first mail to the
> list :)
>
> The default bootloader for PPC machines is still Yaboot (at least on RHEL and
> SLES), and our main goal here at IBM is to contribute code to grub2 to make it
> Yaboot's replacement for PPC systems (specifically IBM POWER5, POWER6 and POWER7
> machines).
>
> The most important feature that we were lacking in grub2, from a PPC
> perspective, was netboot. We ported bootp/tftp support from yaboot to grub2, but
> the implementation was PPC specific, relying upon OFW's obp-tftp package to
> handle all network communication.
>
> We discussed that with Vladimir, who pointed out the following drawbacks:
> 1) Current implementation was BOOTP/TFTP only. No support for other protocols.
> 2) Almost no shared code between architectures.
> 3) 100% dependent on OFW.
>
> We are now working on a network infrastructure that could be shared by all
> platforms, including protocols, device drivers, etc. Gpxe project is a good
> start point, and most of things are being developed based on it.
>
> Chances are that we'll have something working on x86 soon, and then we'll start
> adding support for PPC (access to PCI bus via OFW, VIO, device drivers for some
> very specific cards like ehea, etc).
>

I would be interested in the x86 port and something like telnet and/or
VNC terminal for Grub or at least reading configuration from the
network. I guess it would be possible to test and add additional
layers quite easily once one of the network cards emulated in qemu is
supported.

There is already some crypto imported for password support so adding
enough to have SSL would hopefully not be too difficult.

Thanks

Michal

GRUB and network (was Re: GRUB and Google Summer of Code)

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

First of all please change subject line when topic changes
Michal Suchanek wrote:
>>     
>
> I would be interested in the x86 port and something like telnet and/or
> VNC terminal for Grub or at least reading configuration from the
> network. 
The problem is that for this grub has to be a server. For e.g. ftp grub
is a client so it needs to take any action only when it needs data.
On the other hand if grub acts as a server it must be able to process
the connection request at any moment.
> I guess it would be possible to test and add additional
> layers quite easily once one of the network cards emulated in qemu is
> supported.
>   
Actually we can just add a pseudo-card which will use sufficiently
low-level network interface to grub-emu
> There is already some crypto imported for password support so adding
> enough to have SSL would hopefully not be too difficult.
>   
Not true. Although we have ciphers and hashes we don't have either
asymetric algorithms or random generator. The first is easy to import
but generating random numbers involves gathering entropy which is
cornerstone of network cryptography. Without a good random number
generator most SSL algorithms will only make the user happier without
adding any security against attacker.


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



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

Re: GRUB and network (was Re: GRUB and Google Summer of Code)

[Isaac Dupree]

On 04/01/10 16:59, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> There is already some crypto imported for password support so adding
>> enough to have SSL would hopefully not be too difficult.
>>
> Not true. Although we have ciphers and hashes we don't have either
> asymetric algorithms or random generator. The first is easy to import
> but generating random numbers involves gathering entropy which is
> cornerstone of network cryptography. Without a good random number
> generator most SSL algorithms will only make the user happier without
> adding any security against attacker.

Is it reasonable to generate some random data during grub-install, and 
write it to the disk, where GRUB will then use it?  Maybe in combination 
with real-time clock, this can be good enough initial entropy? (But I 
have not consulted with security research--this is just a guess.)

-Isaac

Re: GRUB and network (was Re: GRUB and Google Summer of Code)

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

Isaac Dupree wrote:
> On 04/01/10 16:59, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>> There is already some crypto imported for password support so adding
>>> enough to have SSL would hopefully not be too difficult.
>>>
>> Not true. Although we have ciphers and hashes we don't have either
>> asymetric algorithms or random generator. The first is easy to import
>> but generating random numbers involves gathering entropy which is
>> cornerstone of network cryptography. Without a good random number
>> generator most SSL algorithms will only make the user happier without
>> adding any security against attacker.
>
> Is it reasonable to generate some random data during grub-install, and
> write it to the disk, where GRUB will then use it?
It is possible but there following problems:
1) This file has to be kept secret. In cases when one can be reasonably
sure GRUB wasn't tempered with but isn't sure it's still secret (e.g.
distribution of signed file), it's pretty much useless.
2) You can never ever use same entropy twice. So you will need to save
some kind of pointer where the last used entropy is. And when all
entropy was used we're back at square one. It's possible to save the
random number generator state instead but then random number isn't often
reseeded and so the smallest flaw in its algorithm is relatively easily
usable.
>   Maybe in combination with real-time clock, 
Point of random numbers is being unpredictable. RTC is predictable as a
clock.

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



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

GRUB and network (Re: GRUB and Google Summer of Code)

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

Alex Zanetti de Lima wrote:
> We discussed that with Vladimir, who pointed out the following drawbacks:
> 1) Current implementation was BOOTP/TFTP only. No support for other protocols.
> 2) Almost no shared code between architectures.
> 3) 100% dependent on OFW.
>
>   
And it messed up with memory allocation since there is no way of
requesting only portion of file or know file size
> We are now working on a network infrastructure that could be shared by all 
> platforms, including protocols, device drivers, etc. Gpxe project is a good 
> start point, and most of things are being developed based on it.
>
> Chances are that we'll have something working on x86 soon, and then we'll start 
> adding support for PPC (access to PCI bus via OFW, VIO, device drivers for some 
> very specific cards like ehea, etc).
>
>   

It's nice to hear.
But pay attention to license: not every piece of gpxe code is
license-compatible with grub2.
I would like to make an infrastructure for networking part of grub
itself since gpxe doesn't help much with configuration routines (this
part needs to be rewritten because gpxe environment is very different).
But the drivers imported from gpxe are likely to go into grub-extras.
Also high-level protocols like http have to be enhanced in grub since
gpxe implementation doesn't support seek even if protocol and server does.
When you or Manoel want to share something you're welcome to upload to
people or branches. It will allow easier collaboration and public review.

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



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