Traditional C "Hello World" working in NaCl

https://groups.google.com/forum/#!msg/native-client-discuss/lT5bsW1ZlKQ/WsXJ5y_2s54J

by ginsweater • 14 years ago

59 24 14 years ago

groups.google.com

rollypolly• 14 years ago

I wonder how it handles a bogus printf format string.

loeg• 14 years ago

The same way the underlying printf implementation does? This isn't wrapping printf(3), just the underlying write(2).

Are you trying to ask if it catches, e.g., format string vulnerabilities? I think the answer to that is: Native Client's aim is to be a safe x86 VM, so — hopefully. But to me personally, it seems unlikely that they've thought of everything.

caf• 14 years ago

The important part of the design - the bit that makes it achievable - is that it's not a general x86 VM. It only accepts a limited subset of valid x86 object code, a subset chosen to make validation a tractable problem. This requires a modified compiler be used.

The unlikelihood that the original design was perfect is probably why they had the "Native Client Security Contest" a few years ago - and indeed independent researchers found several flaws. Personally, I'm a lot happier with it now that they've fixed everything that Mark Dowd could find wrong with it ;)

arkitaip2• 14 years ago

I wonder when we will see the first obfuscated C for NaCI code contest.

spicyj• 14 years ago

Just a note, it's NaCl, spelled NACL, as in the molecule "sodium chloride" (and the abbreviation of the name "Native Client").

calpaterson• 14 years ago

As a side note, why is it that I have to sign in to Google in order to be able to see this? Is registration /really/ necessary for Google Groups?

arkitaip2• 14 years ago

Strange, I'm not logged in to my Google account and could read the article without any issues.

rnadna• 14 years ago

You are right. It's very annoying. It's even worse than having links that are behind a paywall, because at least a paywall usually indicates that funds are flowing to the person (reporter, etc.) who created the content. The google groups situation is quite different, and quite annoying. I never login to google groups to see something listed on HN. I wonder whether HN could provide an option to let readers avoid such items, by removing them from the listing or flagging them?

kcbanner• 14 years ago

Another poster said this only happens if you are logged in but need a session refresh.

dangrossman• 14 years ago

You are only being asked for a password because you're (partially) logged in to a Google Account already. Either log out, or open Google Groups links with "open in incognito window" if you use Chrome.

icebraining• 14 years ago

It works fine here (Chrome on Windows) even if I log out.

I think it's a bug. Are you on a mobile browser?

chubot• 14 years ago

Yeah I think it's a bug with mobile... happens on my ipad all the time (super annoying) but not my PC.

jbri• 14 years ago

If you're signed in to a Google account already but your session is inactive, you might be asked to re-authenticate. If you're not signed in at all, you don't get asked.

raverbashing2• 14 years ago

Can someone please explain to me why running native code coming from a web site is a good idea?

Because I see this as "Google's ActiveX"

cantankerous• 14 years ago

Read the paper. It's a subset of x86 that retains better security properties for distribution.

http://src.chromium.org/viewvc/native_client/data/docs_tarba...

raverbashing2• 14 years ago

Very interesting. The security features are very thorough.

Of course, until someone finds a vulnerability, or a way through the validator, or an exploit on an abstracted function.

Still, it's a good security model

tveita• 14 years ago

At best that takes care of the security issues. The other thing that makes ActiveX an affront to the web is the platform lock-in.

x86 code is not suitable as a web standard. (And neither is the LLVM intermediate representation, for reasons expounded on in e.g. http://permalink.gmane.org/gmane.comp.compilers.llvm.devel/4...)

toemetoch2• 14 years ago

I'm a fan of fast native code, but I worry that this promotes sneaky code in the background once it gets widely adopted.

With javascript we basically have open-source web apps. I often skim through js source to learn new tricks - and obfuscation doesn't really stop me (apart from google's java-translated js) . With compiled NaCl I probably wouldn't be able to find out a lot.

I'm not talking about "stealing user data" when I say sneaky code. No, with compiled native code a whole new game is started: computational-intensive code. It wouldn't be that difficult to include code that gets a job to work on for a few minutes: breaking captchas, brute-forcing passwords, anything that shift computational effort from a server to a client.

Drakim• 14 years ago

I would assume the NaCl apps won't run by default. Maybe you get that "click to activate" thing that firefox is implementing for Flash and Java

Arelius• 14 years ago

Yeah, that's not what happens, at least not today.

toemetoch2• 14 years ago

It doesn't run by default. But remember it's Google who's pushing this, and their browser has momentum. I'd guess it's just a matter of time before they run it by default. They already cashed out for security bounties for NaCl in the past[1] and seem to have increased resources recently[2] since it's quite a lucrative market for gaming.

[1] https://developers.google.com/native-client/community/securi... [2] m.yahoo.com/w/legobpengine/news/google-bringing-high-end-gaming-chrome-via-native-054102268.html

Traditional C "Hello World" working in NaCl

Related Stories