2010-12...@22:57 Risto H. Kurppa
> If somebody steps forwared to take the existing information and put all of the
> repositories + downloads online somewhere (read-only) for historic reference,
> I'd be more than happy to provide the respective account/data.
>
> Regards,
> Harald
> --
> - H
At 23:38 +0100 29/12/10, Vinzenz Hersche wrote:
Glenn, i like to try this for a kernel.. it should need just be a patched
kernel (so need to recompile) and a loaded kernel or what do you think?
i don't know so much about cross-compile, but i like to learn it.. if also
someone else like to join t
Vinzenz Hersche writes:
> it should need just be a patched
> kernel (so need to recompile) and a loaded kernel or what do you think?
>
> ...a loaded module, of course.. sry, typo.. :)
I don't think grsec can be a separate module.
___
Openmoko communi
At 23:38 +0100 29/12/10, Vinzenz Hersche wrote:
Glenn, i like to try this for a kernel.. it should need just be a patched
kernel (so need to recompile) and a loaded kernel or what do you think?
i don't know so much about cross-compile, but i like to learn it.. if also
someone else like to join t
Hi, Vinzenz
Just get kernel matching your distro, add your favorite patch and
rebuild. You may use almost any armel toolchain. In fact only sources
used in particular distro are different, but you may find it on site of
your favorite distro.
You may join irc on freenode, #openmoko channel if you
В Срд, 29/12/2010 в 23:28 +0100, Glenn пишет:
> At 0:06 +0200 30/12/10, Timo Juhani Lindfors wrote:
> >Glenn writes:
> >> Maybe it might be a good idea to embed grsecurity in the kernel - for
> >> two reasons:
> >
> >I think the main goal should be to upstream our changes, not add new
> >changes
Glenn writes:
>>What has grsecurity to do with debugging?
>
> On there home page they write:
>
> # Prevention of arbitrary code execution, regardless of the technique
> used (stack smashing, heap corruption, etc)
> # Prevention of arbitrary code execution in the kernel
> # Randomization of the sta
At 0:06 +0200 30/12/10, Timo Juhani Lindfors wrote:
Glenn writes:
Maybe it might be a good idea to embed grsecurity in the kernel - for
two reasons:
I think the main goal should be to upstream our changes, not add new
changes that are not upstream.
* Debug programs and drivers (faster de
On 17 December 2010 10:10, Al Johnson wrote:
> On Friday 17 December 2010, Timo Jyrinki wrote:
>>
>> Anyway, if one can come up with a perfect xorg.conf that disables the
>> extra devices there and only configures glamo + touch input + hw
>> buttons, that'd be nice.
What about the SHR xorg.conf?
Glenn writes:
> Maybe it might be a good idea to embed grsecurity in the kernel - for
> two reasons:
I think the main goal should be to upstream our changes, not add new
changes that are not upstream.
> * Debug programs and drivers (faster debugging?)
What has grsecurity to do with debugging?
Maybe it might be a good idea to embed grsecurity in the kernel - for
two reasons:
* Debug programs and drivers (faster debugging?)
* Heighten security
?
Have no idea how the performance impact might be.
http://grsecurity.net/
Quote: "...
[02/10] Official grsecurity/PaX support on ARM
[01/25
See below.
r
-- Forwarded message --
From: Harald Welte
Date: Wed, Dec 29, 2010 at 1:00 PM
Subject: Re: openmoko.org services / projects is now down..
To: "Risto H. Kurppa"
On Wed, Dec 29, 2010 at 12:41:47PM +0200, Risto H. Kurppa wrote:
> Hi Harald!
>
> There has now been som
giacomo mariani writes:
> You can achive a "similar" result using editUenv.sh from
> http://code.google.com/p/edituenv/ (also based on devirginator).
That seems to use uboot-envedit which is not in Debian. I'd rather use
the established fw_setenv tool.
>> > Please tell me how to do this! I have no religious bind to Qi. To
>> > hell
>> with minimalism, let us all use the bootloader that is standard,
>> smart, configurable and well supported.
>>
>> I think easiest way is to use fw_setenv. I rethought, need relatively
>> trivial modification to u-b
14 matches
Mail list logo
