Re: child protection + anti-cheating

[Carl-Daniel Hailfinger]

Hi Carlos,

On 11.01.2009 05:25, Chris Ball wrote:
>> How do we protect children from accessing porn or other
>> questionable content, and how do we prevent malicious persons from
>> communicating with kids, like say, child predators in IRC?
>
> You can't prevent this, if you also want to provide Internet access.
>   

Absolutely agreed.

By the way, a recent sociological study found out that children with
access to unmonitored internet chat are less is danger of becoming
victims of child predators.
Although that sounds strange at first, it it obvious once you consider
the fear of real-world child predators that someone might become aware
of what they do. The "risk" that children tell their online friends
about such predatory behaviour works as a pretty effective deterrent for
real-world predators (which are a much bigger group than online predators).
I can try to dig up that study if you need it for communication with
officials.


>> How do we prevent cheating between students?
>
> You can't prevent this.
>
>> Like instant messaging each other during quizzes?
>
> The easiest way would be to have the teacher stand at the back of the
> class looking for anyone doing so.  If network access is not needed
> during the quiz, you could also [...] turns off the wireless radio
>   

That would work, but kids are smart enough to turn wireless back on and
make the LED light ineffective (with paint/mud). And even if you can
prevent that, the kids can use the camera to look back over their
shoulder and check whether someone is watching them and cheat by
conventional means.

Besides that, there's always the possibility of storing a cheat sheet on
the laptop itself. Good luck trying to find that. A solution for that is
to unpredictably exchange laptops between kids directly before a test,
but it runs against the ownership paradigm.

Someone with enough time and/or money can always cheat. In many
countries, kids have some free time and learning to cheat is probably
the topic with the strongest motivation.

You can't prevent cheating, but you can make it difficult enough that
most kids won't bother.


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Way to tell if it is an XO

[Carl-Daniel Hailfinger]

Hi,

On 09.12.2008 22:37, Chris Ball wrote:
>> Hello, I need to know what is a good way to find out if the local
>> machine running a python script is a XO.
>
> One way might be to "cat /ofw/model".  If the file doesn't exist, or
> doesn't return a letter and number, you probably aren't running on an
> XO.
>
>> The goal is to check it the machine running the program is in fact
>> an XO or some other machine, and to do it in a way that is very
>> hard to fake from some other computer.
>
> I don't think making this hard to fake is possible, because any computer
> with root access can reply to your test in whatever way is necessary.
> I think you probably shouldn't try to accomplish this, or should try to
> use a different method such as a pre-shared credential.
>   

Yes, regardless of which test Marcel implements, it should be easy to
fool the test in a few minutes.


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: The XO laptop gets a Windows makeover

[Carl-Daniel Hailfinger]

Hi Robert,

On 27.10.2008 00:57, [EMAIL PROTECTED] wrote:

> On Oct 26, 2008, at 4:09 PM, Albert Cahalan wrote:
>
>   
>> Booting both into Windows would allow file sharing.
>> Compared to what Sugar does, file sharing is very reliable.
>> It works with **all** programs, without any developer effort.
>> It's compatible between different software versions, different
>> types of software, and even different OSes. It even eliminates
>> the need to maintain a continuous network connection, which is
>> great for kids without wired networks or reliable electricity.
>> 
> As for Windows file sharing I could show you situations in which  
> Windows file sharing fails miserably and

You conveniently claim that you *could* show situations where file
sharing fails miserably, but then you leave out the actual description
of any of these situations. I don't doubt they exist, but in general
Windows file sharing works really well for a rather large number of users.
And I'm fairly confident that sharing (copying/reading/writing)
arbitrary files reliably even in the face of intermittent network
outages is a quite useful capability to have.


>   contrary to what you state  
> Windows file sharing is not compatible between all operating  
> systems.

And here you're refuting a straw man. Nice fallacy. Note how Albert
wrote about "different OSes" and not your "all operating systems" straw man.


> A few of your statements are so bizarre they don't even  
> deserve a response.
>   

You missed the opportunity to actually point out which statements you
consider bizarre. No justification of your statement is given. That
allows anyone to invoke that statement on select yet unspecified parts
of your e-mail.


> Means of file sharing can be setup fairly easily in Sugar if you want  
> to move raw files around. Currently file sharing is performed through  
> activity sharing.
>   

Does "setup fairly easily" mean someone has to write a program
("activity") to do it? If yes, it's not easy (yet). Will it work with
arbitrary binary files? If not, it's just as sensible as people loading
a file into MS Word and saving it at some destination instead of simply
copying the file over. I have seen that, and while I admire the
creativity inherent in that action, it is slower and forces users to
look at the contents of the file which may not be desirable. And yes,
I'm going to give you an example: If someone shares an image via the
paint program ("activity") with you and you find the image offensive,
your only way to show/share that with the teacher is to look at the
image again.

Anyway, I am looking forward to your enlightened and detailed response.


Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Announcing OFW Q2E18

[Carl-Daniel Hailfinger]

On 17.09.2008 08:22, Mitch Bradley wrote:
> http://wiki.laptop.org/go/OLPC_Firmware_q2e18
>
> This is the version that we hope to include in the 8.2 software bundle, 
> so please test it like crazy.
>
> It won't brick B2s ...
>   

Thanks for fixing this bug! Any chance you can give an assessment about
B1 for this firmware?

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Recovery connector?

[Carl-Daniel Hailfinger]

On 16.09.2008 18:26, Mitch Bradley wrote:
> E-series firmware prior to q2e17c will brick B2, as indicated by the 
> bright red warnings at http://wiki.laptop.org/go/Firmware .
>   

Could you perhaps add a warning for B1 as well (if appropriate)?

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Power-on to GUI in 20 seconds

[Carl-Daniel Hailfinger]

On 29.08.2008 22:19, Edward Cherlin wrote:
> I also want to see Open Firmware replace proprietary BIOSes
> everywhere. In fact, I would like to see OFW-only embedded systems,
> since FORTH is designed for that environment. (I am assuming that
> Mitch can add real-time capabilities to OFW, and that a variety of
> development environments are available for such systems.) Or perhaps
> OFW/Parrot hybrids. I don't know. It's Free Software, folks, what do
> you want to implement today?
>   

It's free software, so you get to choose from multiple free firmware
implementations for x86, some in C, some in Assembler, some in Forth:
- Open Firmware (Forth)
- Smart Firmware (C, compiles to Forth)
- U-Boot (C, ASM)
- coreboot v2/v3 (C)
- LinuxBIOS v1 (C, ASM)

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: A-board

[Carl-Daniel Hailfinger]

On 18.08.2008 17:25, Richard A. Smith wrote:
> Victor Lazzarini wrote:
>   
>> I have an A-board in my office which I would like to bring back to
>> life if possible.
>> 
>> Any suggestions?
>> 
>
> You are running an ATest that was never upgraded from Insyde bios.
>
> If you set the RTC clock back then you can re-establish your eval period.
>
> There are instructions on the wiki for upgrading an ATest from Insyde to 
> OFW but you will have to dig.  Basically you build a bootable usb disk 
> and then use the 'olpcflash' utility to re-flash your firmware image. 
> The olpcflash repo is on dev.l.o.  You will need to build it static.
>
> A further complication is that we dropped support for ATest in the EC 
> code a long time ago.  So you will have to dig through the Firmware page 
> and find the last firmware that supports Atest.
>   

And please check the RAM. Some A-Test boards (including mine) have RAM
which needs a special image. Look for "CL 2.5" in the wiki.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: OFW sad face doesn't say why

[Carl-Daniel Hailfinger]

On 21.07.2008 11:53, Ivan Krstić wrote:
> On Jul 19, 2008, at 9:36 PM, John Gilmore wrote:
>   
>> But a certain former
>> security wizard at OLPC removed that recommendation from the Wiki
>> page, thus leading to your current troubles.
>> 
>
> This is untrue; please support your claims with diffs. As per:
>
>   
>  >
>
> I removed the line 23 suggestion for one to immediately _get_ their  
> devkey, nothing else.
>   

Sorry, but that's untrue, unless your definition of "nothing else" is
"political stuff". That very changeset made by you also had political
edits. I would have fallen for your claim if you had not linked to the
changeset which disproves it. If there was any other context attached to
"nothing else", you failed to make that clear. (And as a security guru,
leaving ambiguities is not exactly good practice.)


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Motherboard images

