Actually, my solution does not bloat the code as much - you would incur the penalty of loading the protection once per scope - after that all subsiquent accesses via that register are "free". With the BOUND instruction, you have to insert it before every access, unless you can somehow insure that the check is unneeded (e.g. a loop index where you can BOUND the start and the end value of the loop var).
As for the code/data space issue - the issue at hand is stack-smashing and array bounds violations - neither of which is measurably affected by seperation of code and data space.
As for "who's to blame" for the current code/data overlap - it's a bit of a toss-up: GCC has some of the blame, LIBC some of the blame, the kernel some of the blame. But having done development in an environment where the code and data segments did not overlap I can tell you that you get bit by all SORTS of problems - const char *'s that the compiler wants to put in the code segment, pointer conversions from void * to void (*)(), and so on.
Stupid question - do you perhaps have the new plugin installed in your home directory, and the old plugin installed in/usr/(lib|local)/mozilla/plugins?
My statement about "it gets hard" was for a seperate hardware stack and auto data storage, not seperate code and data spaces.
Even if the program space and the data space were completely seperate I can trivially smash the stack and get a shell - again, all I have to do is overwrite the current function return address with the address of execv, and the preceeding addresses with a bogus return address and pointer to the strings "/bin/sh", 0, and 0. No code segment overlap needed.
Secondly, the BOUND instruction would have to occur before EVERY potential operation, bloating code size (bu-bye cache) and slowing the machine down.
Your assertion that seperate code and data spaces in the kernel is like locking the doors on a convertable - it may make you feel good, but it does not really do anything.
Lastly, most stack smashes happen in user space, not kernel space. If you wish to critizize anybody, criticize the developers of GCC and libc.
OK, so to recap the previous article and this article:
They compare a chip that is not shipping now, cannot ship now because of bugs, but when it ships will have a memory interface twice as fast as what is shipping now on the Athlon as well as a roughly 50% higher clock speed. In many tests the Athlon (which is shipping now) still won, and where it did not win it usually was over 50% as fast as this new chip (which is not shipping yet).
If I can overwrite a buffer, I can screw you machine. I don't care if the stack is not executable - I can modify the return address and fake a call to exec with "/bin/bash" as the args.
If auto storage is removed from the call/return stack, I can overwrite another variable somewhere else, perhaps tricking your program into thinking it is debug mode. It gets harder, but not impossible.
What I was discussing was fine-grained memory bounds checking - which you simply cannot do when all you have is 8192 LDT and 8192 GDT entries, some of which have to be IDT gates, system call gates, task state segments, etc.
'min-width'
Value: | | inherit
Initial: UA dependent
Applies to: all elements except non-replaced inline elements and table elements
Inherited: no
Percentages: refer to width of containing block
Media: visual
'max-width'
Value: | | none | inherit
Initial: none
Applies to: all elements except non-replaced inline elements and table elements
Inherited: no
Percentages: refer to width of containing block
Media: visual
(taken from the very link you gave, emphasis mine)?
Granted, I wasn't as clear as I should have been - I was referring to Netscapes user-content.css, which allows you to re-write a page on the fly. It is not possible to, in user-content.css, say "if the width of a table entry is between x and y, rewrite it to be *".
I'm about to say something I would have never dreamed of saying a couple of years ago.
It is a shame that Intel made segments work the way they do, because a minor tweak and segments would have been the perfect way to prevent buffer overflows in hardware.
Consider: what if, instead of segment descriptors having to live in the GDT and LDT, they could be loaded into a register from a normal memory limit? True, they would then have been useless for OS level protection, but I assert that is what the page map is for (yes, the page mapper didn't exist prior to the 386, and enhanced segments showed up in the 286).
In some of the DSPs that I work with, you have registers to specify a region of memory. When you access off these registers, memory bounds are enforced by the chip (this allows for circular regions of memory, bit reversed addressing, and other weird things you need when doing DSP work).
What if you could have done something like this: buffer:
ds 1024 ; a buffer of stuff buffer_descr:
dd buffer ; where buffer starts
dd 1024 ; sizeof(buffer)...
LDPROT ES,buffer_descr ; set limits checking
LD ES:(ESI),EAX ; store to buffer with checking.
Thus, any access out of bounds would throw a SIGSEGV.
Then, the code could have provided protection against overflows without explicit checking on every array access. True, this would not protect you if all you were given was the buffer address, but in the presense of this sort of hardware, GCC could have been modified to make a char (*a)[] (pointer to array of char) be three elements - base, sizeof(), index.
The problem isn't so much the ads, rather it is the fact that the webmaster(baters) who create these sites set up their layouts assuming your screen is 800x600. Therefor, since the ads are 160 wide, and there are two of them (one on each side), that leaves 800-(2*160) = 400 (that's the sort of math these morons use) for the article.
So, if you are running a 1600x1200 window and larger fonts (anti-aliasing? I need no anti-aliasing!) you get an article like this .
If the morons would either
use a "width=*" for the article
Come to an agreement as to what class the actual article text would be
then there wouldn't be a problem - large browser users like me would either get an article that spans the available space (the width option) or could at least override the setting on the article text in our CSS (the common class option).
I've contacted several sites about this. For example, PBS (hosters of the Cringely articles) responded saying "Some people don't like long lines of text, so there!" (OK, then they can resize their windows to get the line length they want.)
Unfortunately, since every site uses a slightly different "width=", and since CSS does not allow you to say "width=[400..800]" or something like that, you have to have a seperate entry for each site, and when the webmaster(bater) changes the layout you have to update your CSS and restart your browser.
I do wish people would realise that HTML is about giving enough info to my browser to render the page, not about being pixel-exact.
AOL is blocking DSL users from directly sending email. This is largely because of all the "U 2 kin make $$$ wit UR computer!!!!!" scams that are nothing more than spamming@home clients.
"WAAAAH!! I WANNA SEND MAIL FROM MY DSL" people cry (NOTE: I am on a DSL connection myself).
"FOO! Just use your ISP's mail server" other people say (that's what I do....)
"WAAAAH! MY ISP'S MAIL SERVER SUXORS!" the first group reply (I cannot understand how the ISP's connectivity works, but the mail server doesn't, but I digress).
OK, so what about this: why doesn't somebody set up a mail server, which requires its users to be authenticated beforehand, has a real TOS with fangs, claws, breath weapons, rocket launchers and other implements of mass destruction to be quickly turned upon violators, and which uses either SMTP-S or SSH style connections.
Thus, all the folks who use DSL, who's ISPs mail service is unacceptable, and who want an alternative can have a place they can connect to that is NOT a spam haven, NOT on a dynamic IP, NOT on blocklists, and thus everybody is happy.
After all, you can already buy your wire from one provider, your connectivity itself from another (in some places), your web space from a third. Why not mail services from a dedictated mail provider?
(NOTE: I am not talking Rot^H^H^H Hotmail or the like - I am talking a service that actually allows mail sending from something other than a Web page or proprietary client.)
Things to remember
on
Gas Goes Solid
·
· Score: 5, Insightful
1) Hydrates are not stable at room temperature and pressure - you still have to keep them cold (-10 C). Granted, -10C is better than -100C, but you will still have to have a refrigeration unit or a pressurized tank.
2) When you break the hydrate down, you have methane and water. You have to do something with the water - dump it on the ground, feed it into the engine to be vaporized, something.
3) While hydrates may store more methane than storing the methane as a gas, I don't think hydrates store more methane per unit volume than storing the methane as a liquid.
4) You are storing methane and water - you will have more mass per unit methane than storing just methane.
Those things said, this could be a good thing, in that anything that allows better storage and transport of methane makes it a more viable fuel source.
I never said they wanted the info to persecute^H^H^H^H^H^H^H^H^Hprosecute you - just that if they wanted the data on the drive they could get it.
However, if the data on the drive is embarassing, they could bring it out in court and make it a matter of public record.
If they REALLY want you, they use your data to find somebody else (say, the person you bought something illegal from) and then crack him to get the data to bust you.
These are some of the reasons that things like double jepordy are so important - with the resources of the state behind him, a prosecutor can crush anybody he wants without strong limits.
He hits you with a supeona for the key. You have two choices - supply or refuse.
You refuse, citing your 5th amendment rights.
The DA offers you immunity.
You continue to refuse.
Since you have been offered immunity, you no longer have the protection of the 5th amendment, as you cannot incriminate yourself.
Therefor, you are in violation of the supeona - a court document.
You are, therefor, in contempt of court.
You are missing the point here - your 5th amendment right does not apply, because you are no longer incriminating yourself. That is the "trick" they use.
Read the 5th amendment. You cannot be compelled to incriminate yourself. If the testimony would not incriminate you (due to immunity being granted) then the 5th amendment does not apply.
Sorry, but this already has been done several times.
The best way to keep anything hidden from anybody is to keep them from ever knowing it existed in the first place - if they already know, or suspect, then it's already too late.
Sure, you might have your super-leet miniserver stuck in your heating ducts, powered by a little mini-windmill and linked via 802.11g to your house, with an emergency "shut up for 24 hours" command, and that might keep it from being found in a cursory search. But if the cops really think you have something on a computer in your house that is worth finding, they will find it. They will keep searching until they do, even if it takes days.
So the day after you are hauled downtown, one of the forensics team says "Hey, there's a signal here on 5GHz - get the spec-an in here and let's DF that puppy."
Now, if you used strong encryption, you might keep them from knowing what is on the disk, but find it they will. And they can compel you to provide the key - even here in the US, all they have to do is say "Fine - we won't charge you based on anything we find." That "poofing" sound was your 5th Amendment right becoming irrelevant - you can no longer incriminate yourself, so you can no longer refuse to testify and be protected. Continue to refuse, and they find you in contempt of court and lock you up until you change your mind.
Robert Heinlein made the point in "If This Goes On..." that the best thing in the world is to let them find something bad, but not bad enough to get you into trouble. So, if you are plotting the overthrow of the known world, you keep that info a deep, dark secret tattooed on the inside of your eyelids encrypted with a 4096 bit key, but you keep your goat porn on a drive they will find (with a little looking). Then, when they think you are hiding something and find the drive, they look a little longer, don't find anything, and move on.
But once again, the big trick is not to arouse suspicions in the first place. If they knock on the door, you've already lost.
This technique is nothing more than embedding an oscillator on-chip, and using that to monitor the main clock.
Since most CPUs internally multiply their clock (you don't feed a 3.0 GHz P4 a 3.0 GHz clock, you feed it a much slower clock and it multiplies it up), why then don't manufacturer's just use an embedded clock and do away with all this?
Simple - it is very hard to have an accurate clock embedded in the CPU. External clocks can use a quartz crystal to vibrate and make the clock - an embedded oscillator would have to use an on-chip delay line or RC network, which will drift over time, temperature, and voltage.
So all they can do with a system like this is catch you if you are overclocking by a fairly large amount - were they to try to trap you at a 10% overclock they would have false trips due to process variation.
To extend the analogy the article used: you will get a speeding ticket if you are going 20 over the speed limit. Keep it less than 10 over and you will be fine.
NOTE: this is not advice condoning overclocking or speeding! This is just an analysis of the technology involved.
Let's see, what else won't be an accurate simulation?
This sounds to me like it might be good for psychological research, and possible some life support systems work, but as for really simulating a trip....
I'd rather see somebody, anybody, start working on a real, permanently manned lunar base. You can at least BEGIN to simulate a trip then, while still being only a few days away from home if things go wrong.
But the Moon is no longer considered "sexy" by The Powers That Be.
Even though I am a subscriber, and I have my ad block count set to 0 (i.e. block all ads), and even though the/. crew say that should be fine for me to preview stories, I have yet to see one from TMF.
I don't think it is working.
But then, I also have not received moderation points in over a year, even though I M2 every day.
Personally, I think much of the/. code isn't fully tested.
(Yes, this is OT - hence why I have hit the "No Karma Bonus" flag.)
Slashdot Mirror
Actually, my solution does not bloat the code as much - you would incur the penalty of loading the protection once per scope - after that all subsiquent accesses via that register are "free". With the BOUND instruction, you have to insert it before every access, unless you can somehow insure that the check is unneeded (e.g. a loop index where you can BOUND the start and the end value of the loop var).
As for the code/data space issue - the issue at hand is stack-smashing and array bounds violations - neither of which is measurably affected by seperation of code and data space.
As for "who's to blame" for the current code/data overlap - it's a bit of a toss-up: GCC has some of the blame, LIBC some of the blame, the kernel some of the blame. But having done development in an environment where the code and data segments did not overlap I can tell you that you get bit by all SORTS of problems - const char *'s that the compiler wants to put in the code segment, pointer conversions from void * to void (*)(), and so on.
It ain't as easy as it sounds, trust me.
It worked just fine for me when I installed it.
/usr/(lib|local)/mozilla/plugins?
Stupid question - do you perhaps have the new plugin installed in your home directory, and the old plugin installed in
My statement about "it gets hard" was for a seperate hardware stack and auto data storage, not seperate code and data spaces.
Even if the program space and the data space were completely seperate I can trivially smash the stack and get a shell - again, all I have to do is overwrite the current function return address with the address of execv, and the preceeding addresses with a bogus return address and pointer to the strings "/bin/sh", 0, and 0. No code segment overlap needed.
Secondly, the BOUND instruction would have to occur before EVERY potential operation, bloating code size (bu-bye cache) and slowing the machine down.
Your assertion that seperate code and data spaces in the kernel is like locking the doors on a convertable - it may make you feel good, but it does not really do anything.
Lastly, most stack smashes happen in user space, not kernel space. If you wish to critizize anybody, criticize the developers of GCC and libc.
OK, so to recap the previous article and this article:
They compare a chip that is not shipping now, cannot ship now because of bugs, but when it ships will have a memory interface twice as fast as what is shipping now on the Athlon as well as a roughly 50% higher clock speed. In many tests the Athlon (which is shipping now) still won, and where it did not win it usually was over 50% as fast as this new chip (which is not shipping yet).
If I can overwrite a buffer, I can screw you machine. I don't care if the stack is not executable - I can modify the return address and fake a call to exec with "/bin/bash" as the args.
If auto storage is removed from the call/return stack, I can overwrite another variable somewhere else, perhaps tricking your program into thinking it is debug mode. It gets harder, but not impossible.
What I was discussing was fine-grained memory bounds checking - which you simply cannot do when all you have is 8192 LDT and 8192 GDT entries, some of which have to be IDT gates, system call gates, task state segments, etc.
I sit here in shock and amazement - Macromedia actually has a Flash 6 plugin for Mozilla under Linux.
I must go out to my car now and roll up my windows - else those flying pigs will make a mess of my upholstery.
Anyone got a version that works with Xine - like an MPEG or DiVX?
(taken from the very link you gave, emphasis mine)?
Granted, I wasn't as clear as I should have been - I was referring to Netscapes user-content.css, which allows you to re-write a page on the fly. It is not possible to, in user-content.css, say "if the width of a table entry is between x and y, rewrite it to be *".
And again, if I, the reader, find it too hard to read the long lines of text, I, the reader, can resize my window until it is easy to read.
The webmaster(bater) does not know what my comfort threshold is.
Let me decide what I want to read.
This will affect all tables in the body. When you have the standard layout of nested tables, this won't work well.
I'm about to say something I would have never dreamed of saying a couple of years ago.
...
It is a shame that Intel made segments work the way they do, because a minor tweak and segments would have been the perfect way to prevent buffer overflows in hardware.
Consider: what if, instead of segment descriptors having to live in the GDT and LDT, they could be loaded into a register from a normal memory limit? True, they would then have been useless for OS level protection, but I assert that is what the page map is for (yes, the page mapper didn't exist prior to the 386, and enhanced segments showed up in the 286).
In some of the DSPs that I work with, you have registers to specify a region of memory. When you access off these registers, memory bounds are enforced by the chip (this allows for circular regions of memory, bit reversed addressing, and other weird things you need when doing DSP work).
What if you could have done something like this:
buffer:
ds 1024 ; a buffer of stuff
buffer_descr:
dd buffer ; where buffer starts
dd 1024 ; sizeof(buffer)
LDPROT ES,buffer_descr ; set limits checking
LD ES:(ESI),EAX ; store to buffer with checking.
Thus, any access out of bounds would throw a SIGSEGV.
Then, the code could have provided protection against overflows without explicit checking on every array access. True, this would not protect you if all you were given was the buffer address, but in the presense of this sort of hardware, GCC could have been modified to make a char (*a)[] (pointer to array of char) be three elements - base, sizeof(), index.
So, if you are running a 1600x1200 window and larger fonts (anti-aliasing? I need no anti-aliasing!)
you
get
an
article
like
thi
If the morons would either
then there wouldn't be a problem - large browser users like me would either get an article that spans the available space (the width option) or could at least override the setting on the article text in our CSS (the common class option).
I've contacted several sites about this. For example, PBS (hosters of the Cringely articles) responded saying "Some people don't like long lines of text, so there!" (OK, then they can resize their windows to get the line length they want.)
Unfortunately, since every site uses a slightly different "width=", and since CSS does not allow you to say "width=[400..800]" or something like that, you have to have a seperate entry for each site, and when the webmaster(bater) changes the layout you have to update your CSS and restart your browser.
I do wish people would realise that HTML is about giving enough info to my browser to render the page, not about being pixel-exact.
Great. Now certain people will be faking strokes down at the free clinic.
Others will be saying, "Nawww <hic> - this is muDICenal <hic> (sic)"
Besides, giving coffee to a drunk does not make him sober, giving coffee to a drunk just gives you a wide-awake drunk.
AOL is blocking DSL users from directly sending email. This is largely because of all the "U 2 kin make $$$ wit UR computer!!!!!" scams that are nothing more than spamming@home clients.
"WAAAAH!! I WANNA SEND MAIL FROM MY DSL" people cry (NOTE: I am on a DSL connection myself).
"FOO! Just use your ISP's mail server" other people say (that's what I do....)
"WAAAAH! MY ISP'S MAIL SERVER SUXORS!" the first group reply (I cannot understand how the ISP's connectivity works, but the mail server doesn't, but I digress).
OK, so what about this: why doesn't somebody set up a mail server, which requires its users to be authenticated beforehand, has a real TOS with fangs, claws, breath weapons, rocket launchers and other implements of mass destruction to be quickly turned upon violators, and which uses either SMTP-S or SSH style connections.
Thus, all the folks who use DSL, who's ISPs mail service is unacceptable, and who want an alternative can have a place they can connect to that is NOT a spam haven, NOT on a dynamic IP, NOT on blocklists, and thus everybody is happy.
After all, you can already buy your wire from one provider, your connectivity itself from another (in some places), your web space from a third. Why not mail services from a dedictated mail provider?
(NOTE: I am not talking Rot^H^H^H Hotmail or the like - I am talking a service that actually allows mail sending from something other than a Web page or proprietary client.)
1) Hydrates are not stable at room temperature and pressure - you still have to keep them cold (-10 C). Granted, -10C is better than -100C, but you will still have to have a refrigeration unit or a pressurized tank.
2) When you break the hydrate down, you have methane and water. You have to do something with the water - dump it on the ground, feed it into the engine to be vaporized, something.
3) While hydrates may store more methane than storing the methane as a gas, I don't think hydrates store more methane per unit volume than storing the methane as a liquid.
4) You are storing methane and water - you will have more mass per unit methane than storing just methane.
Those things said, this could be a good thing, in that anything that allows better storage and transport of methane makes it a more viable fuel source.
I never said they wanted the info to persecute^H^H^H^H^H^H^H^H^Hprosecute you - just that if they wanted the data on the drive they could get it.
However, if the data on the drive is embarassing, they could bring it out in court and make it a matter of public record.
If they REALLY want you, they use your data to find somebody else (say, the person you bought something illegal from) and then crack him to get the data to bust you.
These are some of the reasons that things like double jepordy are so important - with the resources of the state behind him, a prosecutor can crush anybody he wants without strong limits.
OK, I'll take this slowly.
The DA wants to decrypt your drive. He cannot.
He hits you with a supeona for the key. You have two choices - supply or refuse.
You refuse, citing your 5th amendment rights.
The DA offers you immunity.
You continue to refuse.
Since you have been offered immunity, you no longer have the protection of the 5th amendment, as you cannot incriminate yourself.
Therefor, you are in violation of the supeona - a court document.
You are, therefor, in contempt of court.
You are missing the point here - your 5th amendment right does not apply, because you are no longer incriminating yourself. That is the "trick" they use.
Read the 5th amendment. You cannot be compelled to incriminate yourself. If the testimony would not incriminate you (due to immunity being granted) then the 5th amendment does not apply.
Sorry, but this already has been done several times.
The best way to keep anything hidden from anybody is to keep them from ever knowing it existed in the first place - if they already know, or suspect, then it's already too late.
Sure, you might have your super-leet miniserver stuck in your heating ducts, powered by a little mini-windmill and linked via 802.11g to your house, with an emergency "shut up for 24 hours" command, and that might keep it from being found in a cursory search. But if the cops really think you have something on a computer in your house that is worth finding, they will find it. They will keep searching until they do, even if it takes days.
So the day after you are hauled downtown, one of the forensics team says "Hey, there's a signal here on 5GHz - get the spec-an in here and let's DF that puppy."
Now, if you used strong encryption, you might keep them from knowing what is on the disk, but find it they will. And they can compel you to provide the key - even here in the US, all they have to do is say "Fine - we won't charge you based on anything we find." That "poofing" sound was your 5th Amendment right becoming irrelevant - you can no longer incriminate yourself, so you can no longer refuse to testify and be protected. Continue to refuse, and they find you in contempt of court and lock you up until you change your mind.
Robert Heinlein made the point in "If This Goes On..." that the best thing in the world is to let them find something bad, but not bad enough to get you into trouble. So, if you are plotting the overthrow of the known world, you keep that info a deep, dark secret tattooed on the inside of your eyelids encrypted with a 4096 bit key, but you keep your goat porn on a drive they will find (with a little looking). Then, when they think you are hiding something and find the drive, they look a little longer, don't find anything, and move on.
But once again, the big trick is not to arouse suspicions in the first place. If they knock on the door, you've already lost.
If Kyptonite makes Kryptionians weak, does hematite make Hemos weak?
Perhaps Hemos should stay away from that area of Mars...
Because:
a) a quartz crystal is HUGE compared to the scale of devices that go into a CPU.
b) The quartz crystal needs an open area to vibrate in, again taking up a relatively large volume within the chip.
c) putting multiple "things" in the chip housing is expensive - hence why Intel went away from doing that as fast as they could.
In trying to keep my post as simple as possible, while focusing on the primary issue, I oversimplified a bit.
However, all my previous statement stand as to the impacts of this technique.
This technique is nothing more than embedding an oscillator on-chip, and using that to monitor the main clock.
Since most CPUs internally multiply their clock (you don't feed a 3.0 GHz P4 a 3.0 GHz clock, you feed it a much slower clock and it multiplies it up), why then don't manufacturer's just use an embedded clock and do away with all this?
Simple - it is very hard to have an accurate clock embedded in the CPU. External clocks can use a quartz crystal to vibrate and make the clock - an embedded oscillator would have to use an on-chip delay line or RC network, which will drift over time, temperature, and voltage.
So all they can do with a system like this is catch you if you are overclocking by a fairly large amount - were they to try to trap you at a 10% overclock they would have false trips due to process variation.
To extend the analogy the article used: you will get a speeding ticket if you are going 20 over the speed limit. Keep it less than 10 over and you will be fine.
NOTE: this is not advice condoning overclocking or speeding! This is just an analysis of the technology involved.
No solar radiation.
No absense of gravity.
No micrometeorite punctures.
Let's see, what else won't be an accurate simulation?
This sounds to me like it might be good for psychological research, and possible some life support systems work, but as for really simulating a trip....
I'd rather see somebody, anybody, start working on a real, permanently manned lunar base. You can at least BEGIN to simulate a trip then, while still being only a few days away from home if things go wrong.
But the Moon is no longer considered "sexy" by The Powers That Be.
Even though I am a subscriber, and I have my ad block count set to 0 (i.e. block all ads), and even though the /. crew say that should be fine for me to preview stories, I have yet to see one from TMF.
/. code isn't fully tested.
I don't think it is working.
But then, I also have not received moderation points in over a year, even though I M2 every day.
Personally, I think much of the
(Yes, this is OT - hence why I have hit the "No Karma Bonus" flag.)