Right on.
It looks like the major actors finally realize that developing and using systems for the future has a lot in common with clearing a field of land mines. There are too many gotcha's that bite in places you didn't know you had places. While I cannot imagine IBM and whatever has replaced the seven dwarves totally embracing open source, I think that they realize that it is suicidal not to utilize the advantages of open source in the core basic areas where it has an extreme advantage. I have nothing to back it up, but I think the interest of the big boys comes from the anecdotal tales of long uptime, not the well configured and it does its job, but the ill-configured, reconfigured, abused system that managed to stay up when they would be excused for dying from being hacked to death.
>>OpenBSD isnt vulnerable, and even if it is, it won't be in a few hours:) (blatant, I know:) It takes an attitude like that to even stand a reasonable chance of being reasonably secure.
It depends on how everything is connected. There is a vast difference between being dead if anything fails and being dead only if everything fails. I think that what killed off the mainframes was using the mainframe to emulate a gaggle of PCs. If it is done right (not easy), if the machine you rely on becomes overtaxed or dead, the load is shifted elsewhere. You are right to treat it with a high degree of scepticism. "The invasion was called off because some private stubbed his toe." Don't laugh, that is the normal state of affairs. Change the last byte of first sector of your boot drive. Create a unit check on an unknown device on IBM mainframe (maybe fixed now, instant death on IBM/360 MVS).
The idea of a cache is that you have a small, expensive, high-speed store and a large, cheap, low-speed store. With the right shenanigans you get the speed of fast store and the cost of the slow store. As a means of quickly and safely (across hardware failures) committing information to disk, network could be very useful, but nothing about the setup would be simple or easy.
>>Writing tightly-coupled distributed applications is both hard and wierd. I think there is a fundamental problem with the languages. A line is a sequence of characters. A file is a sequence of lines. A program is one linear order of something that is essentially a partial order. There is no way to explicitly denote what depends on what. DO A A1, A2, A3 DO B B1 after A2, B2, B3 DO C C1 after A1, C2 after A3, C3 DO D D1 after B2 and C1, D2 after C2, D3 after B3 and C3 Trivial, but alreadly too complicated. Haven't even used "or' yet. As far as I know, not expressible in any current mainstream language.
That's why Algol uses:= for assignment. OT: I wish languages would allow if 0 = x = 1 expressions. Something about conditionals and booleans being different concepts (?);)
I've got the RedHat 6.2 Professional (more like $170) and I'm smiling. When 7.2 comes around I'll be real interested again. The bugs squashed out by the free downloads, betas, CheapBytes, etc. make the boxed sets a real bargain.
I've actually seen IBM fix something. Fast. Once. A long time ago, Cobol compiler wouldn't work with new version of MVS. DP group were the ones who used the compiler, infrequently, so they just put in the disks for the old version whenever they needed to compile anything. No big problem except that sometimes the system was unusable because the wrong system was up. Playing a hunch, I had one of the DP guys run and dump the cobol compiler and found what I suspected. The Cobol compiler was using the same RECFM=FS (Fixed Standard) in DCBs that I had. The new version got into something to do with Fixed Spanned and wasn't moving the record pointer. So just patched the DCBs to RECFM=F and the compiler now worked on the new system. The next day, someone from IBM (looked field engineer and not very happy to be where he was) was messing with tape drives. Moral: If you can do it yourself, you can get some pretty good response.
With the 1 of 10 that does know what he is talking about, you are still right. Repeat the steps again. Oops, missed that (either direction) will happen all too often. To properly diagnose, you have to _know_, to the best available certitude. Regarding feelings, you _are_ an idiot if you do not know everything. One note. There is a big difference between "X is broken" and "I think X is broken".
Quick, what is 0xffff + 0xffff? If they are signed integers, the answer is -2. If they are unsigned integers, the answer is overflow. VAX and x86 distinguish between signed and unsigned by testing the condition codes. They have one add instruction used for both signed and unsigned arithmetic. They do not have the required information to know if it is an overflow condition or not. IBM/360 distinguishes between signed and unsigned by using different opcodes, so it can and does generate overflow exceptions. For fun, consider adding a signed integer to an unsigned integer and storing result into a signed integer and an unsigned integer respectively.
Curiously, the only direct caryovers from the PDP11 to the VAX were the condition codes.
Looks interesting. I'll be glad when and if something like this becomes mainstream. I think you will find persistence across system crashes to be fiendishly useful. Like recursion in print calls IO-error calls print. Recursion is necessary to unwind gracefully, instead of getting stuck in print returns to IO-error returns to print returns to IO-error ad infinitum.
minor glitch. read over it without noticing. I think the main reason is some combination of seing what it takes and how far can they take it, with the added bonus that it might actually be useful for something. This might give a bit of insign as to _why_ the animosity towards BillG and his software. It's more subtle and fundamental than just bugs or he's rich.
By const pointer, I assume your mean that the value of the pointer does not change. What constrains the value of the index into the array? You can do pointer arithmetic in Fortran by using indexes and a single carefully placed array.
Array A[10], B[10] Unless there is something that prevents me from accessing B[3] by means of A[13], including indirectly via subroutines,.... I forgot, what was the argument anyway?
Sorry, no mirror, but I did read most of it. Not bad really, but he was aproaching the Intel architecture from a Unix/VAX perspective rather than a Multics or Old Burroughs perspective. Overall probably better than the average of the decent/. posts. The problem is very real. He was looking for a magic bullet, with maybe a few ideas of his own. The problem has been solved, probably before he was born, and the solvers are mostly dead and buried. Nothing to be ashamed about. He should have left the thing up, with maybe a followup and a link to/.
Open range is faster and easier than dealing with well-tended fences. Unfortunately benchmarks measure what they can measure and the victor wins by shirking safeguards. Buffer overflows have been solved long ago, and the solvers are dead. IBM 1401, Burroughs. The worst is that the buffer overflow exploits, like the web defacements, are minor nuisances. The effect of storing the 11th element of a 10 element array can be rather damaging. The language is the right place to attack the problem, but the language exists at many different levels. There is also a problem in that there may be several different ways to interpret a set of bits in memory. There is also a problem in that it is much easier to point to something than to precisely delimit the extents. Language is the key, and it needs to be a box not a point. Not easy, not backwards compatible. Much that is running today is broken but nobody realizes it. When the buffer overflows, et. al. are handled, these programs will not run because they are in fact broken. Closed source or too lazy, you cannot fix the buffer overflow problem. Open source, just maybe.
If you actually _use_ the intel segment structure, you aim a read/write data segment at exactly the extent of code you need to modify, not the standard bit of CS:12345 being the same byte as DS:12345 being the same byte as SS:12345. With byte granularity, the segment can precisely delimit up to 1 Megabyte of code. With 4k granularity, the limit is 4G. For non-trivial security, I think Intel did it right, only none of the OS's follows through. Somethink like it works better to control the keys than to control the locks. There seems to be too much all or nothing, user or kernel. Anything legitimate has to be more complicated than that.
If you have 12 guests and room for 10 chairs on your property, you just put 2 chairs on you neighbors property. Chances are your neighbor neither knows nor cares. Everybody is happy... until...
Er, What is an array type in C? I can do an array declaration which does not allocate memory. I can do an array definition which does allocate memory. I can access the array as array[i] where i is outside the legal limits. I can also access the array as i[array] or *(i+array). If I pass an array to a subroutine, how is that subroutine prevented from accessing memory before or after the extents of the array?
That's funny. The only difference I've noticed is that/. seems to handle a lot more traffic without succombing itself to the/. effect. Just look how long (ie short) it has taken for the commentary to this to get saturated. Whoever or whatever, they are dong something right.
Nonsafe: Read or write reference to any array. Casting is safe enough. The problem is that any indirect reference to any kind of array is unbounded and capable of accessing all of available memory.
Except for hardware designed to run Multics, a flat address space is probably the only possibility. Any system that allows "coloring outside the lines" will be susceptible to buffer overruns or worse. And they all do with possible exceptions of such as Ada, Algol68, LISP, or some of the modern languages. I think the purpose of the segmented arch was to allow some degree of separation of different things into different logical segments, but it turned into a mess of segment address arithmetic to turn 48-bit pointers (16-bit segment+32-bit offset) into a 20-bit (real mode, to break the 64k barrier) or 32-bit (protected mode) pointer. To protect against buffer overruns (character string to character string), there is probably nothing since to equal the IBM 1401 machine language. Move A to B where A is longer than B and B is NOT overrun. Used word marks and record marks in addition to the 8 data bits.
Because it is actually fixed on the Intel architecture and broken on the VAX. It's really the OS's that are broken, limiting the Intel to being only a bad version of a VAX.
To check against bounds you must have the bounds to check against. The semantics of memory allocation need to be considered. I think almost all forms return a pointer to somewhere within the heap. Clever or inadvertent messing with pointer[-n] should be capable of doing some wierd or disastrous things. There is help possible from the intel hardware. The OS could return a 16-bit segment register capable of referencing exactly the allocated memory. Unfortunately, there are only some 8000+ available possibilities for the return value.
Slashdot Mirror
Right on.
It looks like the major actors finally realize that developing and using systems for the future has a lot in common with clearing a field of land mines. There are too many gotcha's that bite in places you didn't know you had places. While I cannot imagine IBM and whatever has replaced the seven dwarves totally embracing open source, I think that they realize that it is suicidal not to utilize the advantages of open source in the core basic areas where it has an extreme advantage. I have nothing to back it up, but I think the interest of the big boys comes from the anecdotal tales of long uptime, not the well configured and it does its job, but the ill-configured, reconfigured, abused system that managed to stay up when they would be excused for dying from being hacked to death.
>>OpenBSD isnt vulnerable, and even if it is, it won't be in a few hours :) (blatant, I know:)
It takes an attitude like that to even stand a reasonable chance of being reasonably secure.
It depends on how everything is connected. There is a vast difference between being dead if anything fails and being dead only if everything fails. I think that what killed off the mainframes was using the mainframe to emulate a gaggle of PCs. If it is done right (not easy), if the machine you rely on becomes overtaxed or dead, the load is shifted elsewhere. You are right to treat it with a high degree of scepticism.
"The invasion was called off because some private stubbed his toe." Don't laugh, that is the normal state of affairs. Change the last byte of first sector of your boot drive. Create a unit check on an unknown device on IBM mainframe (maybe fixed now, instant death on IBM/360 MVS).
Isn't that the basis for Microsoft.net?
The idea of a cache is that you have a small, expensive, high-speed store and a large, cheap, low-speed store. With the right shenanigans you get the speed of fast store and the cost of the slow store.
As a means of quickly and safely (across hardware failures) committing information to disk, network could be very useful, but nothing about the setup would be simple or easy.
>>Writing tightly-coupled distributed applications is both hard and wierd.
I think there is a fundamental problem with the languages.
A line is a sequence of characters.
A file is a sequence of lines.
A program is one linear order of something that is essentially a partial order.
There is no way to explicitly denote what depends on what.
DO A A1, A2, A3
DO B B1 after A2, B2, B3
DO C C1 after A1, C2 after A3, C3
DO D D1 after B2 and C1, D2 after C2, D3 after B3 and C3
Trivial, but alreadly too complicated. Haven't even used "or' yet. As far as I know, not expressible in any current mainstream language.
Bah. Plain text eats less-than signs.
if 0 <= x <= 1
That's why Algol uses := for assignment. ;)
OT: I wish languages would allow if 0 = x = 1 expressions. Something about conditionals and booleans being different concepts (?)
I've got the RedHat 6.2 Professional (more like $170) and I'm smiling. When 7.2 comes around I'll be real interested again. The bugs squashed out by the free downloads, betas, CheapBytes, etc. make the boxed sets a real bargain.
I've actually seen IBM fix something. Fast. Once.
A long time ago, Cobol compiler wouldn't work with new version of MVS. DP group were the ones who used the compiler, infrequently, so they just put in the disks for the old version whenever they needed to compile anything. No big problem except that sometimes the system was unusable because the wrong system was up.
Playing a hunch, I had one of the DP guys run and dump the cobol compiler and found what I suspected. The Cobol compiler was using the same RECFM=FS (Fixed Standard) in DCBs that I had. The new version got into something to do with Fixed Spanned and wasn't moving the record pointer. So just patched the DCBs to RECFM=F and the compiler now worked on the new system.
The next day, someone from IBM (looked field engineer and not very happy to be where he was) was messing with tape drives.
Moral: If you can do it yourself, you can get some pretty good response.
With the 1 of 10 that does know what he is talking about, you are still right.
Repeat the steps again. Oops, missed that (either direction) will happen all too often.
To properly diagnose, you have to _know_, to the best available certitude. Regarding feelings, you _are_ an idiot if you do not know everything.
One note. There is a big difference between "X is broken" and "I think X is broken".
Quick, what is 0xffff + 0xffff?
If they are signed integers, the answer is -2.
If they are unsigned integers, the answer is overflow.
VAX and x86 distinguish between signed and unsigned by testing the condition codes. They have one add instruction used for both signed and unsigned arithmetic. They do not have the required information to know if it is an overflow condition or not.
IBM/360 distinguishes between signed and unsigned by using different opcodes, so it can and does generate overflow exceptions.
For fun, consider adding a signed integer to an unsigned integer and storing result into a signed integer and an unsigned integer respectively.
Curiously, the only direct caryovers from the PDP11 to the VAX were the condition codes.
Looks interesting. I'll be glad when and if something like this becomes mainstream.
I think you will find persistence across system crashes to be fiendishly useful. Like recursion in print calls IO-error calls print. Recursion is necessary to unwind gracefully, instead of getting stuck in print returns to IO-error returns to print returns to IO-error ad infinitum.
minor glitch. read over it without noticing.
I think the main reason is some combination of seing what it takes and how far can they take it, with the added bonus that it might actually be useful for something.
This might give a bit of insign as to _why_ the animosity towards BillG and his software. It's more subtle and fundamental than just bugs or he's rich.
By const pointer, I assume your mean that the value of the pointer does not change.
.... I forgot, what was the argument anyway?
What constrains the value of the index into the array?
You can do pointer arithmetic in Fortran by using indexes and a single carefully placed array.
Array A[10], B[10]
Unless there is something that prevents me from accessing B[3] by means of A[13], including indirectly via subroutines,
Sorry, no mirror, but I did read most of it. /. posts. The problem is very real. He was looking for a magic bullet, with maybe a few ideas of his own. The problem has been solved, probably before he was born, and the solvers are mostly dead and buried. Nothing to be ashamed about. He should have left the thing up, with maybe a followup and a link to /.
Not bad really, but he was aproaching the Intel architecture from a Unix/VAX perspective rather than a Multics or Old Burroughs perspective.
Overall probably better than the average of the decent
Open range is faster and easier than dealing with well-tended fences. Unfortunately benchmarks measure what they can measure and the victor wins by shirking safeguards.
Buffer overflows have been solved long ago, and the solvers are dead. IBM 1401, Burroughs.
The worst is that the buffer overflow exploits, like the web defacements, are minor nuisances. The effect of storing the 11th element of a 10 element array can be rather damaging.
The language is the right place to attack the problem, but the language exists at many different levels. There is also a problem in that there may be several different ways to interpret a set of bits in memory. There is also a problem in that it is much easier to point to something than to precisely delimit the extents. Language is the key, and it needs to be a box not a point. Not easy, not backwards compatible. Much that is running today is broken but nobody realizes it. When the buffer overflows, et. al. are handled, these programs will not run because they are in fact broken. Closed source or too lazy, you cannot fix the buffer overflow problem. Open source, just maybe.
If you actually _use_ the intel segment structure, you aim a read/write data segment at exactly the extent of code you need to modify, not the standard bit of CS:12345 being the same byte as DS:12345 being the same byte as SS:12345.
... until ...
With byte granularity, the segment can precisely delimit up to 1 Megabyte of code. With 4k granularity, the limit is 4G.
For non-trivial security, I think Intel did it right, only none of the OS's follows through. Somethink like it works better to control the keys than to control the locks.
There seems to be too much all or nothing, user or kernel. Anything legitimate has to be more complicated than that.
If you have 12 guests and room for 10 chairs on your property, you just put 2 chairs on you neighbors property. Chances are your neighbor neither knows nor cares. Everybody is happy
Er,
What is an array type in C?
I can do an array declaration which does not allocate memory.
I can do an array definition which does allocate memory.
I can access the array as array[i] where i is outside the legal limits.
I can also access the array as i[array] or *(i+array).
If I pass an array to a subroutine, how is that subroutine prevented from accessing memory before or after the extents of the array?
That's funny. The only difference I've noticed is that /. seems to handle a lot more traffic without succombing itself to the /. effect.
Just look how long (ie short) it has taken for the commentary to this to get saturated.
Whoever or whatever, they are dong something right.
Even better:
Allocate A;
Free A;
Allocate B;
Free A;
Allocate C;
Store into B;
Betcha C has got some problems.
Nonsafe:
Read or write reference to any array.
Casting is safe enough. The problem is that any indirect reference to any kind of array is unbounded and capable of accessing all of available memory.
Except for hardware designed to run Multics, a flat address space is probably the only possibility.
Any system that allows "coloring outside the lines" will be susceptible to buffer overruns or worse. And they all do with possible exceptions of such as Ada, Algol68, LISP, or some of the modern languages.
I think the purpose of the segmented arch was to allow some degree of separation of different things into different logical segments, but it turned into a mess of segment address arithmetic to turn 48-bit pointers (16-bit segment+32-bit offset) into a 20-bit (real mode, to break the 64k barrier) or 32-bit (protected mode) pointer.
To protect against buffer overruns (character string to character string), there is probably nothing since to equal the IBM 1401 machine language. Move A to B where A is longer than B and B is NOT overrun. Used word marks and record marks in addition to the 8 data bits.
Because it is actually fixed on the Intel architecture and broken on the VAX. It's really the OS's that are broken, limiting the Intel to being only a bad version of a VAX.
To check against bounds you must have the bounds to check against.
The semantics of memory allocation need to be considered. I think almost all forms return a pointer to somewhere within the heap. Clever or inadvertent messing with pointer[-n] should be capable of doing some wierd or disastrous things.
There is help possible from the intel hardware. The OS could return a 16-bit segment register capable of referencing exactly the allocated memory. Unfortunately, there are only some 8000+ available possibilities for the return value.