[Carl-Daniel Hailfinger]

On 13.07.2008 09:14, John Watlington wrote:
> I posted some annotated photos of the production XO motherboard on  
> the wiki at:
> http://wiki.laptop.org/go/XO_Motherboard
> http://wiki.laptop.org/go/XO_Motherboard_Repair
>   

I believe the SPI EEPROM is 1 MByte, not 1 Mbit.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: SuperUser permission for the Driver??

[Carl-Daniel Hailfinger]

On 25.06.2008 08:07, Michael Stone wrote:
> We have an activity that wants superuser privilege in order to poke
> kernel memory.
>   

Hello? Please take the poor activity out back and shoot it. No activity
has any business poking kernel memory.

> The real questions we should be attempting to address here include:
>
> * Who is granting privilege to this activity?
>   

Everybody who wants to ridicule the security model.

> * How are they doing so?
>
> * How should we record the decision?
>
>  -  My tentative answer is that we should store activities with
> different security properties in well-known directory chains
> with appropriately restricted write access.
>
> * What kinds of abuse are these mechanisms vulnerable to?
>
> * Whose responsibility is it to handle the error condition that the
>   human operator does not, him-or-herself posess superuser privilege,
>   e.g. for theft-deterrence reasons?
>   

Just say no.

Having an activity poke kernel memory is a really strong sign that the
interface is totally broken.

Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: How USB's are enumerated on the XO

[Carl-Daniel Hailfinger]

On 23.06.2008 20:29, Jim Gettys wrote:
> While in theory, USB devices can/should send serial numbers, that part
> of the spec is honored mostly by it's absence (due to cost).
>
> As John said, unfortunately, with USB you have to go down to the device
> and see if they have something usable to distinguish devices.
>   

The easiest way to achieve this on USB flash disks is to store a file
with a UUID on each disk upon first insertion.

Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Manufacturing tags

[Carl-Daniel Hailfinger]

On 17.06.2008 22:26, John Watlington wrote:
> As replacing the SPI flash becomes a more regular
> occurence,

Ouch. Do you have any further pointers about that?

> reinstalling the manufacturing tags is becoming a problem.
>
> What tags are absolutely essential for our software to operate ?
>
> These are:
> SN  (serial number)
> U#  (uuid)
>
> What about these ?:
> LO   (C locale)
> KL   (keyboard layout)
> LA   (country code)
> KA   (Keyboard ASCII map)
> KV   (keyboard variant)
> WM  (wireless module MAC)
> SG  (motherboard rev)
> B#   (motherboard number)
>
> As every essential tag must be typed in, with a reboot between
> each, I would like to minimize the number of tags I restore.
>   

Minimizing the number of reboots would be the way to go.


Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [OLPC Security] Bitfrost and dual-boot

[Carl-Daniel Hailfinger]

On 30.05.2008 08:34, Albert Cahalan wrote:
> On Fri, May 30, 2008 at 1:15 AM, Edward Cherlin <[EMAIL PROTECTED]> wrote:
>   
>> On Thu, May 29, 2008 at 8:45 PM, Albert Cahalan <[EMAIL PROTECTED]> wrote:
>> 
>>> On Thu, May 29, 2008 at 5:07 PM, Edward Cherlin <[EMAIL PROTECTED]> wrote:
>>>   
>>>
 Also, I think you completely misunderstand the market. The ability to
 use Open FirmWare instead of a proprietary BIOS will be of intense
 interest to all PC vendors. I expect OFW to sweep through most of the
 market in no more than two or three years.
 
>>> I can't imagine why. LinuxBIOS (now coreboot) didn't.
>>> Even EFI didn't. Your wishes are not their wishes.
>>>   
>> Albert, I'm not talking to you any more until you start making sense.
>> Linux BIOS never booted any Windows other than 2000 (with ADLO), and
>> 

That's not really true. coreboot (former LinuxBIOS) does boot XP and
Vista with the right payload. I should know it, I'm one of the coreboot
developers. Granted, that knowledge is not spread far and wide.

>> EFI isn't Open Source.
>> 

That's not entirely accurate. There are EFI implementations which are
Open Source, but EFI is just a presentation layer and performs no
hardware init, so you're back to square one.

> You think the PC vendors care that EFI isn't Open Source?
> You think the PC vendors care that BIOS isn't Open Source?
> Really, they have NO desire for Open Source firmware.
>   

Indeed. Some companies say that any public code for hardware init poses
a threat to their intellectual property and/or is baaad for various
made-up reasons.

> That's your desire, not theirs. Do not assume they think like you.
>   

I can tell you how many hardware vendors think:
- Does it reduce cost? If not, scratch the idea.
- Does it make the lawyers nervous? If yes, scratch the idea. In
general, lawyers of hardware vendors get nervous once somebody suggests
to publish anything, regardless whether the content is obvious or not.
- Is it still compatible with DOS and any and all legacy operating
systems ever invented (including Windows 95/98/ME)? If not, scratch the
idea unless your intended market (high-end gaming rigs or somesuch) will
never want that compatibility. This is evident from the mainboards you
can actually buy with EFI.


Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: XO-2

[Carl-Daniel Hailfinger]

On 23.05.2008 21:37, Richard A. Smith wrote:
> Carl-Daniel Hailfinger wrote:
>
>> As I stated before on this list, bypassing P_THEFT is very easy. You
>> don't even have to desolder the complete flash chip, one pin is
>> sufficient. All of this is doable for less than $1 per laptop if you
>> have access to cheap labor. $1 per laptop is _not_ expensive enough to
>> be infeasible. I am very willing to publish a video tutorial of the
>> procedure if you think I can't do that. The only downside would be that
>> everybody then knows how to bypass P_THEFT.
>
> If you want to tell me your procedure in private I'll be happy to
> review  it for you.  IMHO we actually do need people to challenge what
> we have done.  Tis' the only real way to know.
>
> I'm guessing the single pin you are referring the the flash write
> protect pin? If so then I'll note thats actually not where the
> strongest part of the link is.  Very early on we also disable the
> ability to talk to the io ports on the EC that make writing to the SPI
> flash possible. Once they are disabled you can't talk to the EC
> anymore to re-enable them. You have to reset the EC. So far we have
> not found a method that circumvents that.

I didn't know about the disabled IO ports (nice idea BTW), but
fortunately my procedure requires little EC cooperation and will work
even with that measure in place.

>   Fire away.
>
> Please give us the chance to fix it first if you do find something.  :)

OK, will do so via private mail.

Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: SSH DSA logins on crank.

[Carl-Daniel Hailfinger]

On 23.05.2008 17:15, Holger Levsen wrote:
> On Tuesday 20 May 2008 15:50, Carl-Daniel Hailfinger wrote:
>   
>> I claim [...]
>> 
>
> And you were right.
>   

Thanks for checking my math.

Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: SSH DSA logins on crank.

[Carl-Daniel Hailfinger]

Hi,

On 23.05.2008 17:16, Holger Levsen wrote:
> On Wednesday 21 May 2008 16:06, Chris Ball wrote:
>   
>> Yes.  We have the openssh-blacklist package installed, which contains
>> keyhashes of all possible weak keys and disallows logins using them.
>> 
>
> AFAIK not all possible weak keys, but only for the most popular arches and 
> (definitly only) the popular key lengths.
>   

Holger is right about the blacklist being a useful strict subset of all
weak keys.
The good news is that ssh_keygen only allows 1024 bit DSA keys (the man
page says: "DSA keys must be exactly 1024 bits as specified by FIPS
186-2.").

Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: XO-2

[Carl-Daniel Hailfinger]

On 22.05.2008 17:01, C. Scott Ananian wrote:
> On 5/22/08, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote:
>   
>>  >  h) hardware-protected RTC (bitfrost desiderata)
>> I'd be very interested in the reasons for that. P_THEFT is still mostly
>>  unimplemented for cost reasons. A hardware-protected RTC will not
>>  improve the current state at all as long as the hardware side of P_THEFT
>>  is not implemented. It will certainly raise cost, though.
>> 
>
> Not the case: epoxy-coating the motherboard was not cost-effective,
> meaning that the cost of bypassing P_THEFT by circuit-board changes
> was already expensive enough to be infeasible -- and of course epoxy
> adds to manufacture, repair, and rework costs.  The economics weren't
> with it.
>   

