Fork me on GitHub
  November 20, 2018, 02:20:59 pm
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
   Home   Help Search Login Register  
Pages: [1] 2
  Print  
Author Topic: Plugin API vulnerabilities  (Read 8334 times)
xoft
Newbie
*
Posts: 42


View Profile
« on: February 06, 2011, 06:46:22 pm »

After a quick browse through the plugin API, I think I see a big potential for segfaults in plugins.

The Map functions:
Code:
  unsigned char* (*getMapData_block)(int x, int z);
  unsigned char* (*getMapData_meta) (int x, int z);
  unsigned char* (*getMapData_skylight)  (int x, int z);
  unsigned char* (*getMapData_blocklight)(int x, int z);
seem to return pointers into the living data structures. Now suppose the plugin stores such a pointer and accesses it at a later time. But MineServer may have already released those chunks! BANG Smiley

Options:
  1, Leave it as-is, no plugin ever will be so stupid (the ostrich approach)
  2, Remove the routines altogether, replace with a single-block getter / setter function (will make some "terraforming" plugins painfully slow)
  3, Upon call of these routines, increment a "lock" on the chunk; provide a lock-decrement function for the plugins to call when the chunks is no longer needed; don't release the chunk until it has a nonzero lock count (can cause memory starvation if plugins hold too many locks)
  4, Huh
Logged
Fador
Administrator
Full Member
*****
Posts: 126


View Profile
« Reply #1 on: March 11, 2011, 12:37:43 pm »

Well the pointers are not suppose to be stored =/
Logged
xoft
Newbie
*
Posts: 42


View Profile
« Reply #2 on: March 11, 2011, 01:00:29 pm »

Such an approach will make porting MineServer to use threads painful. (And I DO HOPE that MS will get multithreaded, eventually)

How about using this set of functions instead?
Code:
void getMapDataBlock(int xmin, int xmax, int ymin, int ymax, int zmin, int zmax, unsigned char * dest);
void setMapDataBlock(int xmin, int xmax, int ymin, int ymax, int zmin, int zmax, unsigned char * src);
void getMapDataMeta(int xmin, int xmax, int ymin, int ymax, int zmin, int zmax, unsigned char * dest);
void setMapDataMeta(int xmin, int xmax, int ymin, int ymax, int zmin, int zmax, unsigned char * src);
void getMapDataSkylight(int xmin, int xmax, int ymin, int ymax, int zmin, int zmax, unsigned char * dest);
void setMapDataSkylight(int xmin, int xmax, int ymin, int ymax, int zmin, int zmax, unsigned char * src);
void getMapDataBlocklight(int xmin, int xmax, int ymin, int ymax, int zmin, int zmax, unsigned char * dest);
void setMapDataBlocklight(int xmin, int xmax, int ymin, int ymax, int zmin, int zmax, unsigned char * src);

This would be safe (as long as the passed pointers are correct and of correct size), could be made thread-safe easily, would allow plugins be able not to care about chunks / internal storage methods. The underlying implementation would handle all the details regarding chunks (and later multithreadlocks). Also it doesn't seem to suffer from issues inherent with locks and it is efficient enough.
Logged
Ligustah
Newbie
*
Posts: 42


View Profile
« Reply #3 on: March 13, 2011, 12:14:52 am »

Question might be a bit off topic,
but why should Mineserbe be multi-threaded again?
Logged
Delirium
Newbie
*
Posts: 27



View Profile
« Reply #4 on: March 14, 2011, 12:07:00 am »

Performance...
Logged

Make it idiot proof and someone will make a better idiot.
Ligustah
Newbie
*
Posts: 42


View Profile
« Reply #5 on: March 14, 2011, 12:33:36 am »

The original Java server is multi-threaded, i don't see where it has more performance.
Multi-threading should, in my opinion, only be considered if Mineserver should
ever even run into performance issues.
Multi threading sounds like a cool thing, but it brings lots of problems. Locking,
synchronisation. Minecraft requires a lot of data reads and writes. I think the performance
you might gain by running several threads are lost, when threads have to wait for
resources to become available.

