 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/1/2011 13:32, Orchid XP v8 wrote:
> I had presumed this carried over from MS-DOS
> (although I couldn't say what version).
Version 2.0 introduced directories, as well as the path-like calls (i.e.,
where you pass the file name as a UNIXy string rather than a FCB).
Version 3.22 was the first that actually looked at the control information
in the boot sector to decide how many sectors were on the floppy and such.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/2/2011 13:37, Jim Henderson wrote:
> Those two statements contradict each other. PowerShell is a command
> prompt, is it not?
It's a command line interpreter. You'll confuse the crap out of everyone if
you call it a "command prompt", since the old command interpreter is called
"command".
It would be like calling a .pov file a "batch file" of SDL commands.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 06.06.2011 18:17, schrieb Darren New:
> If you really want to see, look at some of the new OS research. Read the
> Singularity design documents, for example. There's some really cool
> stuff in there when you get an OS that can rely on your programs
> actually declaring in their manifest what resources they need and the OS
> can rely on the programs actually obeying the semantics of the OS.
> (E.g., you get stuff like bits of the kernel being compiled into the
> executable code for efficiency, stuff like page faults being handled in
> user space, etc.)
/Relying/ on the programs /obeying/ anything particular?
From what you write, it sounds like the inventors of that OS have never
heard the term "malware" in their whole life.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/6/2011 10:32, clipka wrote:
> /Relying/ on the programs /obeying/ anything particular?
Yes, because the executable MSIL code is checked for correctness by code
that has, in turn, been proven to be correct. Just as one example. Or
because the kernel code is mathematically proven to be correct.
Of course, if you corrupt the hardware like in the Sony example, that's
something rather beyond what I'd call "malware".
> From what you write, it sounds like the inventors of that OS have never
> heard the term "malware" in their whole life.
It's Microsoft. I'm pretty sure they've heard of malware. Indeed, the whole
point of designing it like they did is, for one thing, to keep malware from
running. I'm pretty sure, for example, that there's no formal mathematical
proof that keeps Linux, for example, from letting a process access memory
belonging to another process. Nor is there a mechanism in place in most
operating systems to restrict file access to only those files a program
declares at compile time that it will access, or to keep a device driver
from accessing arbitrary other device addresses, or to limit authorization
based on which program did the authentication. Indeed, in the current
incarnation, it's impossible to modify the collection of executable code
without rebooting the machine; installing a program is the only way to
modify what can be executed, and that in turn requires a reboot. (Altho I'm
pretty sure that's merely a limitation, not a design intention.)
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/06/2011 05:10 PM, Darren New wrote:
> On 6/1/2011 3:51, Invisible wrote:
>> How random is that?
>
> It's not at all random. It's also the reason you can unmount a drive
> where your cwd is set in Windows and not in UNIX.
Actually, last time I tried it, you can't do this in Windows either.
> How come every time you come across legacy support, you say it's a
> kludge or a wtf or a random? :-)
What was a good idea 40 years ago is not necessarily a good idea today.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/6/2011 11:05, Darren New wrote:
> I'm pretty sure, for example, that there's no formal mathematical
> proof that keeps Linux, for example, from letting a process access memory
> belonging to another process.
For that matter, there's very few systems out there that require all your
code to be digitally signed and which checks it every time you fire it up,
other than game consoles and phones for copy-protection purposes.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 06.06.2011 20:14, schrieb Darren New:
> For that matter, there's very few systems out there that require all
> your code to be digitally signed and which checks it every time you fire
> it up, other than game consoles and phones for copy-protection purposes.
... and still, even /those/ seem to keep dropping their pants if
addressed in the right manner. And you'd think, if anyone is willing to
invest real money into such systems, it would be the makers of such
systems (apart from military or secret agencies of course).
Seems like the problem is not /that/ easily solved...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/6/2011 11:10, Orchid XP v8 wrote:
> Actually, last time I tried it, you can't do this in Windows either.
Not only can you dismount it, when you remount it, you have the same cwd.
Since every drive has a cwd, it would be impossible to dismount any drive if
you couldn't dismount one where you had a cwd set.
>> How come every time you come across legacy support, you say it's a
>> kludge or a wtf or a random? :-)
>
> What was a good idea 40 years ago is not necessarily a good idea today.
That doesn't make it a kludge or a wtf or a random. It makes it an idea
whose time has passed.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/6/2011 12:51, clipka wrote:
> ... and still, even /those/ seem to keep dropping their pants if addressed
> in the right manner.
Usually through the use of a hardware hack, tho.
The Sony hack required him to actually wire up the motherboard with switch
shorting out traces. The XBox hack was, IIRC, not so much a flaw in the
security of the system, but a broken game that let you run code from a saved
game (via buffer overflow or some such).
That's exactly why you need to do something like formal logical checks that
your code does the right thing at the lowest levels, then make everyone
conform to that.
When you're talking security against malware rather than copy protection,
it's a lot easier to get right, in some ways, because you don't *ever* want
the malware to run. Nobody is going to be sticking debuggers on the chip or
shorting out motherboard traces in order to get malware running on their own
machine.
--
Darren New, San Diego CA, USA (PST)
"Coding without comments is like
driving without turn signals."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 06.06.2011 22:15, schrieb Darren New:
> On 6/6/2011 12:51, clipka wrote:
>> ... and still, even /those/ seem to keep dropping their pants if
>> addressed
>> in the right manner.
>
> Usually through the use of a hardware hack, tho.
>
> The Sony hack required him to actually wire up the motherboard with
> switch shorting out traces. The XBox hack was, IIRC, not so much a flaw
> in the security of the system, but a broken game that let you run code
> from a saved game (via buffer overflow or some such).
>
> That's exactly why you need to do something like formal logical checks
> that your code does the right thing at the lowest levels, then make
> everyone conform to that.
Ah yes - a formal proof... pretty useful if your intention is to make
sure a security-critical system never fails due to unforeseen errors.
As for making sure that a system is secure against /malicious intent/, I
believe it's pretty useless.
Just have a look at smart cards: For a given smart card design, you may
formally prove that there is no input sequence that makes the card
disclose even a single bit of its secret key...
... on its /official/ interface, i.e. the I2C bus data lines. But such a
formal analysis typically forgets a few other channels on which the
device is leaking information. For instance, an analysis may forget
about the timing of the data output, which might give hints about what's
going on inside. Or the power the chip consumes at any given time.
Say you will - I think a formal analysis can never foresee /all/
possible attack vectors a system might exhibit.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