As I stated before on this list, bypassing P_THEFT is very easy. You
don't even have to desolder the complete flash chip, one pin is
sufficient. All of this is doable for less than $1 per laptop if you
have access to cheap labor. $1 per laptop is _not_ expensive enough to
be infeasible. I am very willing to publish a video tutorial of the
procedure if you think I can't do that. The only downside would be that
everybody then knows how to bypass P_THEFT.


> We actually know exactly how much it costs to bypass P_THEFT in bulk,
> since some of original manufacture run ended up with a firmware bug
> which bricked them in exactly the way P_THEFT would.
>   

If you came up with a cost of more than $2, the recovery/bypass was
missing the obvious shortcuts or you had a requirement not to solder.


> Hardware-protected RTC helps with the security of ongoing
> theft-deterrence, which is orthogonal to initial activitation security
> (which it seems you are discussing).

Agreed on the orthogonality.


> Contrary to your claim, initial
> activation security is being heavily deployed and does seem to be
> successful.
>   

A statement of security is a nice theft deterrent. This may change once
the bad guys realize circumvention is very doable.


>>  >  i) better protection for firmware FLASH, to avoid the possibility of
>>  > bricking a machine if the power is removed at the wrong time.
>>
>> Protection for firmware flashing against bricking is easy if the flash
>>  chip is big enough. OTOH, performing an update of EC microcode is a much
>>  more difficult thing to protect against failure.
>> 
>
> Yes, there were some design details with Gen 1 hardware that turned
> out to make it difficult to safely reflash, even though the flash chip
> is big enough to accomodate a backup OFW.  The EC is perfectly capable
> of recovering OFW, but the EC memory map coincides with the erase
> block size of the SPI flash, unfortunately, so there's a critical
> window during which all of the EC code must be erased.  We hope to fix
> that with Gen 2.
>   

There are SPI flash chips on the market which have an erase granularity
of half the size of the EC code or even less. Selecting such a chip
should work even for Gen 1 unless I'm missing a key detail.


>>  >  k) more open software: we may not need an EC, and if we do we may be
>>  > able to ensure its code is open.  We may change the wireless device,
>>  > and/or be able to switch to open firmware for it.
>>
>> I believe item k) was already in the contracts with Quanta and Marvell,
>>  unless the official announcements back then were wrong. It has been
>>  stated repeatedly by OLPC officials that the only thing preventing a
>>  full open source wireless firmware is the lack of time for porting the
>>  code to another embedded OS. There were also statements like "We are
>>  working with Quanta to release EC source code", so I think that's also
>>  mostly a problem with lack of time.
>> 
>
> Yes, it was intended, but the production schedule and component
> availability forced us to build on some pre-existing closed-source
> components, and now that we've reached this point in the manufacturing
> cycle for XO-1, we have very little leverage left with Quanta.  We did
> make our best effort, but there were also some unforeseen interactions
> with the manufacturing contract we signed with Quanta.  Quanta
> designed the motherboard and took responsibility for making
> modifications for manufacturability and to address defects, and now
> they've ended up with significant IP rights in our schematic.  This
> has made it hard to properly support the open EC effort, since by the
> terms of the contract we can't even show them the pinout of the EC.
> We recently hired Paul Fox as firmware engineer, so we're still hard
> at work on this.  We hope that we can work out agreements w

Re: XO-2

[Carl-Daniel Hailfinger]

On 22.05.2008 15:38, C. Scott Ananian wrote:
> I'm not on the hardware team, so this is just a wild guess:
> [...]
> Some other features that have been discussed:
>  d) GPS (unknown whether this will be able to make the cost budget)
>   

This is not only a cost problem, but also a big power drain problem.
Besides that, GPS and GALILEO are similar enough that some manufacturers
claim they can support both with a software update. If a machine is
sitting in a deep valley, getting enough satellites into view for even
an inaccurate a position fix is a real challenge with only one satellite
fleet. Of course, having GPS in a school server will allow kids to
locate themselves on a world map with reasonable accuracy. Not perfect,
but better than nothing.

>  h) hardware-protected RTC (bitfrost desiderata)
>   

I'd be very interested in the reasons for that. P_THEFT is still mostly
unimplemented for cost reasons. A hardware-protected RTC will not
improve the current state at all as long as the hardware side of P_THEFT
is not implemented. It will certainly raise cost, though.

>  i) better protection for firmware FLASH, to avoid the possibility of
> bricking a machine if the power is removed at the wrong time.
>   

Protection for firmware flashing against bricking is easy if the flash
chip is big enough. OTOH, performing an update of EC microcode is a much
more difficult thing to protect against failure.

>  j) more open hardware design (schematic) -- this is really a
> contractual issue with the manufacturer
>   

This would certainly be cool.

>  k) more open software: we may not need an EC, and if we do we may be
> able to ensure its code is open.  We may change the wireless device,
> and/or be able to switch to open firmware for it.
>   

I believe item k) was already in the contracts with Quanta and Marvell,
unless the official announcements back then were wrong. It has been
stated repeatedly by OLPC officials that the only thing preventing a
full open source wireless firmware is the lack of time for porting the
code to another embedded OS. There were also statements like "We are
working with Quanta to release EC source code", so I think that's also
mostly a problem with lack of time.

Please correct me if I'm wrong.

Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: SSH DSA logins on crank.

[Carl-Daniel Hailfinger]

On 21.05.2008 15:12, Ivan Krstić wrote:
> On May 21, 2008, at 5:58 AM, Carl-Daniel Hailfinger wrote:
>> OK, but then a statement from the user like "I never logged in anywhere
>> from a Debian/Ubuntu system" should suffice to reenable the existing
>> key.
>
> Given the trivial cost of generating a new RSA key and the high
> fallibility of human memory, it's not at all unreasonable to err on
> the side of caution as Chris has done.

So DSA is a no-go from now until the end of time?

Chris Ball wrote:
>>> Please mail [EMAIL PROTECTED] if you were using a DSA key that you
>>> now need to replace.
>>>   

I interpreted the statement above as "replace with a RSA or new DSA
key". Ivan, you seem to interpret it as "replace with a RSA key". Since
Chris wrote he disabled logins with DSA keys, I guess you're right.
Thanks for clarifying.

By the way, will remaining and new RSA keys be tested for bad randomness?

Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: SSH DSA logins on crank.

[Carl-Daniel Hailfinger]

On 21.05.2008 14:36, Gary Oberbrunner wrote:
> Carl-Daniel Hailfinger wrote:
>> What happens to those who never logged in *from* a Debian/Ubuntu
>> machine? There's no reason to not let them keep their DSA key.
>
> The point, iiuc, is that if even one such key was sniffed, crank is
> compromised.  At least that user's account, which is dangerous enough.

OK, but then a statement from the user like "I never logged in anywhere
from a Debian/Ubuntu system" should suffice to reenable the existing key.

Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: SSH DSA logins on crank.

[Carl-Daniel Hailfinger]

Hi Chris,

On 19.05.2008 17:02, Chris Ball wrote:
> I've disabled logins with DSA keys on dev.laptop.org.  Turns out that
> while your RSA key is only vulnerable if *created* on a weak Debian or
> Ubuntu machine, your DSA key is vulnerable if *used* on Debian/Ubuntu¹,
> due to DSA having a greater reliance on randomness.
>
> Please mail [EMAIL PROTECTED] if you were using a DSA key that you
> now need to replace.
>   

What happens to those who never logged in *from* a Debian/Ubuntu
machine? There's no reason to not let them keep their DSA key. The PRNG
on the target host doesn't even appear in the DSA signature creation
calculations and therefore is irrelevant to DSA key security.


Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: SSH DSA logins on crank.

[Carl-Daniel Hailfinger]

Hi,

On 20.05.2008 14:30, Holger Levsen wrote:
> On Tuesday 20 May 2008 14:13, Carl-Daniel Hailfinger wrote:
>   
>>> Not by copying to, but by using with, yes, unfortunatly.
>>>   
>> Sorry, "using with" is very imprecise language and leads many people to
>> the wrong conclusion.
>> 
>
> If you think that "using" was confusing here, you should probably also remove 
> the confusion by suggesting a better word. I still think "using" is correct 
> here.
>
>   
>>> Read http://blog.sesse.net/blog/tech/2008-05-14-17-21_some_maths.html -
>>> in short, if the randomness is not really random, DSA can be attacked
>>> rather easily. That's why debian.org and freedesktop.org don't allow DSA
>>> keys at all anymore.
>>>   
>> Everybody points to the blog entry, but nobody seems to read it. The
>> entry states that if you used the private DSA key on a Debian/Ubuntu
>> machine for login to another machine, it might be compromised. 
>> 
>
> You haven't understood the entry.
>   