As of now, nothing in the server is blocking, so i don't think multithreading would make it any faster.
Logged
xoft
Newbie
*
Posts: 42


View Profile
« Reply #6 on: March 14, 2011, 01:08:48 pm »

I think some of the more advanced features, such as minecart tracks or redmine circuitry would very much benefit from the ability to run in separate threads. If for no other reason, then because they might be in for a lot of work if the track / circuit is too large, and not be able to process data fast enough to keep even with the 200ms timer.

And if one thing goes MT, then the whole must go MT, otherwise the mess is unbearable.

Just imagine the lag if you wanted to place a block and it took ~0.5 sec just because the server is very busy calculating your circuit.

MT should be always considered, from the beginning, because if not, then converting ST into MT will be a pain in the *** when one day it is actually needed. If nowhere else, then the interfaces (that are expected to get stable) need to be MT-compatible, if nothing else.

I think my last offer for interface is fully in line with that - it can be made MT-safe very easily if needed, yet it doesn't add any cost for ST. And in fact it provides great benefits, since consumers of that interface won't have to worry about chunks, internal data storage, swapping etc. That's clean interface design.
Logged
Ligustah
Newbie
*
Posts: 42


View Profile
« Reply #7 on: March 14, 2011, 03:54:55 pm »

I think you underestimate the speed of todays CPUs.
As far as i know threads should only be used when things block on IO or take a lot of time
and can't be done non-blocking.

I think it might be feasible to spawn one thread or process for a regions of a certain size,
because chunks are independent from each other in theory.

Oh, and i fact, threads only boost performance on Multi-Core processors.
Logged
xoft
Newbie
*
Posts: 42


View Profile
« Reply #8 on: March 14, 2011, 04:02:38 pm »

Threads are used to an advantage whenever there are two or more tasks that are very losely coupled (that is, they interact minimally or not at all, either via messages, shared data or otherwise)

