Direct (close-to-the-metal) open-source SGX driver

[mali]

It's a shame, that you didn't receive a dev-board. I can't understand that <_<

 

[maciek_urbanski]

It's a shame, that you didn't receive a dev-board. I can't understand that <_<

Thanks, but IMHO it's a good decision.
Those dev. units should go to people that will develop/fix applications that will be ready on Pandora launch. 'libsgx' will not be ready in this time frame.

 

[cb88]

ok just wasn't sure if it was something you had the time to get going....

as far as php skills I have none... although I do think it would be a usefull language to learn

And I am in school X.x

 

[maciek_urbanski]

ok just wasn't sure if it was something you had the time to get going....

as far as php skills I have none... although I do think it would be a usefull language to learn

And I am in school X.x

Ok, it probable came out not as I intended...

I was talking of course about forum I'm configuring, it's Advanced Electron Forum and it's, well, badly written. But this is a young SW product, they certainly have potential. But if I'd test AEF more throughly I wouldn't install it.

Sorry for misunderstanding.

 

[cb88]

I figured it was something along those lines haha... I think the guys that wrote java (or at least the people that wrote the book for my class) should go back to school... (Of course that is probably where they picked up their programming habits... meh )

I don't offend easily anyway... There is always room for improvement you know.

 

[Kyosys]

As a web security enthusiast I'll have to agree with maciek. Most forums systems are poorly written. Even commercial ones

 

[Olexxy]

I was talking of course about forum I'm configuring, it's Advanced Electron Forum and it's, well, badly written. But this is a young SW product, they certainly have potential. But if I'd test AEF more throughly I wouldn't install it.

Have you tried FluxBB ? Supposed to be well written and GPL

 

[cb88]

@Kyosys wouldn't you think proprietary forums would be less good than free licecensed ones :wacko:

heh... FluxBB *looks* nice anyway was responsive.. they probably have low traffic though

one example of a completely horrendous forum would be blackboard especially blackboard vista...

I wonder if mumble has ever been used in a software project.... seems there was another such collaboration tool but i forget what it was called... heh my school has mumble installed but doesn't use it

 

[Catch23]

Marciek, what's going on with your forum, any progress?

 

[cb88]

@Catch23 not sure Maciek is even reading this anymore since the old forum is back up... I sure havn't been following anything here It has been awhile since I have seen any of his posts though

 

[maciek_urbanski]

@Catch23 not sure Maciek is even reading this anymore since the old forum is back up... I sure havn't been following anything here It has been awhile since I have seen any of his posts though

You're right cb88 I'm neglecting Pandora-related activities for now. I've figured out SGX instruction set, most of USSE related specs and places in code I must intercept for capture/replay mechanisms (next step of reverse engineering). My OGL ES setup works (via ATI emulator on OGL 2.0) and I made some simple applications (which will be captured further on)...

Not much more to do without actual hardware.

So for time being I've switched to other project - I'm designing and prototyping home automation system for my soon-to-be-built home.
It's a fairly complex system, few hundred custom AVR nodes (lights & sensors), dozen controllers (bus conversions) few per-room controllers (Gumstix Overo Fire - the same specs like Pandora, but half of flash) and fairly complex central controller (software-wise). Yup - I'm a hardcore nerd.

It's a long-run project (estimated 5yr) - so when I'll get my Pandora I'll continue to develop CTM driver.

As a side note - I intend to use Pandora as a wireless "master controler" for home. :wink:

 

[ldesnogu]

You're right cb88 I'm neglecting Pandora-related activities for now. I've figured out SGX instruction set, most of USSE related specs and places in code I must intercept for capture/replay mechanisms (next step of reverse engineering). My OGL ES setup works (via ATI emulator on OGL 2.0) and I made some simple applications (which will be captured further on)...

Not much more to do without actual hardware.

What about sharing what you already have so that people with hardware can pick it up where you left it? Kind of like the nouveau project for nVidia

 

[cb88]

I'm still not entirely sure about develing into the driver binaries ... and as you mention they nouveau project the state clearly that their efforts are based on trial and error and memory traces and the like and they don't look in the binaries merely watch them as they run

If documentation about the insides of the driver were released or if it were suspected to have been derived from the binary directly it might not be so good

I know the EU has laws that are supposed to protect you and all but it doesn't work that way much of anywhere else and im not sure it would protect you in the case of the sw driver since that wouldl be protected by copywrite... sure I believe you can observe the driver and try to make a driver that replicates its functionality but I'm not so sure about taking a more direct approach

I know the gnash developers have taken a similar stance as the nouveau developers

 

[maciek_urbanski]

I know the EU has laws that are supposed to protect you and all but it doesn't work that way much of anywhere else and im not sure it would protect you in the case of the sw driver since that wouldl be protected by copywrite... sure I believe you can observe the driver and try to make a driver that replicates its functionality but I'm not so sure about taking a more direct approach

Basically you cannot replicate functionality of a driver basing on analysis of it's binaries, because that would constitute a "reverse engineering" and that's illegal.