I claim you didn't understand.

> Let me quote the relevant bit:
>
> "For instance, Applied Cryptography (Schneier) says (thanks to Peter 
> Palfrader 
> for digging up the quote): Each signature requires a new value of k, and that 
> value most be chosen randomly. If Eve ever recovers a k that Alice used to 
> sign a message, perhaps by exploiting some properties of the random number 
> generator that generated k, she can recover Alice's private key, x. If Ever 
> ever gets two messages signed using the same k, even if she doesn't know what 
> it is, she can recover x. And with x, Eve can generate undetectable forgeries 
> of Alice's signature. In any implementation of the DSA a good random-number 
> generateor is essential to the system's security."
>   

Right, the random number generator on the sender side (the one where the
private key is stored) generates k. The random number generator on the
receiver side doesn't even appear in signature generation..

>> Short version: The
>> combination of bad random numbers and a private DSA key on the same
>> machine is harmful.
>> 
>
> Wrong, also the combination of a bad random numbers and a public DSA key has 
> to be considered harmful. If someone sniffed your traffic (which you have to 
> consider), you have to consider your DSA keys to be compromised.
>   

Recovering k is harmful. k is generated by the machine where the private
key is stored.

Please tell me where exactly you see the random number generator of the
destination host to have any influence on generation of k.

If k were generated by the receiving host, Bob would always be able to
recover Alice's private key and we'd call DSA a symmetric key algorithm,
not a public/private key algorithm.

Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: SSH DSA logins on crank.

[Carl-Daniel Hailfinger]

On 20.05.2008 13:31, Holger Levsen wrote:
> Hi,
>
> On Tuesday 20 May 2008 04:08, Bernie Innocenti wrote:
>   
>> Hopefully this doesn't mean that the _private_ DSA key can be
>> compromised if the _public_ key was copied on a Debian/Ubuntu machine.
>> 
>
> Not by copying to, but by using with, yes, unfortunatly.
>   

Sorry, "using with" is very imprecise language and leads many people to
the wrong conclusion.

> Read http://blog.sesse.net/blog/tech/2008-05-14-17-21_some_maths.html - in 
> short, if the randomness is not really random, DSA can be attacked rather 
> easily. That's why debian.org and freedesktop.org don't allow DSA keys at all 
> anymore. 
>   

Everybody points to the blog entry, but nobody seems to read it. The
entry states that if you used the private DSA key on a Debian/Ubuntu
machine for login to another machine, it might be compromised. Logging
in to a Debian/Ubuntu machine does no harm. Short version: The
combination of bad random numbers and a private DSA key on the same
machine is harmful.


Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: An OLPC Development Model

[Carl-Daniel Hailfinger]

On 10.05.2008 00:13, Bert Freudenberg wrote:
> On 09.05.2008, at 20:31, [EMAIL PROTECTED] wrote:
>   
>> Bert,
>>  if you try and say that the entire world is wrong in how it writes  
>> software,
>> 
>
> Actually, that's exactly what I think, and "entire world" includes  
> yours truly ;)
> But this isn't the place to talk about that (if you're curious, visit  
> VPRI [*]).
>
> No, it's not foremost about how the software is written, but about how  
> it is presented to the user. Unfortunately, interface design is much  
> harder than just writing software.
>   

The VPRI stuff is scary because it proposes the equivalent of using
assembler code to speed up C programs. Performing model checking against
one piece of code, then replacing that piece of code with another one
for speed reasons in production is really a horrible plan. It also makes
it obvious that the mathematically correct code is expected to be
unusably slow.


> [...]
> For example, the fastest way for me to retrieve a file is typing it in  
> the system-wide search box on my machine, or into google. It doesn't  
> matter where in the file system hierarchy or on which server it is  
> stored. That is pretty much what the Journal would do, too. Also, the  
> Journal will allow tagging, which is equivalent (but more powerful) to  
> a directory hierarchy. Etc.
>   

Actually, tags are just the equivalence of file names and they are more
efficient to use than simple searches. If you know exactly what you want
and where to find it, searching for it is one of the worst choices
possible besides random walking and active avoidance. With
Mozilla/Firefox/Seamonkey, typing in the first few letters of the URL
takes you faster to an often-used site (due to autocompletion) than
using any search engine. In real life, searching is a last resort if
direct access is impossible. If you keep your bike at a fixed location
you can remember among other bikes in a bike shed, you walk straight to
your bike and don't search for it.


> [*] see http://vpri.org/html/work/ifnct.htm
>   

Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: CIPA done

[Carl-Daniel Hailfinger]

On 08.05.2008 22:29, Joshua N Pritikin wrote:
> On Thu, May 08, 2008 at 04:16:48PM -0400, Tom Hoffman wrote:
>   
>> On Wed, May 7, 2008 at 4:24 PM, Joshua N Pritikin <[EMAIL PROTECTED]> wrote:
>> 
>>> I believe we MUST error on the conservative side, especially for 
>>> American deployments.
>>>   
>> If you're sending home user modifiable wifi-capable computers with
>> kids, you're already a long way from the conservative side of the
>> issue in the US.  Playing it safe, in this case, means pretty much
>> dropping the entire project.
>> 
>
> All the more reason to error on the conservative side. There probably 
> will be sites which reject OLPC for precisely this reason.

This is getting completely ridiculous. You want "to error on the
conservative side". Fine. Simply refuse all connections to the outside
and those conservatives you are so afraid of will be happy. Maybe you
should disable connections inside the mesh as well. One kid could load
an inappropriate activity via USB storage and share it. That MUST be
prevented! While we're at it, filling the USB slots and the SD slot with
epoxy should keep you happy and those conservatives would probably
rejoice (at least that's the impression I get from your statements.)

> However, we must try to get away from all-or-nothing
> thinking with regard to censorship.
>   

Right. Your suggestions contradict that point, though.

An acceptable middle ground for you would probably be software which
mangles the US constitution like this: "Congress shall make no law
abridging the freedom of sXXXch, or the right of the people peaceably to
XXXemble, and to peXXXion the government for a redress of grievances."
(with apologies to the EPIC)

Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: NYC schools and cloaked APs

[Carl-Daniel Hailfinger]

On 05.05.2008 12:24, Morgan Collett wrote:
> On Sat, May 3, 2008 at 10:58 PM, Bert Freudenberg <[EMAIL PROTECTED]> wrote:
>   
>> On 03.05.2008, at 21:48, Carl-Daniel Hailfinger wrote:
>>  > I was completely surprised when I read that NetworkManager is needed
>>  > to
>>  > boot into sugar. I can't think of any scenario where that dependency
>>  > would make sense.
>>
>>  Sugar works fine in jhbuild without NM, including collaboration via
>>  the "mesh view" (no access points visible, but xo kid icons). I'd be
>>  surprised if it didn't on the XO.
>> 
>
> Presence Service will only attempt to connect to a jabber server if it
> sees Network Manager get a valid IP address. Without that, you only
> see the salut / link local collaboration, which works for <10 XOs on
> the mesh.
>   

Wait a second. Presence Service requires NetworkManager instead of
requiring a valid IP address?


Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: NYC schools and cloaked APs

[Carl-Daniel Hailfinger]

Hi,

On 03.05.2008 16:52, Ricardo Carrano wrote:
> While the support is not there, NYC is considering disabling NetworkManager
> but this is not a good solution for (1) the XO will not boot into sugar and
>   

That would be a bug.

> (2) collaboration will not work, because the mesh view will be broken.
>   

That would be a bug as well.

> They are interested in a way (quick workaround) of doing the configuration
> manually in a persistent manner and still be able to collaborate. Any ideas?
>
> Btw, note that:
> - Manually editing networks.cfg won't work because the scanning (the
> blinking icon phase in the mesh view) is passive. So, if the AP do not
> broadcast its SSID it is like it is not there.
> - Manually associating  to the AP would work but NetworkManager prevents
> dhcp from working.
>   

It should be possible to manually associate with the AP, then kill
NetworkManager with SIGKILL so it can't mess things up during
termination. After that, dhcp should no longer present a problem.