Redstone circuits and tracks (and world physics, maybe) are ideal candidates - they each run calculations that are independent of each other. Therefore putting them to separate threads would mean negligible harm on single-core processors and a huge gain on multicore and multithread machines (which, don't forget, are dominant in the consumer electronics today)

However, we're straying more and more away from the subject - API replacement.

Tell me one single reason why the old API should stay and the new API should not be implemented. Oh, and "already written" is not a reason Smiley
Logged
BurnZeZ
Newbie
*
Posts: 2


View Profile
« Reply #9 on: March 15, 2011, 03:21:22 am »

I think you underestimate the speed of todays CPUs.
As far as i know threads should only be used when things block on IO or take a lot of time
and can't be done non-blocking.

I think it might be feasible to spawn one thread or process for a regions of a certain size,
because chunks are independent from each other in theory.

Oh, and i fact, threads only boost performance on Multi-Core processors.

Quit being an idiot. No reason to multi-thread? Is this a joke?
Either you're misinformed, or trollin'. lern2computer

"Oh, and i fact, threads only boost performance on Multi-Core processors."
Because single core processors clearly dominate the market. DERP

Let me guess, next you're going to argue that framerate independent physics are overrated?
« Last Edit: March 15, 2011, 03:30:07 am by BurnZeZ » Logged
Jailout2000
Newbie
*
Posts: 49


Enthusiast


View Profile WWW
« Reply #10 on: March 15, 2011, 04:54:05 am »

I think you underestimate the speed of todays CPUs.
As far as i know threads should only be used when things block on IO or take a lot of time
and can't be done non-blocking.

I think it might be feasible to spawn one thread or process for a regions of a certain size,
because chunks are independent from each other in theory.

Oh, and i fact, threads only boost performance on Multi-Core processors.

Quit being an idiot. No reason to multi-thread? Is this a joke?
Either you're misinformed, or trollin'.
Exactly.

Ligustah, you're wrong on so many levels. Multi-core processors are not the only thing that can benefit multi-threading. There's this other technology which has been around for just as long if not longer, called Hyper-Threading. My CPU actually has it (and runs on a single-core).

With Hyper-threading, two threads can be executing at the same time on ONE cpu core. If you have a dual core with hyper threading, then four threads can execute at the same time. Likewise, if you have a dual core without hyper threading, only two threads will execute at a single time, providing the process is capable of running on more than one core.

Also, "today's CPUs" -- really? Are you forgetting some people still run their "servers" on old pieces of silicon?!
Logged

Visit my website to see what's up with me.
Ligustah
Newbie
*
Posts: 42


View Profile
« Reply #11 on: March 15, 2011, 09:49:19 am »

At least i refrained from judging your person(s).
I don't really know anything about Hyper-Threading, so i might of course be wrong there.
So yea, i see you're pretty sure that you want to go the multi-threading hype, so i'll stop
arguing here.
Logged
SweetCraft Girl
Newbie
*
Posts: 11


View Profile
« Reply #12 on: March 15, 2011, 10:56:10 pm »

I think you underestimate the speed of todays CPUs.

I think you know nothing of a todays CPU's, and i must quote what i said in IRC before posting this:
-----------
[15:44] <@SweetGirl> who is the primitive talking about THREADING in that Mineserver post???
[15:44] <@SweetGirl> Ligustah
[15:44] <@SweetGirl> thats someone who like, is still using  a P4 or a dual-CPU or a 2006 dual core.
------------
You did say one thing that is a fact:  Coding for true threading is difficult.  Very difficult.

Everything else was fairly said from the perspective of someone ignorant lacking in knowledge of that which they so strongly speak.

Google is your friend.  If you are too lazy to learn about the medium you care to operate/code in - i.e. Modern CPU Architecture and Capabilities; then you hopefully are not planning on coding anything for this Minecraft platform.

Scary...seriously.
Logged
SweetCraft Girl
Newbie
*
Posts: 11


View Profile
« Reply #13 on: March 15, 2011, 11:03:52 pm »

At least i refrained from judging your person(s).
I don't really know anything about Hyper-Threading, so i might of course be wrong there.
So yea, i see you're pretty sure that you want to go the multi-threading hype, so i'll stop
arguing here.

You don't "really know anything about Hyper-Threading" or "Multi-Threading".

And it isn't some new voodoo tech, it is 1/2 decade old technology, not counting "hyper threading".  So seriously, stop being a Luddite because you refuse to read a tech website for who knows what personal reason.  Why anyone would choose to willfully be ignorant on a topic and then post a message as if to attempt to debate it and not back down when they have already shown themselves intellectually deficient in at least 1 out of 2 areas pertaining to the topic, is really beyond me.  

Some people just have to be right no matter what.

I do not think you even comprehended let alone read a word Xoft or Jailout said.  Nor will you read anymore in this thread because you have already shown that when challenged with inconvenient facts, data, information, contrary to your own, you walk away instead of shining the light fully on the issue to at least clarify your own understanding or to deconstruct the argument put against you and show them wrong.

Either way, you are on the long road to working harder, not smarter.  Have fun with that.
« Last Edit: March 15, 2011, 11:07:47 pm by SweetCraft Girl » Logged
Ligustah
Newbie
*
Posts: 42


View Profile
« Reply #14 on: March 16, 2011, 05:04:50 am »

I already said i was wrong. So what's the point of offending me like that?
As for your ludicrious accusations concerning my lack of interest in other
people's post: you are completely wrong this time.
I don't think you have any right to assume something like that.

Anyways, as i said. I'm out of this discussion, which turned pointless a few
posts ago. Feel free to make more fancy posts about me. I will probably read
them, but i will certainly not waste more time replying to your trolling.

Thanks.
Bye.
Logged
Pages: [1] 2
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!