You can however analyze binaries to find out how hardware works. You can use this knowledge to create driver presenting different functionality to the user, so AFAIK no binary-compatible with kernel stub OGL ES driver is legally possible.

If you are not sure (read: didn't consult a lawyer) I'd advise against involvement in this project. I did - so I feel fairly secure.

What about sharing what you already have so that people with hardware can pick it up where you left it? Kind of like the nouveau project for nVidia

Sorry, but no. I want to be on top of things to the end - in other words: I want design and fine-tune CTM API. I have my design methodologies that drive my co-workers mad, but as a result - the resulting API is lean & clean. I'm not suggesting anything about you folks, but it's a pet project and I want it to be done my way. When API and initial implementation will be done (proverbial "seed" is planted) I will share code for you all to improve it.
But be sure if from any reason I would not be able to finish my work - it will be made public in unifinished state. And for clarity - I didn't "left" the project - I just don't have hardware to work on... and if this will continue for more months I will buy Gumstix Overo Fire+Tobi3 (HW-wise a Pandora for embedded solutions) - and work on this.

Side question: Are we on this forum "for good" ? I did a fair share of PHP coding in my days and fixing/migrating a GP32X is not a "rocket science"...

 

[urjaman]

Basically you cannot replicate functionality of a driver basing on analysis of it's binaries, because that would constitute a "reverse engineering" and that's illegal.

You can however analyze binaries to find out how hardware works. You can use this knowledge to create driver presenting different functionality to the user, so AFAIK no binary-compatible with kernel stub OGL ES driver is legally possible.

If you are not sure (read: didn't consult a lawyer) I'd advise against involvement in this project. I did - so I feel fairly secure.

As you did consult a lawyer then ok - then it's legal to directly (on your own) create a driver with different API - the driver with a different API being documentation in the following example that i am pretty sure of being legal.
I thought that the legal thing would be to:
- analyze the binaries
- write documentation about how the hardware is driven
- then have somebody else write the driver from your documentation (and it could even have any API - even the same)

So, i think it would be legal to create a binary-compatible with kernel stub OGL ES driver if somebody created that by looking at(/maybe even directly calling) your ligsgx (when released) but not the binary blob.

 

[Zoxc]

You could of course just write an OpenGL (ES 2.0) driver ontop of libsgx, but maciek_urbanski has no intension to do so.

 

[anexanhume]

Basically you cannot replicate functionality of a driver basing on analysis of it's binaries, because that would constitute a "reverse engineering" and that's illegal.

You can however analyze binaries to find out how hardware works. You can use this knowledge to create driver presenting different functionality to the user, so AFAIK no binary-compatible with kernel stub OGL ES driver is legally possible.

If you are not sure (read: didn't consult a lawyer) I'd advise against involvement in this project. I did - so I feel fairly secure.

As you did consult a lawyer then ok - then it's legal to directly (on your own) create a driver with different API - the driver with a different API being documentation in the following example that i am pretty sure of being legal.
I thought that the legal thing would be to:
- analyze the binaries
- write documentation about how the hardware is driven
- then have somebody else write the driver from your documentation (and it could even have any API - even the same)

So, i think it would be legal to create a binary-compatible with kernel stub OGL ES driver if somebody created that by looking at(/maybe even directly calling) your ligsgx (when released) but not the binary blob.

This is my understanding of the process. This is how they did it in the 80's when the PC clone wars were going on.

Side question: Are we on this forum "for good" ? I did a fair share of PHP coding in my days and fixing/migrating a GP32X is not a "rocket science"...

This forum will foreseeably exist "for good", but gp32x is returning very shortly.

 

[Pickle]

You could of course just write an OpenGL (ES 2.0) driver ontop of libsgx, but maciek_urbanski has no intension to do so.

adventus is doing this, its more of a wrapper though.

 

[ldesnogu]

What about sharing what you already have so that people with hardware can pick it up where you left it? Kind of like the nouveau project for nVidia

Sorry, but no. I want to be on top of things to the end - in other words: I want design and fine-tune CTM API. I have my design methodologies that drive my co-workers mad, but as a result - the resulting API is lean & clean. I'm not suggesting anything about you folks, but it's a pet project and I want it to be done my way. When API and initial implementation will be done (proverbial "seed" is planted) I will share code for you all to improve it.
But be sure if from any reason I would not be able to finish my work - it will be made public in unifinished state. And for clarity - I didn't "left" the project - I just don't have hardware to work on... and if this will continue for more months I will buy Gumstix Overo Fire+Tobi3 (HW-wise a Pandora for embedded solutions) - and work on this.

Oh OK, you made it sound like the project was put to an end. I certainly understand your position on keeping the code then, I do the same

 

[warmi]

You could of course just write an OpenGL (ES 2.0) driver ontop of libsgx, but maciek_urbanski has no intension to do so.

adventus is doing this, its more of a wrapper though.

Why would anyone want to do that ?

There are already implementations available for Windows and Linux ( Img Tech and ATI)