> I have a feeling that enabling support to cloaked APs may be quicker than
> hatching a workaround, but to do it fast we would need help in the NM part.
>   

I was completely surprised when I read that NetworkManager is needed to
boot into sugar. I can't think of any scenario where that dependency
would make sense.

Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Auto backlight management?

[Carl-Daniel Hailfinger]

On 25.04.2008 06:25, Ivan Krstić wrote:
> On Apr 24, 2008, at 10:39 PM, Frank Ch. Eigler wrote:
>   
>> Opportunistic use of the on-board camera and the time-of-day clock
>> could yield such heuristics.
>> 
>
>
> The camera lights up an LED when enabled, alerting the laptop operator  
> to its use. This privacy-preserving feature would be rendered  
> ineffective if kids got used to seeing the LED flash on and off every  
> so often as the system autonomously attempts to adjust the backlight.
>   


Is there a "warning time" period from activating the LED to activating
the camera? Just that when someone works in front of the laptop, can he
simply close it fast enough when the camera light goes on unexpectedly?


Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: A technical assessment of porting "Sugar" to Windows.

[Carl-Daniel Hailfinger]

On 24.04.2008 20:32, C. Scott Ananian wrote:
> 11. Bitfrost: initial activation security.
>
> Our deployment countries are very concerned with theft of XOs.  This
> item and the next address different mechanisms OLPC has designed to
> mitigate and manage this risk.
>
> "Initial activation security" means that an XO as delivered from the
> factory is a worthless brick.  It cannot be transformed into a
> functional machine without the use of an activation key, tied to the
> machine's serial number, which is generated by OLPC or the deployment
> country.  The goal of this feature is to deter theft-in-transit:
> activation keys and the XO hardware follow different paths to the
> target school, minimizing the value of the XO until it arrives in the
> hands of its child owner.
>
> Initial activation security is likely to be reasonably implementable
> on Sugar/Windows.  Mitch Bradley has been working on making Windows
> boot under OpenFirmware, and most of initial activation security is
> implemented in OpenFirmware's secure boot path.  The initial
> activation step currently involves booting a Linux kernel with a
> special ramdisk which validates activation leases and writes them to
> internal flash; this process could be used with only minor
> modifications to perform activation of Sugar/Windows machines.
>
>
> 12. Bitfrost: active and passive kill.
>
> Some countries want more aggressive anti-theft protection.  The terms
> of the GPL (as well as our own moral compasses) require us to allow
> the user to disable these mechanisms, but schoolkids who wish to keep
> them enabled gain some additional anti-theft protection.
>
> The theft-deterrence comes in two forms.  The first, passive kill,
> limits the lifetime of the initial activation lease (item #11).  The
> activation lease must be renewed periodically, or the machine reverts
> to the unactivated state.  A thief is guaranteed that a stolen machine
> will not be usable long.
>
> The vulnerability in this scheme is the real-time clock.  The XO
> hardware does not contain an hardware-protected clock (although we may
> be able to leverage firmware in the embedded controller to provide
> this), and so the burden of protecting the passive kill system from
> clock-reset attacks falls on the operating system.  It is rather
> difficult to secure Sugar/GNU/Linux against these attacks; it is
> unlikely that Sugar/Windows will ever be adequately secure.  (If we
> move to an EC-based implementation, then Sugar/Windows will require
> Windows kernel expertise in order to follow suit.)
>
> Active kill piggybacks on the update management system: when the XO
> performs a network transaction to look for an update, it may also be
> informed that it has been stolen, and immediately enter the
> deactivated state.  The obvious vulnerability is in the networking: an
> enterprising thief may conspire to prevent the XO from ever connecting
> to the theft-deterrence server.  A secondary vulnerability is in the
> daemon which periodically checks the theft-deterrence server:
> again, the burden falls on the operating system to protect that
> process from interference.  Again, this is difficult enough on
> Sugar/GNU/Linux; it is much more so on Sugar/Windows XP.
>
> For completeness, I will note that although passive and active kill
> theft-deterrence systems have been implemented on Sugar/GNU/Linux,
> only initial activation security has been deployed in the field.
> Passive and active kill systems entail large support costs which OLPC
> has chosen to date not to incur.
>   

AFAIK the hardware side of P_THEFT alias theft protection alias
activation security/kill functionality has not been implemented,
rendering all software efforts moot.

Unless the manufacturing details have changed since my last inquiry, I
can unlock ~4 XO machines per hour WITHOUT having a developer key. The
only thing I need are some really affordable tools. If someone else
disassembles the machines for me, I think unlocking 10 machines per hour
is well within the doable range.

For the record: I will not take orders for mass-unlocking unless
ownership is proven.


Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: A technical assessment of porting "Sugar" to Windows.

[Carl-Daniel Hailfinger]

On 24.04.2008 20:32, C. Scott Ananian wrote:
> 4. Journal and Datastore.
>
> One part of the zooming UI not discussed in item #3 (above) is the
> "Journal" view, the XO's replacement for the traditional "files and
> folders" metaphor.  Our current implementation is based on Xapian,
> which "compiles" on Windows (but perhaps not much more):
> http://lists.tartarus.org/pipermail/xapian-devel/2006-March/000311.html
>
> That said, our Journal and datastore are in need of a rewrite.  The
> current proposal (http://wiki.laptop.org/go/Olpcfs) is not
> incompatible with a Windows implementation, but the implementation
> strategies on Windows and GNU/Linux would likely be very different.
> The most straightforward course of action would be to have two
> completely separate implementations of the same API.  This course requires
> skilled Windows developers who are comfortable with NTFS reparse points
> and/or filesystem development on Windows.  Developing a single
> implementation which is cross-platform is likely more difficult.
>   

I looked at the OLPCFS page and it became very clear that OLPCFS is
virtually identical to what Reiser4 was initially designed to be. Almost
all of the listed OLPCFS features were present in the first Reiser4
designs and almost all were repeatedly vetoed by the Linux VFS guys (Al
Viro and Christoph Hellwig) for design reasons, not code reasons. So if
you want OLPCFS, try early Reiser4 snapshots (maybe for Linux 2.6.4 or
so) and add one or two features on top of it.

Sorry. I wish the idea would fly, but you may be in for some very tough
criticism if you intend to have anything with a concept like OLPCFS
merged in the Linux kernel.


Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Ad-hoc Networking

[Carl-Daniel Hailfinger]

On 24.04.2008 02:00, Ricardo Carrano wrote:
> (...)
>   
>> This isn't what I was talking about.  Forget about the mesh.  Ban it
>> from your mind.
>> (...) the troublesome Mesh and just live with the 802.11b/g,
>>
>> 
>
> "Ban  (...) the troublesome Mesh" you say. Sigh.
>   

You forgot to quote the "from your mind" part.

> There is not a single piece of software or hardware in any innovative
> project that wasn't or isn't "troublesome" at some point.
> What to we do? We just throw away every important aspect of the project so
> life is easier? I don't think so.
>   

Hey, the above paragraph can be quoted in a distorting way as well:
"There is not a single [...] important aspect of the project". Selective
quoting is fun, really. ;-)

We don't throw away every important aspect of the project, we simply
disable/ignore features as long as they don't work as expected. A
"feature" which is an obstacle without visible benefits to
users/developers has no inherent value.

> Let's drop suspend/resume, sugar and whatever is "troublesome"? Doubt it.
> Think about for a second. Why in the world a whole community of researchers
> worldwide have been investing a decade in mesh network development? Do you
> really consider the 802.11 ad-hoc mode an alternative? Because the IEEE
> itself does not.
> If you think about it you will end up adding relaying capabilities back.
> And I will repeat this one more time. The mesh works. Have you tried it?
>   

Looking at trac, wireless is one of the biggest sources of bugs and the
community can hardly do anything about it. Normally, somebody who
complains can be told to fix the code, but with a closed wireless
firmware, complaining is the only possible action.

Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Walter leaving and shift to XP.

[Carl-Daniel Hailfinger]

On 23.04.2008 03:09, C. Scott Ananian wrote:
> On Tue, Apr 22, 2008 at 8:58 PM, Mitch Bradley <[EMAIL PROTECTED]> wrote:
>   
>>  The laptops are even more wonderful with a child-friendly UI, loads of fun
>>  activities, and a non-proprietary software stack.  But in the steady
>>  state, the
>>  web is the high-order bit, sufficient to qualify as education in and of
>>  itself.
>> 
>
> But aren't we forgetting the connectivity aspect?  A laptop with a web
> browser and no web to browse doesn't seem to me to be very useful.
> The XO's promise for rural areas relies on its deployment strategy,
> mesh networking, and low power consumption.
>   

In theory, mesh networking is a feature of the wireless firmware and
should work fine regardless of operating system choice.

Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Walter leaving and shift to XP.

[Carl-Daniel Hailfinger]

On 22.04.2008 23:29, Ivan Krstić wrote:
> On Apr 22, 2008, at 5:25 PM, Edward Cherlin wrote:
>   
>> Who says Negroponte is shifting? Certainly not Walter in any of his
>> public posts. Can't happen. We would all be out of here like a shot  
>> to fork Sugar. Nicholas is weird, but not utterly stupid.
>> 
>
>
> "Eventually, Negroponte added, Windows might be the sole operating  
> system ... Negroponte said he was mainly concerned with putting as  
> many laptops as possible in children's hands."
>
> -- via Associated Press
> 

Thanks for digging up that quote. It confirms that this has become a
pure laptop project and not an education project as the official mission
states (stated?). Giving laptops to children is not an education
project, it's giving laptops to children.

Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Walter leaving and shift to XP.

[Carl-Daniel Hailfinger]

On 22.04.2008 23:25, Edward Cherlin wrote:
> On Tue, Apr 22, 2008 at 1:52 PM, Aaron Konstam <[EMAIL PROTECTED]> wrote:
>   
>> I always forget that when I reply the message does not go to the list.
>>  On the support-gang list there is quite a bit of discouragement over
>>  Walter leaving because Negroponte has decided to go the XP route with
>>  the XO. And he is in talks with MS$ to get a version of XP to run on the
>>  XO.
>> 
>
> I know about XP on the XO. Microsoft was working on it all last year.
> What's this about Negroponte shifting to XP? I know that there is a
> rumor about, but where I have seen it, it has just been a
> misinterpretation of the usual news. Negroponte is quoted,
>
> * OLPC chairman says laptop project could not promote openness if it
> was closed to Microsoft.
> * "Microsoft has always been working on Windows for the XO. We put the
> SD (secure digital) slot into our laptop over one year ago, for them."
>
> Who says Negroponte is shifting? Certainly not Walter in any of his
> public posts.
>
>   
>>  How may developers want to shift to developing for an XP based, rather
>>  than a sugar based , platform?
>> 
>
> Can't happen. We would all be out of here like a shot to fork Sugar.
> Nicholas is weird, but not utterly stupid.
>   

The big problem is that most people see this as a Linux+Sugar vs.
Windows decision. OLPC is simply fighting on too many fronts and new
developers generally do not tackle existing problems, but work on shiny
new features and reinvent the wheel.
I see a choice of at least:
- Linux + Sugar
- Linux + fast UI
- Windows XP lite (or whatever it is called)

My hope is that the second choice wins. If the first and the second
choice are identical some time in the future, even better!


Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [sugar] where is Walter?

[Carl-Daniel Hailfinger]

On 22.04.2008 02:13, Michael Stone wrote:
> What in this description of events leads you to the conclusion that OLPC
> is "shriveling up and dying"?
>   

Perhaps not shriveling up, but quite a few contributors/participants
from the early days (pre-A-Test till B2-Test) have left and the
perceived goals and principles of the project have changed considerably
as well.

The general climate is much less friendly to criticism, and I see the
recent USENIX paper debate as a prime example. That paper has been
criticised and ridiculed on various grounds instead of addressing the
issues it brought up. We claim to have stellar security based on the
official Bitfrost spec, yet lots of that spec are unimplemented.

Back in the old days, even strong criticism was seen as a way to improve
code and design. We had heated debates and decisions about
adding/removing features were done transparently with input from the
community.

I really miss that time.

But I see a chance to bring that culture back once the immense pressure
on the "core team" (for lack of a better name) diminishes and update.2
is released. Let's hope for the best.


Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: New faster build 1889

[Carl-Daniel Hailfinger]

On 21.04.2008 20:58, Marcus Leech wrote:
> Also, was the fact that it bricks your machine design intent?
>
> I'm sad now.
>   

Wrong kernel. Didn't we have recovery mechanisms for such situations?


Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: New joyride build 1889

[Carl-Daniel Hailfinger]

On 21.04.2008 18:00, Build Announcer v2 wrote:
> http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1889
>
> Changes in build 1889 from build: 1870
>
> Size delta: 17.57M
>
> +kernel-PAE 2.6.23.1-21.fc7
> -kernel 2.6.22-20080408.1.olpc.de2a86ff3b60edc
>
> --- Included kernel-PAE version 2.6.23.1-21.fc7 ---
>   

WTF?!? Since when does the XO have >4GB of RAM? And since when can the
processor address more than 4G of RAM?

Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: "Chilling Effects" paper at USENIX

[Carl-Daniel Hailfinger]

On 09.04.2008 05:50, Jaya Kumar wrote:
> On Tue, Apr 8, 2008 at 8:38 PM, Joshua N Pritikin <[EMAIL PROTECTED]> wrote:
>   
>> On Tue, Apr 08, 2008 at 10:24:34PM -0400, Benjamin M. Schwartz wrote:
>>  > A paper called "Freezing More Than Bits: Chilling Effects of the OLPC XO
>>  > Security Model" will be presented next Monday at USENIX UPSEC'08 [1].  The
>>  > author has kindly posted the paper at [2], which I discovered after Google
>>  > took me to her weblog [3].
>>
>>  This paper is depressing. Why didn't the authors step up and
>>  contribute instead of criticizing from the citadel?
>>
>>  This paper is dead on arrival.
>> 

No, the paper is dead-on.

> I think your reaction is dismissive rather than addressing the
> author's criticism.
>
> Forgive me if I'm wrong, I'm no expert, but it looks to me like the
> paper makes specific technical criticisms and seems quite detailed. I
> think it would be more positive and productive to respond to the
> technical statements made in the paper rather than to be dismissive
> and ignore what looks to some of us like valuable feedback.
>   

Some of the criticisms in the paper have been mentioned on the security@
list over a year ago. The reactions were twofold: Some were ridiculed,
others were ignored.
It seems this academic paper was the only way to get meaningful
responses. Then again, most of the comments about the paper were either
flames or otherwise dismissive instead of disproving any of the claims
made in the paper.

Anybody who has not completely read both the bitfrost spec and the
USENIX paper should shut up now. I have read the Bitfrost spec and was
one of the first persons to comment on it directly after it was
published. That's why I dismiss most of the comments on this list about
the USENIX paper - it is too obvious that commenters did not read and
understand the Bitfrost spec.

Oh, and by the way, http://wiki.laptop.org/go/OLPC_Bitfrost states "We
welcome feedback on this document, preferably to the public OLPC
security mailing list
". There is NO
point in contacting any Bitfrost author privately to point out flaws -
it would go squarely against published official OLPC policy.

Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Call for Papers/Talks/Ideas! "Update.2 Mini-Conference"

[Carl-Daniel Hailfinger]

On 22.03.2008 02:09, Martin Langhoff wrote:
> On Fri, Mar 21, 2008 at 8:58 PM, Carl-Daniel Hailfinger
> <[EMAIL PROTECTED]> wrote:
>   
>>  if Windows runs faster
>> 
> ...
>   
>>  once somebody has a child-friendly UI for Windows
>> 
>
> You are going from "if" to "when" with absolutely no support from facts.
>   

Oh, I have seen the huge speed difference between the current
UI/environment and a minimalist one (both on real hardware). That's
sufficient to question the assertion that Windows would be slower
(unless Windows source is really that unoptimized).

> I agree with John's concern and desire for better performance...
> concentrating on our users. But "maybe a competitor runs faster" is
> not an interesting conversation on the development list.
>   

This is the development list, not the sugar list. Technically, Microsoft
is not a competitor of development, it only competes with the currently
used OS and UI. I can't see another list fitting the debate as well as
[EMAIL PROTECTED] Feel free to educate me otherwise.

Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Call for Papers/Talks/Ideas! "Update.2 Mini-Conference"

[Carl-Daniel Hailfinger]

On 22.03.2008 00:30, John R.Hogerhuis wrote:
> I'd agree with Mitch. Performance, or for us, UI responsiveness, the most
> visible and painful issue being start up time of applications is paramount. My
> 4-year old, with no cushy performant computer experience, loses interest in 
> the
> 10 seconds+ it takes to load activities. Even the calculator takes seconds to
> load. Actions taken in the photo/video recorder do not sync up with sounds and
> are not proximate enough in time to the UI action.
>   

Given that there will be XO machines running Windows (I'm not claiming
it will come factory-installed) it will certainly provide for lots of
entertainment if Windows runs faster than the current Sugar+Linux
environment.

Sure, the official mission is “It's an education project, not a laptop
project” , but that also means once somebody has a child-friendly UI for
Windows with lots of education software working on the laptop, we will
have to answer both questions about usability and speed. For that, it
would be nice to know where/why most of the time is lost
(UI/language/security/...) and whether the losses are unavoidable by
design or just chances to improve performance which have not yet been
taken due to time constraints.

Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: New bible reading activity

[Carl-Daniel Hailfinger]

On 15.03.2008 17:40, Joshua N Pritikin wrote:
> On Sat, Mar 15, 2008 at 05:35:35PM +0100, Carl-Daniel Hailfinger wrote:
>   
>> On 15.03.2008 17:08, Jean Piche wrote:
>> 
>>> I wish to state my profound disagreement with the inclusion of this
>>> activity on the XO. It goes counter to the essential cultural
>>> neutrality of OLPC. If countries wish to put this activity on the XO,
>>> so be it, but IMO, OLPC should not in any way be associated with this
>>> endeavour.
>>>   
>> Did you just want to rant or did I fail to notice an invisible pink
>> unicorn requesting the inclusion of this activity?
>> 
>
> Inclusion in what? Build 700 doesn't include any activities. It even 
> lacks TamTam!
>   

Now that's a shining example of cultural neutrality. ;-)

Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: New bible reading activity

[Carl-Daniel Hailfinger]

Hi,

On 15.03.2008 17:08, Jean Piche wrote:
> I wish to state my profound disagreement with the inclusion of this
> activity on the XO. It goes counter to the essential cultural
> neutrality of OLPC. If countries wish to put this activity on the XO,
> so be it, but IMO, OLPC should not in any way be associated with this
> endeavour.

Did you just want to rant or did I fail to notice an invisible pink
unicorn requesting the inclusion of this activity?

Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Alternative power/recharging source?

[Carl-Daniel Hailfinger]

On 22.02.2008 23:41, Ben Goetter wrote:
>  >> hours...using gravity! :-) (Consider the XO using
>  >> about 2 watts...)
>
> There seems little danger of this mechanism being useful on Earth for 
> the XO-1.  A 30kg human child who can move her own mass a meter 
> vertically (via a series of pulleys, or perhaps just climbing stairs 
> with a buddy riding piggyback etc.)

If the child has a mass of 30 kg, why should he/she carry anything else 
piggyback one meter upwards to gain 300 J of potential gravitational 
energy (assuming g=10 m/s^2)? The child already gets that potential 
enery if it climbs the stairs alone.

> can invoke only 300J of potential 
> gravitational energy, or enough to let an XO sleep for two and a half 
> minutes assuming a 100% efficient conversion from gravitational to 
> electrical potential.
>   

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: How to create a new MIME type for a Sugar activity?

[Carl-Daniel Hailfinger]

Hi James,

On 06.02.2008 16:46, James Simmons wrote:
> I agree I have no business inventing my own MIME type.  What I really
> want is a file suffix association like I can do with Windows or
> Midnight Commander on Linux.  The MIME type of application/zip works,
> but Etoys is using that one too.  I need a way for Zip files using the
> .slides suffix to be opened by my Activity by default.  Unfortunately,
> the files by their nature must be created by a program other than the
> Activity.  Any suggestions would be welcomed.

What about using the "application/x-*" scheme? IIRC that is the way to
handle unofficial assignments. An example would be
application/x-sugar-activity-slide or somesuch.


Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: How to create a new MIME type for a Sugar activity?

[Carl-Daniel Hailfinger]

On 04.02.2008 18:21, James Simmons wrote:
> To accomplish this I have created my Zip files with the extension 
> ".slides" and I'd like to be able to use the MIME type 
> "application/slides" for such files.
>
> I'm also interested in creating a reader program for Gutenberg etexts.  
> I'd like these files to have their own MIME type too so they don't get 
> opened by the Write activity by mistake.  I was thinking of using a file 
> suffix of ".book" and a MIME type of "text/book" for these.
>
> I'd appreciate any information on MIME types
>   

Sorry, you can't just invent a MIME media type. There are a few RFCs for
MIME media types which specify how your media type has to be named and
how to apply for an IANA registration. More info can be found at
http://www.iana.org/assignments/media-types/ . There also is a
specification how unofficial MIME media types have to look like in case
you don't want to register them.

Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [OLPC-Games] Violent games on the OLPC Activities page

[Carl-Daniel Hailfinger]

Hi Antoine,

On 17.01.2008 21:53, Antoine van Gelder wrote:
> Also Noah - could you please try and show some empathy for the
> backgrounds of the people you talk to? Do you understand that large
> parts of the rest of the world have not enjoyed the same levels of
> stability and safety that your country has ?
> [...]
> Many of us in the other countries have been shot at, had bombs going off
> next to us and been brutalized by people with  guns that were loaded
> with real bullets made of lead that, should you be shot with them, would
> blow your head clean off.
>   

Unfortunately I lack information about your backgrund, which results in
the following question:
You use the word "us" very often. Please tell the list members which
country you have lived in where bombs went off next to you.
I'm trying to understand you better.

Thanks.

Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: B2s and OFW

[Carl-Daniel Hailfinger]

On 17.01.2008 02:02, Mitch Bradley wrote:
> Ricardo Carrano wrote:
>   
>> Hi Mitch!
>>
>> Would you recommend using firmware version q2d07 on a B2-1 unit?
>> 
>
> Yes.
>   

So Q2D07 has been tested on B2-1? How about B1 and B2-2? IIRC there were
some EC changes incompatible to B1 and B2 models.

(I assume my A-Test board will have to stay with some really early
firmware, especially because it needs that CL2.5 patch.)


Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: disabling root and olpc passwords

[Carl-Daniel Hailfinger]

On 13.01.2008 01:45, M. Edward (Ed) Borasky wrote:
> Typical Linux practice is the following:
>
> 1. One *never* allows remote shell login as "root" -- *ever* -- even 
> behind a firewall. One allows only *one* user in the "wheel" group to 
> log in to a shell account, and then *only* via "ssh".
>   

Which is almost as unsafe as using "root" directly.

> 2. When root access is needed, "sudo" is used, with the least permissive 
> mode possible.
>   

And once you start installing software globally via sudo, the account
from which you called sudo to install software is (in almost all
circumstances) effectively "root". Same goes for bootloader configuration.

> 3. "ftp" is done using "sftp" and/or "scp". For Windows clients, there's 
> PuTTY.
>   

Agreed.

> Anything less than this level of security is a bad habit -- a *very* bad 
> habit. Please don't encourage such habits, or ask the open source 
> community to cater to them.
>   

Actually, I would consider the belief that sudo makes things
unconditionally safer to be mostly equivalent to the belief that a
"personal firewall" (which is not a firewall) makes things
unconditionally safer. IMO, use of sudo should be discouraged because it
gives people a false sense of security. It is possible to use sudo in a
safe way. Same goes for the "root" account.
And then there are those people who run "sudo bash". Although they
violate your point 2, they prove part of my point.

Many people interpret complicated or work-intensive interfaces as damage
and work around them. Often the workaround not only neutralizes the
intent of the original interface, it actually makes things worse from
the perspective of the person who tried to impose the interface on them
in the first place.
Have you ever worked at a place where people were required to change
their passwords every month and the new password was not allowed to
match any of the last n passwords? I have seen that and assure you that
it worsens security. People start to put their password as post-it-note
on their monitor. Once you manage to stop the post-it habit, they figure
out that a rotating list of passwords constructed like "secret1,
secret2, secret3..." works fine. If the system notices that passwords
are similar, there's at least some chance one guy knows another guy who
then tells someone in upper management that if the system is able to
find similarities between passwords, they surely are not stored with a
cryptographically secure hash function.

Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: root password

[Carl-Daniel Hailfinger]

On 11.01.2008 03:33, Ivan Krstić wrote:
> On Jan 3, 2008, at 1:21 PM, Albert Cahalan wrote:
>   
>> The non-nerd kids are getting toys.
>> 
>
> (Sidenote: this displays a stunning level of ignorance and failure of  
> comprehension of the project's goals.)
>   

Reminds me of a nice quote from an OLPC official (I forgot who exactly
said this):
"This is not an opensource laptop project, it is an education project."
Unfortunately, in the early days of OLPC the message was more like "This
is an opensource laptop project with the ultimate goal of enabling
better eduaction for kids.". I have to admit I was quite disappointed
with the perceived change of the goals of the project.

Besides the nasty wording of your criticism of Albert's opinion, it is
quite interesting that you think emphasizing the toy factor "displays a
stunning level of ignorance and failure of comprehension".
We deliver *games* to *kids* as a key aspect of the project, but the
machines are *not* toys?
Please clarify.


Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: OLPC News 2007-12-22

[Carl-Daniel Hailfinger]

On 22.12.2007 17:32, Walter Bender wrote:
> 2. Hinge: Jacques Gagne has been investigating the laptop hinge—the
> "clearance" between the two rotating parts should be tighter and this
> would reduce wobble. Mary Lou Jepsen and Quanta are investigating a
> possible run-in change at the earliest possible date.
>   

Wasn't the clearance made wider sometime between B1 and B2 to fix the
problem with interlocking plastic parts? Please explain further.

> 7. Embedded controller: Richard Smith spent time studying oscilloscope
> traces looking for a possible cause of the reopening of Ticket 1835
> (unable to resume); recent software builds were failing on the
> suspend/resume testbed. He has been unable to reproduce the problem
> with bare-board tests and he now feels that he fully understand the
> software causes of 1835 (three distinct causes). Running the latest EC
> code with Joyride kernels doesn't seem to have the problem. Richard
> and John will continue to run tests on the suspend/resume testbed to
> insure that we won't have the problem with Update.1
>
> A second bonus was discovery and verification of EC issues that Chris
> Ball and Jim Gettys have run into. Andres helped Richard find an EC
> bug where the SCI mask was getting corrupted. The most frequent
>   

Is this a hardware or software bug?

> manifestation of that was the loss of AC events or battery-charge
> level.  Richard still don't know the root cause of the corruption, but
> has a good test case and kernel debug logs. There appears to be a case
> where EC communication fails and error recover is not working. Fixing
> it is going to involve more oscilloscope time, because turning on
> serial- port debugging appears to make the problem go away. There is
> already a workaround in the kernel to fix the mask when it becomes
> corrupted, so it's not a show-stopper.
>
> Richard is also writing some cron scripts that will take a snapshot of
> the battery ACR while the laptop is running on battery power and then
> then send us the data. Richard wants to use these data to build power
> usage profiles. The ACR gives us a very accurate reading on the amount
> of mA/h drawn from the battery.  Plotting it over time will begin to
> give us insight on our dynamic power draw.
>   

This may have been asked before, but how far is the progress in freeing
the EC code? IIRC first there were official statements that the EC code
would be free (and all parties would agree to that), then after some
time it was announced that OLPC were talking with Quanta about setting
the code free, now we just hear about EC bugs, but nothing about the code.


Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Devel-machines] Testing of firmware and base system on B2 and B1.

[Carl-Daniel Hailfinger]

On 28.09.2007 19:49, Mitch Bradley wrote:
> Mitch Bradley wrote:
>>
>>
>> B3 and later machines are essentially identical as far as the firmware
>> is concerned.  OFW senses the board revision and reports it in the
>> device tree, but does behave differently as a result of board revision
>> difference.
> 
> I meant "does not".

Nice. Does that also apply to the EC microcode?

Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Devel-machines] Testing of firmware and base system on B2 and B1.

[Carl-Daniel Hailfinger]

On 27.09.2007 01:44, Jim Gettys wrote:
> As we run up to mass production of systems, the team at OLPC must
> focus its efforts on testing and bug fixing on the mass-production
> hardware.
> 
> To date, we've been careful to ensure that our firmware and software
> works on all five variants of our beta hardware. Testing all these
> variants is taking time from key developers; therefore we will stop
> testing firmware and builds on the B1 and B2 systems.
> 
> (3) Do *not* upgrade your firmware on B1 or B2 systems to any version
> after Q2C27. It will never have been tested on your hardware and could
> break it completely.
> 
> (4) B3, B4, and C test systems are identical from a programmer's point
> of view.

Are they also identical from a BIOS developer's point of view?

Since I have A,B1,B2 machines and use them for development (including
BIOS development), I'd like to continue working on the BIOS and even
release new BIOS versions for these old machines. Be warned, though,
that the A-Test boards are not at the center of my focus.

> (5) If you are doing active development and need a B4 system, please
> use the developer's program to ask for a replacement. While we cannot
> guarantee that we can replace all developer's machines, we do have
> some available for those who really need them.

I'll apply for a B4 system soon.

Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Modification of Public OLPC Software

[Carl-Daniel Hailfinger]

On 25.09.2007 17:36, Jim Gettys wrote:
> On Mon, 2007-09-24 at 22:19 -0700, big one wrote:
>> I often use Linux without any X-Windows, but only svgalib: mplayer, links 
>> 2.0 browser, mp3blaster, etc. On FreeDOS (Free Disk Operating System), I can 
>> use display, arachne, pppd etc.
>>
>> Because OLPC is sold to general public using "Buy 2 Get 1" G1G1, is it 
>> possible to customize OLPC:
> 
>> 2. Boot to console mode (svgalib).
> 
> Yes.

No. We have neither VGA nor SVGA support because we are missing the
required VSA module.

Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Q2C20 Released

[Carl-Daniel Hailfinger]

On 31.07.2007 01:51, Richard A. Smith wrote:
> Q2C20 bits are up at http://dev.laptop.org/pub/firmware/q2c20
> Release notes are at http://wiki.laptop.org/go/OLPC_Firmware_q2c20
> 
> The auto-reinstaller has been updated to use this new firmware.

A-Test users BEWARE!

The last section of the above wiki page "If you have an ATest system
[...]" does not apply anymore. You will probably brick your system if
you upgrade.

Richard: Please remove that section or replace it with a warning similar
to the pre-B1 warning. Thanks.

Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: OOM manager project

[Carl-Daniel Hailfinger]

On 20.07.2007 16:37, Jim Gettys wrote:
> Note that the kernel has to be able to recover memory when it needs it,
> or it will deadlock: this is a situation where the kernel must be in
> control, but user space could cooperate much better than it does today,
> by providing appropriate hints.  So don't say: "the kernel shouldn't
> kill processes: user space should"; that design doesn't fly.
> [...]
> So we need an OOM killer helper.  
> 
> We have the ability to provide the kernel with much of the 
> information it needs for much better behavior, if we choose.
> [...]
> 5) see if there are better OOM algorithms that Linux presently has.

How does the new proposal relate to the OOM discussion here:
http://www.redhat.com/archives/olpc-software/2006-March/msg00197.html

Have we simply given up trying to beat userspace into shape?

Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: System software teleconference meeting minutes - 2007-07-17

[Carl-Daniel Hailfinger]

Hi,

On 18.07.2007 04:25, Mitch Bradley wrote:
> OLPC System Software Teleconference, 2007-07-17
> Mitch is close to having Forth running on the EC.

Is this on the opensource EC code?

Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Power Management

[Carl-Daniel Hailfinger]

On 08.06.2007 17:57, Jordan Crouse wrote:
> On 08/06/07 16:49 +0100, Richard Hughes wrote:
>> On Fri, 2007-06-08 at 11:42 -0400, Chris Ball wrote:
>>>* if there isn't a software tick (dynticks/tickless) planned for the
>>>  very near future
>> Can we get this info from the kernel?
> 
> Probably not - and if you could, the latency to tell you would probably
> be longer then the delay.  This will also have to be automatically triggered.

Why not go the other way round?
Tell the kernel something like "go to sleep if the next tick happens after
the minimum duration of one sleep-wakeup cycle" and let the kernel decide.
If the kernel decides to go to sleep, the cost is zero. Otherwise, the
syscall (or sysfs write or whatever else) will cost you probably still
less time than polling this info from userspace.

Regards,
Carl-Daniel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel