🚀 go-pugleaf

Quadibloc wrote:
> On some tech news site, I came across a comment to the effect that things
like
> Meltdown and Spectre wouldn't be such a big deal...
>
> if the only executable content our computers ran were programs we installed
on
> them.
>
> Of course, that wouldn't prevent viruses 100%, but it would return things
back to
> the situation that existed before the Internet.
>
> So when viewing a web site, the server would have to do all the work of any
fancy
> programmed behavior of the site. The computer would act like it was just a
TV set
> for viewing the site.
>
> I think that this suggestion is a little too extreme. After all, millions of
> people might be viewing a site on a tiny little server. So the computers of
> people viewing web sites have to be expected to do some of the work.
>
> But given that fixes for Meltdown and Spectre will apparently make computers
> slower, this inspired me to think of a way that this idea could be modified
to
> be usable.
>
> Maybe every computer that views the Internet, to be secure, needs to be two
> computers.
>
> One conventional computer that's fast, and has, as a result, imperfect
security,
> that one uses to run one's own programs.
>
> And a second very secure and somewhat slow computer. When viewing web sites,
or
> opening word processor documents with macros, and so on, in order to
properly
> sandbox this foreign executable content, it gets run on the slow computer.
>
> The slow computer's supervisory program runs in memory that looks like ROM
to
> it, but which is writeable by the fast computer - and only the fast computer
can
> access the hard drive. The slow computer would be slow because it wouldn't
do
> dangerous things like speculation; if necessary, it might not even be
pipelined.
>
> Outputs from the slow computer would be processed by the fast computer to
> display them to the user; so the fast computer would still have to have bug
free
> programs without vulnerabilities to display web sites, display video and
images,
> and so on. So it would not be a panacea for security, it would simply deal
with
> the most uncontrollable class of vulnerabilities. The fast computer would
still
> need security measures to prevent things like buffer overflows.

Doesn't a personal router provide the slow computer's functionality?

/BAH

jmfbahciv <See....@aol.com> writes:
>Quadibloc wrote:
>> On some tech news site, I came across a comment to the effect that things
>like
>> Meltdown and Spectre wouldn't be such a big deal...
>>
>> if the only executable content our computers ran were programs we installed
>on
>> them.
>>
>> Of course, that wouldn't prevent viruses 100%, but it would return things
>back to
>> the situation that existed before the Internet.
>>
>> So when viewing a web site, the server would have to do all the work of any
>fancy
>> programmed behavior of the site. The computer would act like it was just a
>TV set
>> for viewing the site.
>>
>> I think that this suggestion is a little too extreme. After all, millions of
>> people might be viewing a site on a tiny little server. So the computers of
>> people viewing web sites have to be expected to do some of the work.
>>
>> But given that fixes for Meltdown and Spectre will apparently make computers
>> slower, this inspired me to think of a way that this idea could be modified
>to
>> be usable.
>>
>> Maybe every computer that views the Internet, to be secure, needs to be two
>> computers.
>>
>> One conventional computer that's fast, and has, as a result, imperfect
>security,
>> that one uses to run one's own programs.
>>
>> And a second very secure and somewhat slow computer. When viewing web sites,
>or
>> opening word processor documents with macros, and so on, in order to
>properly
>> sandbox this foreign executable content, it gets run on the slow computer.
>>
>> The slow computer's supervisory program runs in memory that looks like ROM
>to
>> it, but which is writeable by the fast computer - and only the fast computer
>can
>> access the hard drive. The slow computer would be slow because it wouldn't
>do
>> dangerous things like speculation; if necessary, it might not even be
>pipelined.
>>
>> Outputs from the slow computer would be processed by the fast computer to
>> display them to the user; so the fast computer would still have to have bug
>free
>> programs without vulnerabilities to display web sites, display video and
>images,
>> and so on. So it would not be a panacea for security, it would simply deal
>with
>> the most uncontrollable class of vulnerabilities. The fast computer would
>still
>> need security measures to prevent things like buffer overflows.
>
>Doesn't a personal router provide the slow computer's functionality?
>

No, it's a specialized device for packet forwarding.

ARM has an architecture called BigLittle, where a multiprocessor
die consists of several high-end (e.g. out of order, high power, high frequency)
cores (e.g. A57 or A75) and one or two smaller, low-power, in-order
cores).   The operating software can direct tasks to the appropriate
type of core and can power off the high-power cores when not necessary.

On Tue, 2018-01-30, Quadibloc wrote:
> On some tech news site, I came across a comment to the effect that things like 
> Meltdown and Spectre wouldn't be such a big deal...
>
> if the only executable content our computers ran were programs we installed on 
> them.

That ignores the multiuser aspect of computers.

> Of course, that wouldn't prevent viruses 100%, but it would return things back to 
> the situation that existed before the Internet.
>
> So when viewing a web site, the server would have to do all the work of any fancy 
> programmed behavior of the site. The computer would act like it was just a TV set 
> for viewing the site.
>
> I think that this suggestion is a little too extreme. After all, millions of 
> people might be viewing a site on a tiny little server. So the computers of 
> people viewing web sites have to be expected to do some of the work.

A little less fancy programmed behavior would be nice for a
change. Especially since it seems to be there for the benefit of the
content provider most of the time.

I wonder what the energy budget looks like for e.g.:
- Wikipedia
- YouTube
- Facebook
- Google's search engine, and their ads business
- Usenet

I.e. how many watts get burned, and where in the chain.  I imagine
that it varies widely, and that the clever operators try to push it
client-side.

Is there any good research on this?

[snip computer architecture idea; sorry for not at commenting this time]

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

On Tuesday, January 30, 2018 at 7:35:53 AM UTC-7, jmfbahciv wrote:

> Doesn't a personal router provide the slow computer's functionality?

I'm thinking of doing stuff like running the JavaScript on web pages. Routers don't do that.

However, I've thought some more, and this can be less elaborate. How about 
simply a special virtualization mode where, to assist sandboxing, the virtual 
machine is running in a mode where a lot of possible attacks on the virtual 
machine boundaries are precluded - at the cost of the VM running a bit slower.

John Savard

On Tuesday, January 30, 2018 at 8:35:25 AM UTC-7, Jorgen Grahn wrote:
> On Tue, 2018-01-30, Quadibloc wrote:

> > On some tech news site, I came across a comment to the effect that things like 
> > Meltdown and Spectre wouldn't be such a big deal...

> > if the only executable content our computers ran were programs we installed on 
> > them.

> That ignores the multiuser aspect of computers.

Well, if a computer is multi-user, you only want the admins to be able to 
install software. Requiring applications software to be usable by users other 
than an admin would promote good coding practice...

John Savard

On 2018-01-30, Quadibloc <jsa...@ecn.ab.ca> wrote:

> On some tech news site, I came across a comment to the effect that things
> like Meltdown and Spectre wouldn't be such a big deal...
>
> if the only executable content our computers ran were programs we installed
> on them.

Then there are the programs the vendor installs on them, a.k.a "automatic
updates"...

> Maybe every computer that views the Internet, to be secure, needs to be two 
> computers.
>
> One conventional computer that's fast, and has, as a result, imperfect
> security, that one uses to run one's own programs.
>
> And a second very secure and somewhat slow computer. When viewing web sites,
> or opening word processor documents with macros, and so on, in order to
> properly sandbox this foreign executable content, it gets run on the slow
> computer.

I have something like that now.  When I do local processing my machine is
quite fast.  But there's a webmail server I sometimes use which switches
to the slow computer.  At least it acts like that; responses take between
10 and 30 seconds, and one CPU core is saturated all that time.

(Ow, my cheek hurts from putting my tongue that far into it...)

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  HTML will DEFINITELY be ignored.  Join the ASCII ribbon campaign!

Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes:

> I have something like that now.  When I do local processing my machine is
> quite fast.  But there's a webmail server I sometimes use which switches
> to the slow computer.  At least it acts like that; responses take between
> 10 and 30 seconds, and one CPU core is saturated all that time.
> 
> (Ow, my cheek hurts from putting my tongue that far into it...)

Possibly relevant?

   http://idlewords.com/talks/website_obesity.htm

Never made any sense to me vigorously to scrutinize software to be
installed for threats, then cruise the net sucking in megabytes of
heterogeneous js code.  Whose code?  Whose benefit?  Whose purposes?


-- 
Mike Spencer                  Nova Scotia, Canada

On Tue, 30 Jan 2018 10:24:48 -0800 (PST), Quadibloc
<jsa...@ecn.ab.ca> wrote:

>On Tuesday, January 30, 2018 at 8:35:25 AM UTC-7, Jorgen Grahn wrote:
>> On Tue, 2018-01-30, Quadibloc wrote:
>
>> > On some tech news site, I came across a comment to the effect that things like 
>> > Meltdown and Spectre wouldn't be such a big deal...
>
>> > if the only executable content our computers ran were programs we installed on 
>> > them.
>
>> That ignores the multiuser aspect of computers.
>
>Well, if a computer is multi-user, you only want the admins to be able to 
>install software. Requiring applications software to be usable by users other 
>than an admin would promote good coding practice...

It's the 21st century.  "Admin" is a more complex term than you think
it is.  I am an admin for a machine that is hosted on Amazon.  I can
install and delete software, authorize and deny users, establish
domain privileges, the whole nine yards.  However there is a higher
level of admin that is allowed to create virtual machines such as the
one for which I am an admin.

On Tuesday, January 30, 2018 at 8:09:11 PM UTC-7, J. Clarke wrote:

> It's the 21st century.  "Admin" is a more complex term than you think
> it is.  I am an admin for a machine that is hosted on Amazon.  I can
> install and delete software, authorize and deny users, establish
> domain privileges, the whole nine yards.  However there is a higher
> level of admin that is allowed to create virtual machines such as the
> one for which I am an admin.

Of course security for cloud machines is different from that for a personal 
computer. But personal computers have security issues that new hardware features 
might give assistance with.

John Savard

Scott Lurndal wrote:
> jmfbahciv <See....@aol.com> writes:
>>Quadibloc wrote:
>>> On some tech news site, I came across a comment to the effect that things
>>like
>>> Meltdown and Spectre wouldn't be such a big deal...
>>>
>>> if the only executable content our computers ran were programs we
installed
>>on
>>> them.
>>>
>>> Of course, that wouldn't prevent viruses 100%, but it would return things
>>back to
>>> the situation that existed before the Internet.
>>>
>>> So when viewing a web site, the server would have to do all the work of
any
>>fancy
>>> programmed behavior of the site. The computer would act like it was just a
>>TV set
>>> for viewing the site.
>>>
>>> I think that this suggestion is a little too extreme. After all, millions
of
>>> people might be viewing a site on a tiny little server. So the computers
of
>>> people viewing web sites have to be expected to do some of the work.
>>>
>>> But given that fixes for Meltdown and Spectre will apparently make
computers
>>> slower, this inspired me to think of a way that this idea could be
modified
>>to
>>> be usable.
>>>
>>> Maybe every computer that views the Internet, to be secure, needs to be
two
>>> computers.
>>>
>>> One conventional computer that's fast, and has, as a result, imperfect
>>security,
>>> that one uses to run one's own programs.
>>>
>>> And a second very secure and somewhat slow computer. When viewing web
sites,
>>or
>>> opening word processor documents with macros, and so on, in order to
>>properly
>>> sandbox this foreign executable content, it gets run on the slow computer.
>>>
>>> The slow computer's supervisory program runs in memory that looks like ROM
>>to
>>> it, but which is writeable by the fast computer - and only the fast
computer
>>can
>>> access the hard drive. The slow computer would be slow because it wouldn't
>>do
>>> dangerous things like speculation; if necessary, it might not even be
>>pipelined.
>>>
>>> Outputs from the slow computer would be processed by the fast computer to
>>> display them to the user; so the fast computer would still have to have
bug
>>free
>>> programs without vulnerabilities to display web sites, display video and
>>images,
>>> and so on. So it would not be a panacea for security, it would simply deal
>>with
>>> the most uncontrollable class of vulnerabilities. The fast computer would
>>still
>>> need security measures to prevent things like buffer overflows.
>>
>>Doesn't a personal router provide the slow computer's functionality?
>>
>
> No, it's a specialized device for packet forwarding.
>
> ARM has an architecture called BigLittle, where a multiprocessor
> die consists of several high-end (e.g. out of order, high power, high
frequency)
> cores (e.g. A57 or A75) and one or two smaller, low-power, in-order
> cores).   The operating software can direct tasks to the appropriate
> type of core and can power off the high-power cores when not necessary.

that doesn't prevent "bad bits" from occupying the machine.  I would
think that a goal should be to prevent this; so the slow machine or
slow core would be in the box which passes bits to the real machine.


/BAH

jmfbahciv <See....@aol.com> writes:
>Scott Lurndal wrote:
>> jmfbahciv <See....@aol.com> writes:
>>>Quadibloc wrote:
>>>> On some tech news site, I came across a comment to the effect that things
>>>like
>>>> Meltdown and Spectre wouldn't be such a big deal...
>>>>
>>>> if the only executable content our computers ran were programs we
>installed
>>>on
>>>> them.
>>>>
>>>> Of course, that wouldn't prevent viruses 100%, but it would return things
>>>back to
>>>> the situation that existed before the Internet.
>>>>
>>>> So when viewing a web site, the server would have to do all the work of
>any
>>>fancy
>>>> programmed behavior of the site. The computer would act like it was just a
>>>TV set
>>>> for viewing the site.
>>>>
>>>> I think that this suggestion is a little too extreme. After all, millions
>of
>>>> people might be viewing a site on a tiny little server. So the computers
>of
>>>> people viewing web sites have to be expected to do some of the work.
>>>>
>>>> But given that fixes for Meltdown and Spectre will apparently make
>computers
>>>> slower, this inspired me to think of a way that this idea could be
>modified
>>>to
>>>> be usable.
>>>>
>>>> Maybe every computer that views the Internet, to be secure, needs to be
>two
>>>> computers.
>>>>
>>>> One conventional computer that's fast, and has, as a result, imperfect
>>>security,
>>>> that one uses to run one's own programs.
>>>>
>>>> And a second very secure and somewhat slow computer. When viewing web
>sites,
>>>or
>>>> opening word processor documents with macros, and so on, in order to
>>>properly
>>>> sandbox this foreign executable content, it gets run on the slow computer.
>>>>
>>>> The slow computer's supervisory program runs in memory that looks like ROM
>>>to
>>>> it, but which is writeable by the fast computer - and only the fast
>computer
>>>can
>>>> access the hard drive. The slow computer would be slow because it wouldn't
>>>do
>>>> dangerous things like speculation; if necessary, it might not even be
>>>pipelined.
>>>>
>>>> Outputs from the slow computer would be processed by the fast computer to
>>>> display them to the user; so the fast computer would still have to have
>bug
>>>free
>>>> programs without vulnerabilities to display web sites, display video and
>>>images,
>>>> and so on. So it would not be a panacea for security, it would simply deal
>>>with
>>>> the most uncontrollable class of vulnerabilities. The fast computer would
>>>still
>>>> need security measures to prevent things like buffer overflows.
>>>
>>>Doesn't a personal router provide the slow computer's functionality?
>>>
>>
>> No, it's a specialized device for packet forwarding.
>>
>> ARM has an architecture called BigLittle, where a multiprocessor
>> die consists of several high-end (e.g. out of order, high power, high
>frequency)
>> cores (e.g. A57 or A75) and one or two smaller, low-power, in-order
>> cores).   The operating software can direct tasks to the appropriate
>> type of core and can power off the high-power cores when not necessary.
>
>that doesn't prevent "bad bits" from occupying the machine. 


Why would you say that?   What possible knowlege of
the ARM solution do you have other than the very limited
description above?  Don't you think very smart people have
considered the security aspects of the design, specifically
in light of modern threat scenarios?

Quadibloc <jsa...@ecn.ab.ca> writes:
> Of course security for cloud machines is different from that for a
> personal computer. But personal computers have security issues that
> new hardware features might give assistance with.

late 90s, EU had FINREAD standard which assumed insecure, compromised
and/or "public" PCs that couldn't be trusted and provided for end-to-end
trust. page/site ... gone 404 but lives on at wayback machine
https://web.archive.org/web/20021223205124/http://www.finread.com/pages/finread_initiatives/ec_funded_projects/02_embedded.html
some past posts
http://www.garlic.com/~lynn/subintegrity.html#finread

at the time, the payment card associations were working on two different
(secure) specifications ... one for point-of-sale, and different one for
home consumer ... for both they goofed on some things. recent discussion
in post about serial port devices for home consumer and "YES CARD"
period for point-of-sale
http://www.garlic.com/~lynn/2018.html#94 Predicting the future in five years as seen from 1983

it turns out that FINREAD was also one of the casualties of the serial
port fiasco (which has never recovered) ... and "YES CARD" did in a
large US point-of-sale pilot (and prediction that it would be a long
time before it was tried again in the US, waiting until the kinks were
worked out in other jurisdictions) ... "YES CARD" posts
http://www.garlic.com/~lynn/subintegrity.html#yescard

as mentioned, somewhat for having done electronic commerce, in mid-90s,
roped in to be part of the X9A10 financial standard working group which
had been given the requirement to "preserve the integrity of the
financial infrastructure" for *ALL* retail payments (i.e. standard for
*ALL*, i.e. point-of-sale, unattended, face-to-face, internet, home
consumer, etc). Besides standard for *ALL*, it didn't have the
vulnerabilities and exploits that were characteristic of the industry
specifications of the period. transaction standard reference
http://www.garlic.com/~lynn/x959.html#x959
hardware token reference
http://www.garlic.com/~lynn/x959.html#aads

lead technical director of the agency information assurance directorate
had assurance session in the trusted computing track at past IDF ...
where I presented on trust & assurance ... gone 404, but lives
on at wayback machine
http://web.archive.org/web/20011109072807/http://www.intel94.com/idf/spr2001/sessiondescription.asp?id=stp+s13

trivia: much earlier computer security reference ... also gone 404, but
also lives on at the wayback machine
http://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml

assurance related posts
http://www.garlic.com/~lynn/subintegrity.html#assurance

-- 
virtualization experience starting Jan1968, online at home since Mar1970

Scott Lurndal wrote:
> jmfbahciv <See....@aol.com> writes:
>>Scott Lurndal wrote:
>>> jmfbahciv <See....@aol.com> writes:
>>>>Quadibloc wrote:
>>>>> On some tech news site, I came across a comment to the effect that
things
>>>>like
>>>>> Meltdown and Spectre wouldn't be such a big deal...
>>>>>
>>>>> if the only executable content our computers ran were programs we
>>installed
>>>>on
>>>>> them.
>>>>>
>>>>> Of course, that wouldn't prevent viruses 100%, but it would return
things
>>>>back to
>>>>> the situation that existed before the Internet.
>>>>>
>>>>> So when viewing a web site, the server would have to do all the work of
>>any
>>>>fancy
>>>>> programmed behavior of the site. The computer would act like it was just
a
>>>>TV set
>>>>> for viewing the site.
>>>>>
>>>>> I think that this suggestion is a little too extreme. After all,
millions
>>of
>>>>> people might be viewing a site on a tiny little server. So the computers
>>of
>>>>> people viewing web sites have to be expected to do some of the work.
>>>>>
>>>>> But given that fixes for Meltdown and Spectre will apparently make
>>computers
>>>>> slower, this inspired me to think of a way that this idea could be
>>modified
>>>>to
>>>>> be usable.
>>>>>
>>>>> Maybe every computer that views the Internet, to be secure, needs to be
>>two
>>>>> computers.
>>>>>
>>>>> One conventional computer that's fast, and has, as a result, imperfect
>>>>security,
>>>>> that one uses to run one's own programs.
>>>>>
>>>>> And a second very secure and somewhat slow computer. When viewing web
>>sites,
>>>>or
>>>>> opening word processor documents with macros, and so on, in order to
>>>>properly
>>>>> sandbox this foreign executable content, it gets run on the slow
computer.
>>>>>
>>>>> The slow computer's supervisory program runs in memory that looks like
ROM
>>>>to
>>>>> it, but which is writeable by the fast computer - and only the fast
>>computer
>>>>can
>>>>> access the hard drive. The slow computer would be slow because it
wouldn't
>>>>do
>>>>> dangerous things like speculation; if necessary, it might not even be
>>>>pipelined.
>>>>>
>>>>> Outputs from the slow computer would be processed by the fast computer
to
>>>>> display them to the user; so the fast computer would still have to have
>>bug
>>>>free
>>>>> programs without vulnerabilities to display web sites, display video and
>>>>images,
>>>>> and so on. So it would not be a panacea for security, it would simply
deal
>>>>with
>>>>> the most uncontrollable class of vulnerabilities. The fast computer
would
>>>>still
>>>>> need security measures to prevent things like buffer overflows.
>>>>
>>>>Doesn't a personal router provide the slow computer's functionality?
>>>>
>>>
>>> No, it's a specialized device for packet forwarding.
>>>
>>> ARM has an architecture called BigLittle, where a multiprocessor
>>> die consists of several high-end (e.g. out of order, high power, high
>>frequency)
>>> cores (e.g. A57 or A75) and one or two smaller, low-power, in-order
>>> cores).   The operating software can direct tasks to the appropriate
>>> type of core and can power off the high-power cores when not necessary.
>>
>>that doesn't prevent "bad bits" from occupying the machine.
>
>
> Why would you say that?   What possible knowlege of
> the ARM solution do you have other than the very limited
> description above?  Don't you think very smart people have
> considered the security aspects of the design, specifically
> in light of modern threat scenarios?

I understand.  After I sent the post, I realized that I was
using DEC's philosophy.  Your very smart people don't have this
philosophy.  My apologies.

/BAH

On Wednesday, January 31, 2018 at 7:12:56 AM UTC-7, Scott Lurndal wrote:

> Why would you say that?   What possible knowlege of
> the ARM solution do you have other than the very limited
> description above?

The "very limited description above" was a description of something ARM did in 
order to solve the thermal and power limitations of mobile processors, by 
having the "little" processor do the usual tasks of the machine most of the 
time, and the "big" one taking over and being turned on when more computing 
power is needed.

So I don't think you can criticize her in a fair manner for making unwarranted 
assumptions about what ARM is doing for security based on a limited description 
of what they're doing for security... when, in fact, that is not a description 
of anything to do with security.

Since it isn't a security measure, it certainly doesn't stop "bad bits" from 
getting into the machine, whatever that may mean.

John Savard

On Wednesday, January 31, 2018 at 6:32:06 AM UTC-7, jmfbahciv wrote:

> that doesn't prevent "bad bits" from occupying the machine.  I would
> think that a goal should be to prevent this; so the slow machine or
> slow core would be in the box which passes bits to the real machine.

Ah, so you're saying that the router is the best place for a security measure.

It certainly does make sense to stop threats at a level that is as high 
upstream as possible.

However, what I'm talking about is bits that... we don't know whether or not 
they're bad.

A lot of web pages have JavaScript. That lets the web page include a little 
program that runs on your computer. Normally, this is for legitimate purposes, 
like letting web forms be a little fancier without overloading the server.

But these programs, because they're programs running on your computer, _could_ 
be doing sneaky stuff there.

One way to deal with this is the virus scanner approach. Check against patters 
of known tricky JavaScript. You can do _that_ in a router, with deep packet 
inspection at least. But new exploits, or even re-arranged code for old ones, 
could evade detection.

So what I'm proposing is some way to approach a more total fix to the problem.

Don't let web sites run programs on your computer at all.

Have those programs run in a second computer, or in a really locked-down 
sandbox virtualization mode, at least. One which basically gets scrubbed and 
re-initialized for every web page you look at (not slow, because it's a tiny 
second computer).

If you can't find all the bad bits, ensure that they can do no harm.

John Savard

On Wednesday, January 31, 2018 at 8:14:09 AM UTC-7, Lynn Wheeler wrote:

> late 90s, EU had FINREAD standard which assumed insecure, compromised
> and/or "public" PCs that couldn't be trusted and provided for end-to-end
> trust.

This sounds like what it would have to be built around is:

- a secret key in the card plugged into your computer, so that "man-in-the-
middle" attacks couldn't be performed; and

- a keypad on that card, so you enter your PIN there, not on your computer that 
could be keylogged.

For the first point: instead of using the secret key in the card routinely, a 
second-level key that you go to the bank, stick your card in a terminal there, 
and refresh on the card might be what is directly used to get around man-in-the-
middle.

It certainly is possible to design a system of this general nature that is 
secure. This, however, concerns a different issue entirely than the one I was 
talking about.

John Savard

Quadibloc <jsa...@ecn.ab.ca> writes:
>On Wednesday, January 31, 2018 at 7:12:56 AM UTC-7, Scott Lurndal wrote:
>
>> Why would you say that?   What possible knowlege of
>> the ARM solution do you have other than the very limited
>> description above?
>

>Since it isn't a security measure, it certainly doesn't stop "bad bits" from 
>getting into the machine, whatever that may mean.

Well, I must admit I must be careful what I say
about products still in the pipeline, but suffice it to
say that all the processor vendors are _very_ interested
in security.

On 01/02/2018 18:15, Scott Lurndal wrote:
> Quadibloc <jsa...@ecn.ab.ca> writes:
>> On Wednesday, January 31, 2018 at 7:12:56 AM UTC-7, Scott Lurndal wrote:
>>
>>> Why would you say that?   What possible knowlege of
>>> the ARM solution do you have other than the very limited
>>> description above?
>>
> 
>> Since it isn't a security measure, it certainly doesn't stop "bad bits" from
>> getting into the machine, whatever that may mean.
> 
> Well, I must admit I must be careful what I say
> about products still in the pipeline, but suffice it to
> say that all the processor vendors are _very_ interested
> in security.
> 
Recently two chip level security breaches have been revealed, one of 
which works on ARM chips.

On Thursday, February 1, 2018 at 12:37:35 PM UTC-7, Andrew Swallow wrote:

> Recently two chip level security breaches have been revealed, one of 
> which works on ARM chips.

You wouldn't happen to be talking about Meltdown and Spectre by any chance, 
would you?

But _both_ Meltdown and Spectre work on ARM chips; Spectre, but not Meltdown, 
works on AMD chips as well.

John Savard

On 2/1/2018 1:49 PM, Quadibloc wrote:
> On Thursday, February 1, 2018 at 12:37:35 PM UTC-7, Andrew Swallow wrote:
> 
>> Recently two chip level security breaches have been revealed, one of
>> which works on ARM chips.
> 
> You wouldn't happen to be talking about Meltdown and Spectre by any chance,
> would you?
> 
> But _both_ Meltdown and Spectre work on ARM chips; Spectre, but not Meltdown,
> works on AMD chips as well.
> 

Meltdown and Spectre do *not* work on the less powerful ARM chips on the 
Raspberry Pi boards.


-- 
numerist at aquaporin4 dot com

Andrew Swallow <am.sw...@btinternet.com> writes:
>On 01/02/2018 18:15, Scott Lurndal wrote:
>> Quadibloc <jsa...@ecn.ab.ca> writes:
>>> On Wednesday, January 31, 2018 at 7:12:56 AM UTC-7, Scott Lurndal wrote:
>>>
>>>> Why would you say that?   What possible knowlege of
>>>> the ARM solution do you have other than the very limited
>>>> description above?
>>>
>> 
>>> Since it isn't a security measure, it certainly doesn't stop "bad bits" from
>>> getting into the machine, whatever that may mean.
>> 
>> Well, I must admit I must be careful what I say
>> about products still in the pipeline, but suffice it to
>> say that all the processor vendors are _very_ interested
>> in security.
>> 
>Recently two chip level security breaches have been revealed, one of 
>which works on ARM chips.

It works on pretty much any modern out-of-order processor.   It's a new
thing.   That doesn't at all discount that the processor vendors are
_very_ interested in security, and do all they can to avoid these
issues and are certainly working fixes into next generation product.

Charles Richmond <nume...@aquaporin4.com> writes:
>On 2/1/2018 1:49 PM, Quadibloc wrote:
>> On Thursday, February 1, 2018 at 12:37:35 PM UTC-7, Andrew Swallow wrote:
>> 
>>> Recently two chip level security breaches have been revealed, one of
>>> which works on ARM chips.
>> 
>> You wouldn't happen to be talking about Meltdown and Spectre by any chance,
>> would you?
>> 
>> But _both_ Meltdown and Spectre work on ARM chips; Spectre, but not Meltdown,
>> works on AMD chips as well.
>> 
>
>Meltdown and Spectre do *not* work on the less powerful ARM chips on the 
>Raspberry Pi boards.

Those attacks only work on out-of-order cores that speculate memory accesses
that down incorrect paths.   There are only two ARM(tm) cores of the several
dozen ARM variants that suffer from one of the two issues.

On Tue, 2018-01-30, Quadibloc wrote:
> On Tuesday, January 30, 2018 at 8:35:25 AM UTC-7, Jorgen Grahn wrote:
>> On Tue, 2018-01-30, Quadibloc wrote:
>
>> > On some tech news site, I came across a comment to the effect
>> > that things like Meltdown and Spectre wouldn't be such a big
>> > deal...
>
>> > if the only executable content our computers ran were programs we
>> > installed on them.
>
>> That ignores the multiuser aspect of computers.
>
> Well, if a computer is multi-user, you only want the admins to be able to 
> install software.

Hard and undesirable, IMHO: what good is a computer if you cannot
program it?  And how about interpreters: should I be allowed to write
my own shell or Perl scripts?

Unix (which is what I prefer) settles for this: that a user cannot
/accidentally/ execute code which she either (a) has written herself
or (b) has been installed by an admin.

And nowadays (c) Javascript and stuff in web pages she visits :-/

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

Quadibloc wrote:
> On Wednesday, January 31, 2018 at 6:32:06 AM UTC-7, jmfbahciv wrote:
>
>> that doesn't prevent "bad bits" from occupying the machine.  I would
>> think that a goal should be to prevent this; so the slow machine or
>> slow core would be in the box which passes bits to the real machine.
>
> Ah, so you're saying that the router is the best place for a security
measure.

To keep the kids from tracking in filth, you have them take their boots
off before they get into the house.  Same principle is true with
computer bits and bytes.
>
> It certainly does make sense to stop threats at a level that is as high
> upstream as possible.

This isn't necessarily upstream; it could be a hub.
>
> However, what I'm talking about is bits that... we don't know whether or not
> they're bad.

That's defined by usage and the intent of the user.  My bad bits are your
good bits and visa versa.  Scott's usage of his bits is going to be
"scarier" than a mundane user like me because his usage is stuff
which has "never been before".  I used to do the same kind of work; everyone
in my group had POKE privs which allowed patching the running monitor if
we wished to do so.

>
> A lot of web pages have JavaScript. That lets the web page include a little
> program that runs on your computer. Normally, this is for legitimate
purposes,
> like letting web forms be a little fancier without overloading the server.

This is an abmonination.  If code has to be run in order to display
a web page which a user has requested, that web page should be built
on the "dirty" computer and then pushed to the user's system.

The problem we're having is that noone, especially the operating
systems, keeps the user actions separated from system actions.  There
should have been a strict wall between the two functionalities.
TOPS-10 and TOPS-20 got this right via the UUO interface.  Unix and
MSoft's developers, over the years, got lazy while writing new code
and didn't keep a strict wall between the two.  Hardware manufacturers
had more control over these kinds of edicts; that's no longer the case.
With the introduction of networking, things got really muddled about
who is "boss" and the network wars are still being fought.  There
isn't any agreement about who is boss because everyone is a boss,
especially the poor users who are forced to be system and network
managers with no training, documentation or access to reasonable
advice.

I'll ranting now.


>
> But these programs, because they're programs running on your computer,
_could_
> be doing sneaky stuff there.
>
> One way to deal with this is the virus scanner approach. Check against
patters
> of known tricky JavaScript. You can do _that_ in a router, with deep packet
> inspection at least. But new exploits, or even re-arranged code for old
ones,
> could evade detection.

Correct.  Detection of adverse bit arrangements isn't the key even
though it's a pitiful tool.  The decsions of which are "good"
bit arrangements really need to be done based on the type of usage of
the bit requester.  Now, how that is determined and implemented is
about 4-5 months of bullshit sessions.

>
> So what I'm proposing is some way to approach a more total fix to the
problem.

<grin>  So am I.  The above is thinking so far outside the box that
a whole new computing service provider rigor is going to be developed.
>
> Don't let web sites run programs on your computer at all.

Yup.  But that also has it's problems.  Consider the event where the
data on your computer is the input to the web site's service (which
the user requested by opening the web page).  An example is income
tax.  You don't want your data to be uploaded to anything but you
do want the number (tax owed) to be used to transfer money from
your bank to the government's.
>
> Have those programs run in a second computer, or in a really locked-down
> sandbox virtualization mode, at least. One which basically gets scrubbed and
> re-initialized for every web page you look at (not slow, because it's a tiny
> second computer).

Yes.  I would prefer that the second computer not be in the same physical
box; it allows the functionality and bits to be separated by network
protocol.

>
> If you can't find all the bad bits, ensure that they can do no harm.

That is a result, not a goal because you can't define bad bits until
after they do harm.  Those same bits could do good things.

/BAH

Quadibloc <jsa...@ecn.ab.ca> writes:
> Have those programs run in a second computer, or in a really locked-down 
> sandbox virtualization mode, at least. One which basically gets scrubbed and 
> re-initialized for every web page you look at (not slow, because it's a tiny 
> second computer).

re:
http://www.garlic.com/~lynn/2018.html#110 Making Computers Secure

reference to consumer "dial-up" banking moving to internet and
commercial dail-up saying they would never move to the internet
because of large number of vulernabilities and exploits
http://www.garlic.com/~lynn/2018.html#94 Predicting the future in five years as seen from 1983

after the turn of the century, commercial dial-up banking started 
moving to the internet (regardless) and the perdicted exploits started
appearing. Commercial transactions don't have the some rules as
consumer transactions (and not required by financial institutions
to cover the costs, kind of rule that consumer isn't at fault) ... so
businesses would suethe banks over the losses. Eventually the federal
reserve came out with a guidelines that businesses should have a
dedicated PC that is only used for online banking and *NEVER* used for
any other purpose (many of the exploits involved visiting websites
that would install malware and compromise the PC)

past posts mentioning commercial online bankiing
http://www.garlic.com/~lynn/2010f.html#6</a> Online Banking & Password Theft
http://www.garlic.com/~lynn/2010m.html#38</a> U.K. bank hit by massive fraud from ZeuS-based botnet
http://www.garlic.com/~lynn/2010m.html#82</a> Nearly $1,000,000 stolen electronically from the University of Virginia
http://www.garlic.com/~lynn/2010m.html#87</a> Nearly $1,000,000 stolen electronically from the University of Virginia
http://www.garlic.com/~lynn/2010n.html#9</a> 'Here you have' email worm spreads quickly
http://www.garlic.com/~lynn/2010n.html#47</a> ZeuS attacks mobiles in bank SMS bypass scam
http://www.garlic.com/~lynn/2011g.html#22</a> An online bank scam worthy of a spy novel
http://www.garlic.com/~lynn/2011g.html#48</a> Is the magic and romance killed by Windows (and Linux)?
http://www.garlic.com/~lynn/2011h.html#4</a> 1st round in Internet Account Fraud World Cup: Customer 0, Bank 1, Attacker 300,000
http://www.garlic.com/~lynn/2011h.html#65</a> US Business Banking Cybercrime Wave: Is 'Commercially Reasonable' Reasonable?
http://www.garlic.com/~lynn/2011k.html#40</a> Banks blocking more fraudulent money transfers from hijacked business accounts
http://www.garlic.com/~lynn/2011m.html#40</a> ISBNs
http://www.garlic.com/~lynn/2012b.html#61</a> Banking malware a growing threat, as new variant of Zeus is detected
http://www.garlic.com/~lynn/2012b.html#71</a> Password shortcomings
http://www.garlic.com/~lynn/2012i.html#18</a> Zeus/SpyEye 'Automatic Transfer' Module Masks Online Banking Theft
http://www.garlic.com/~lynn/2012j.html#59</a> Bank Sues Customer Over ACH/Wire Fraud
http://www.garlic.com/~lynn/2012j.html#73</a> Is it time to consider a stand-alone PC for online banking?
http://www.garlic.com/~lynn/2012j.html#94</a> Gordon Crovitz: Who Really Invented the Internet?
http://www.garlic.com/~lynn/2012l.html#32</a> Use another browser - Kaspersky follows suit
http://www.garlic.com/~lynn/2012p.html#49</a> Regulator Tells Banks to Share Cyber Attack Information
http://www.garlic.com/~lynn/2014j.html#22</a> The SDS 92, its place in history?
http://www.garlic.com/~lynn/2014j.html#98</a> Cybersecurity
http://www.garlic.com/~lynn/2015d.html#61</a> Western Union envisioned internet functionality
http://www.garlic.com/~lynn/2015e.html#42</a>The real story of how the Internet became so vulnerable
http://www.garlic.com/~lynn/2016h.html#99</a> PC Compromise and Internet Transactions
http://www.garlic.com/~lynn/2017d.html#92</a>Old hardware
http://www.garlic.com/~lynn/2017e.html#31</a>[CM] What was your first home computer?

On 2 Feb 2018 14:19:17 GMT, jmfbahciv <See....@aol.com> wrote:

>Quadibloc wrote:
>> On Wednesday, January 31, 2018 at 6:32:06 AM UTC-7, jmfbahciv wrote:
>>
>>> that doesn't prevent "bad bits" from occupying the machine.  I would
>>> think that a goal should be to prevent this; so the slow machine or
>>> slow core would be in the box which passes bits to the real machine.
>>
>> Ah, so you're saying that the router is the best place for a security
>measure.
>
>To keep the kids from tracking in filth, you have them take their boots
>off before they get into the house.  Same principle is true with
>computer bits and bytes.
>>
>> It certainly does make sense to stop threats at a level that is as high
>> upstream as possible.
>
>This isn't necessarily upstream; it could be a hub.
>>
>> However, what I'm talking about is bits that... we don't know whether or not
>> they're bad.
>
>That's defined by usage and the intent of the user.  My bad bits are your
>good bits and visa versa.  Scott's usage of his bits is going to be
>"scarier" than a mundane user like me because his usage is stuff
>which has "never been before".  I used to do the same kind of work; everyone
>in my group had POKE privs which allowed patching the running monitor if
>we wished to do so.
>
>>
>> A lot of web pages have JavaScript. That lets the web page include a little
>> program that runs on your computer. Normally, this is for legitimate
>purposes,
>> like letting web forms be a little fancier without overloading the server.
>
>This is an abmonination.  If code has to be run in order to display
>a web page which a user has requested, that web page should be built
>on the "dirty" computer and then pushed to the user's system.
>
>The problem we're having is that noone, especially the operating
>systems, keeps the user actions separated from system actions.  There
>should have been a strict wall between the two functionalities.
>TOPS-10 and TOPS-20 got this right via the UUO interface.  Unix and
>MSoft's developers, over the years, got lazy while writing new code
>and didn't keep a strict wall between the two. 

I think you will find that the opposite has occurred.  Early PCs
didn't even have the means to enforce such a wall.  Now modern
operating systems run just about everything in userspace at some level
of virtualization.

> Hardware manufacturers
>had more control over these kinds of edicts; that's no longer the case.
>With the introduction of networking, things got really muddled about
>who is "boss" and the network wars are still being fought.  There
>isn't any agreement about who is boss because everyone is a boss,
>especially the poor users who are forced to be system and network
>managers with no training, documentation or access to reasonable
>advice.
>
>I'll ranting now.
>
>
>>
>> But these programs, because they're programs running on your computer,
>_could_
>> be doing sneaky stuff there.
>>
>> One way to deal with this is the virus scanner approach. Check against
>patters
>> of known tricky JavaScript. You can do _that_ in a router, with deep packet
>> inspection at least. But new exploits, or even re-arranged code for old
>ones,
>> could evade detection.
>
>Correct.  Detection of adverse bit arrangements isn't the key even
>though it's a pitiful tool.  The decsions of which are "good"
>bit arrangements really need to be done based on the type of usage of
>the bit requester.  Now, how that is determined and implemented is
>about 4-5 months of bullshit sessions.
>
>>
>> So what I'm proposing is some way to approach a more total fix to the
>problem.
>
><grin>  So am I.  The above is thinking so far outside the box that
>a whole new computing service provider rigor is going to be developed.
>>
>> Don't let web sites run programs on your computer at all.
>
>Yup.  But that also has it's problems.  Consider the event where the
>data on your computer is the input to the web site's service (which
>the user requested by opening the web page).  An example is income
>tax.  You don't want your data to be uploaded to anything but you
>do want the number (tax owed) to be used to transfer money from
>your bank to the government's.
>>
>> Have those programs run in a second computer, or in a really locked-down
>> sandbox virtualization mode, at least. One which basically gets scrubbed and
>> re-initialized for every web page you look at (not slow, because it's a tiny
>> second computer).
>
>Yes.  I would prefer that the second computer not be in the same physical
>box; it allows the functionality and bits to be separated by network
>protocol.
>
>>
>> If you can't find all the bad bits, ensure that they can do no harm.
>
>That is a result, not a goal because you can't define bad bits until
>after they do harm.  Those same bits could do good things.
>
>/BAH

On 2 Feb 2018 06:46:05 GMT, Jorgen Grahn <grahn...@snipabacken.se>
wrote:

>On Tue, 2018-01-30, Quadibloc wrote:
>> On Tuesday, January 30, 2018 at 8:35:25 AM UTC-7, Jorgen Grahn wrote:
>>> On Tue, 2018-01-30, Quadibloc wrote:
>>
>>> > On some tech news site, I came across a comment to the effect
>>> > that things like Meltdown and Spectre wouldn't be such a big
>>> > deal...
>>
>>> > if the only executable content our computers ran were programs we
>>> > installed on them.
>>
>>> That ignores the multiuser aspect of computers.
>>
>> Well, if a computer is multi-user, you only want the admins to be able to 
>> install software.

"program" and "install software" are two different things.  I can
write and run all the code I want on the company machine.  Until they
gave me admin access a while back I was unable to install anything.

"Install" means more these days than "copy an executable file".
>
>Hard and undesirable, IMHO: what good is a computer if you cannot
>program it?  And how about interpreters: should I be allowed to write
>my own shell or Perl scripts?
>
>Unix (which is what I prefer) settles for this: that a user cannot
>/accidentally/ execute code which she either (a) has written herself
>or (b) has been installed by an admin.
>
>And nowadays (c) Javascript and stuff in web pages she visits :-/
>
>/Jorgen

On 2018-02-03, J  Clarke <jclarke...@gmail.com> wrote:
> On 2 Feb 2018 14:19:17 GMT, jmfbahciv <See....@aol.com> wrote:
>
>>Quadibloc wrote:
>>> On Wednesday, January 31, 2018 at 6:32:06 AM UTC-7, jmfbahciv wrote:
>>>
>>>> that doesn't prevent "bad bits" from occupying the machine.  I would
>>>> think that a goal should be to prevent this; so the slow machine or
>>>> slow core would be in the box which passes bits to the real machine.
>>>
>>> Ah, so you're saying that the router is the best place for a security
>>measure.
>>
>>To keep the kids from tracking in filth, you have them take their boots
>>off before they get into the house.  Same principle is true with
>>computer bits and bytes.
>>>
>>> It certainly does make sense to stop threats at a level that is as high
>>> upstream as possible.
>>
>>This isn't necessarily upstream; it could be a hub.
>>>
>>> However, what I'm talking about is bits that... we don't know whether or not
>>> they're bad.
>>
>>That's defined by usage and the intent of the user.  My bad bits are your
>>good bits and visa versa.  Scott's usage of his bits is going to be
>>"scarier" than a mundane user like me because his usage is stuff
>>which has "never been before".  I used to do the same kind of work; everyone
>>in my group had POKE privs which allowed patching the running monitor if
>>we wished to do so.
>>
>>>
>>> A lot of web pages have JavaScript. That lets the web page include a little
>>> program that runs on your computer. Normally, this is for legitimate
>>purposes,
>>> like letting web forms be a little fancier without overloading the server.
>>
>>This is an abmonination.  If code has to be run in order to display
>>a web page which a user has requested, that web page should be built
>>on the "dirty" computer and then pushed to the user's system.
>>
>>The problem we're having is that noone, especially the operating
>>systems, keeps the user actions separated from system actions.  There
>>should have been a strict wall between the two functionalities.
>>TOPS-10 and TOPS-20 got this right via the UUO interface.  Unix and
>>MSoft's developers, over the years, got lazy while writing new code
>>and didn't keep a strict wall between the two. 
>
> I think you will find that the opposite has occurred.  Early PCs
> didn't even have the means to enforce such a wall.  Now modern
> operating systems run just about everything in userspace at some level
> of virtualization.

Correct. 286 had protected mode, but almost no OS used it...

-- 
press any key to continue or any other to quit...

On 2018-02-03, J  Clarke <jclarke...@gmail.com> wrote:
> On 2 Feb 2018 06:46:05 GMT, Jorgen Grahn <grahn...@snipabacken.se>
> wrote:
>
>>On Tue, 2018-01-30, Quadibloc wrote:
>>> On Tuesday, January 30, 2018 at 8:35:25 AM UTC-7, Jorgen Grahn wrote:
>>>> On Tue, 2018-01-30, Quadibloc wrote:
>>>
>>>> > On some tech news site, I came across a comment to the effect
>>>> > that things like Meltdown and Spectre wouldn't be such a big
>>>> > deal...
>>>
>>>> > if the only executable content our computers ran were programs we
>>>> > installed on them.
>>>
>>>> That ignores the multiuser aspect of computers.
>>>
>>> Well, if a computer is multi-user, you only want the admins to be able to 
>>> install software.
>
> "program" and "install software" are two different things.  I can
> write and run all the code I want on the company machine.  Until they
> gave me admin access a while back I was unable to install anything.
>
> "Install" means more these days than "copy an executable file".

Installing system wide and user wide should be differentiated now.
Software that requires rebooting an OS shouldn't be allowed at all.


-- 
press any key to continue or any other to quit...

On Friday, February 2, 2018 at 8:36:29 PM UTC-7, J. Clarke wrote:
> Now modern
> operating systems run just about everything in userspace at some level
> of virtualization.

I take it that by "modern operating systems", you do not include Windows 7 or 
Linux, but instead Android and possibly Windows 10.

John Savard

On 2018-02-03, Quadibloc <jsa...@ecn.ab.ca> wrote:
> On Friday, February 2, 2018 at 8:36:29 PM UTC-7, J. Clarke wrote:
>> Now modern
>> operating systems run just about everything in userspace at some level
>> of virtualization.
>
> I take it that by "modern operating systems", you do not include Windows 7 or 
> Linux, but instead Android and possibly Windows 10.

Modern starts in 90es... Android is custom distribution of Linux and
Windows 10, erm it's Windows...

>
> John Savard


-- 
press any key to continue or any other to quit...

On Sat, 03 Feb 2018 03:41:11 +0000, Melzzzzz wrote:

>>>The problem we're having is that noone, especially the operating
>>>systems, keeps the user actions separated from system actions.  There
>>>should have been a strict wall between the two functionalities. TOPS-10
>>>and TOPS-20 got this right via the UUO interface.  Unix and MSoft's
>>>developers, over the years, got lazy while writing new code and didn't
>>>keep a strict wall between the two.
>>
>> I think you will find that the opposite has occurred.  Early PCs didn't
>> even have the means to enforce such a wall.  Now modern operating
>> systems run just about everything in userspace at some level of
>> virtualization.
> 
> Correct. 286 had protected mode, but almost no OS used it...

The only systems I can think of were some nice UNIX-like systems, 
including IBM's PC-IX. It didn't help that protected mode was 
incompatible address-wise with real mode.

Barb seems to be implying that the UUO interface was something new (but 
then we know her only experience is DEC!). I can think of plenty of 
examples on other systems and hardware.



-- 
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

On 3 Feb 2018 10:52:00 GMT, Bob Eager <news...@eager.cx> wrote:

>On Sat, 03 Feb 2018 03:41:11 +0000, Melzzzzz wrote:
>
>>>>The problem we're having is that noone, especially the operating
>>>>systems, keeps the user actions separated from system actions.  There
>>>>should have been a strict wall between the two functionalities. TOPS-10
>>>>and TOPS-20 got this right via the UUO interface.  Unix and MSoft's
>>>>developers, over the years, got lazy while writing new code and didn't
>>>>keep a strict wall between the two.
>>>
>>> I think you will find that the opposite has occurred.  Early PCs didn't
>>> even have the means to enforce such a wall.  Now modern operating
>>> systems run just about everything in userspace at some level of
>>> virtualization.
>> 
>> Correct. 286 had protected mode, but almost no OS used it...
>
>The only systems I can think of were some nice UNIX-like systems, 
>including IBM's PC-IX. It didn't help that protected mode was 
>incompatible address-wise with real mode.

AT&T System V is another example (yes, there was a real Unix for the
286).  Also Novell Advanced Netware 286, which was not Unix like at
all.

The big obstacle was a bug that corrupted one or more registers when
switching from protected back to real IIRC.  One developer dealt with
this by saving the register values into the keyboard buffer and
reading them back after the switch.

>Barb seems to be implying that the UUO interface was something new (but 
>then we know her only experience is DEC!). I can think of plenty of 
>examples on other systems and hardware.

On Fri, 2 Feb 2018 19:46:21 -0800 (PST), Quadibloc <jsa...@ecn.ab.ca>
wrote:

>On Friday, February 2, 2018 at 8:36:29 PM UTC-7, J. Clarke wrote:
>> Now modern
>> operating systems run just about everything in userspace at some level
>> of virtualization.
>
>I take it that by "modern operating systems", you do not include Windows 7 or 
>Linux, but instead Android and possibly Windows 10.

If you check the options in Windows 7 you will find that
virtualization is the default for just about everything.

Note also that anything compiled with Visual Studio will by default
also compile to hardware-independent bytecode that has to run on an
emulation layer.

On Sat, 3 Feb 2018 03:44:51 +0000 (UTC), Melzzzzz <Melz...@zzzzz.com>
wrote:

>On 2018-02-03, J  Clarke <jclarke...@gmail.com> wrote:
>> On 2 Feb 2018 06:46:05 GMT, Jorgen Grahn <grahn...@snipabacken.se>
>> wrote:
>>
>>>On Tue, 2018-01-30, Quadibloc wrote:
>>>> On Tuesday, January 30, 2018 at 8:35:25 AM UTC-7, Jorgen Grahn wrote:
>>>>> On Tue, 2018-01-30, Quadibloc wrote:
>>>>
>>>>> > On some tech news site, I came across a comment to the effect
>>>>> > that things like Meltdown and Spectre wouldn't be such a big
>>>>> > deal...
>>>>
>>>>> > if the only executable content our computers ran were programs we
>>>>> > installed on them.
>>>>
>>>>> That ignores the multiuser aspect of computers.
>>>>
>>>> Well, if a computer is multi-user, you only want the admins to be able to 
>>>> install software.
>>
>> "program" and "install software" are two different things.  I can
>> write and run all the code I want on the company machine.  Until they
>> gave me admin access a while back I was unable to install anything.
>>
>> "Install" means more these days than "copy an executable file".
>
>Installing system wide and user wide should be differentiated now.
>Software that requires rebooting an OS shouldn't be allowed at all.

Whether it's system wide or user wide, if it uses the registry my
employer has it blocked for anybody other than developers and IT
people tasked with installing software.

On Saturday, February 3, 2018 at 3:52:02 AM UTC-7, Bob Eager wrote:
> On Sat, 03 Feb 2018 03:41:11 +0000, Melzzzzz wrote:

> > Correct. 286 had protected mode, but almost no OS used it...

> The only systems I can think of were some nice UNIX-like systems, 
> including IBM's PC-IX. It didn't help that protected mode was 
> incompatible address-wise with real mode.

Basically, an operating system that used 286 protected mode would have to 
*reboot* before it could run real mode software. So an operating system 
using 286 protected mode was _incompatible_ with DOS software for the PC, 
which is why Windows didn't get written that way.

But AMD - and then Intel - made the same mistake with 64 bit mode, which 
is why you can't run (directly on the bare iron, without using 
virtualization) 16-bit Windows programs on the 64-bit versions of 
Windows. I just can't understand why, having the historical example of 
the 80286 before them, they would fail to recognize the supreme 
importance of always maintaining upwards compatibility.

John Savard

Bob Eager wrote:
> On Sat, 03 Feb 2018 03:41:11 +0000, Melzzzzz wrote:
>
>>>>The problem we're having is that noone, especially the operating
>>>>systems, keeps the user actions separated from system actions.  There
>>>>should have been a strict wall between the two functionalities. TOPS-10
>>>>and TOPS-20 got this right via the UUO interface.  Unix and MSoft's
>>>>developers, over the years, got lazy while writing new code and didn't
>>>>keep a strict wall between the two.
>>>
>>> I think you will find that the opposite has occurred.  Early PCs didn't
>>> even have the means to enforce such a wall.  Now modern operating
>>> systems run just about everything in userspace at some level of
>>> virtualization.
>>
>> Correct. 286 had protected mode, but almost no OS used it...
>
> The only systems I can think of were some nice UNIX-like systems,
> including IBM's PC-IX. It didn't help that protected mode was
> incompatible address-wise with real mode.
>
> Barb seems to be implying that the UUO interface was something new (but
> then we know her only experience is DEC!). I can think of plenty of
> examples on other systems and hardware.

I didn't intend to imply that it was new;  just the opposite.  When
hardware manufacturing and software development for that hardware
became corporately separated, the software developers used
"short cuts" to get into the guts of the machine even when they
were doing app-level development.  That's why Msoft's so-called
OSes were so insecure and buggy.  Not even Cutler could make them
honor the wall that should have been between the exec code and
a mere user.

/BAH

On Sat, 3 Feb 2018 06:06:45 -0800 (PST), Quadibloc <jsa...@ecn.ab.ca>
wrote:

>On Saturday, February 3, 2018 at 3:52:02 AM UTC-7, Bob Eager wrote:
>> On Sat, 03 Feb 2018 03:41:11 +0000, Melzzzzz wrote:
>
>> > Correct. 286 had protected mode, but almost no OS used it...
>
>> The only systems I can think of were some nice UNIX-like systems, 
>> including IBM's PC-IX. It didn't help that protected mode was 
>> incompatible address-wise with real mode.
>
>Basically, an operating system that used 286 protected mode would have to 
>*reboot* before it could run real mode software. So an operating system 
>using 286 protected mode was _incompatible_ with DOS software for the PC, 
>which is why Windows didn't get written that way.
>
>But AMD - and then Intel - made the same mistake with 64 bit mode, which 
>is why you can't run (directly on the bare iron, without using 
>virtualization) 16-bit Windows programs on the 64-bit versions of 
>Windows. I just can't understand why, having the historical example of 
>the 80286 before them, they would fail to recognize the supreme 
>importance of always maintaining upwards compatibility.

You seem to misunderstand virtualization.  Virtualization does run on
the bare iron.  Virtualization is not emulation.

However trying to run code from the 16-bit era on Windows _without_
virtualization is just plain not going to work--that code needs to be
in a specific area of memory and have direct access to devices that
don't even _exist_ anymore.
>
>John Savard

In that case, it's a wonder that they work on the 32-bit version of Windows 7.

On Saturday, February 3, 2018 at 6:51:33 AM UTC-7, J. Clarke wrote:

> If you check the options in Windows 7 you will find that
> virtualization is the default for just about everything.

Huh? Are you talking about VDI? That's for computers connected to a server.

> Note also that anything compiled with Visual Studio will by default
> also compile to hardware-independent bytecode that has to run on an
> emulation layer.

Yes, that's true.

John Savard

On Sat, 3 Feb 2018 22:56:39 -0800 (PST), Quadibloc <jsa...@ecn.ab.ca>
wrote:

>On Saturday, February 3, 2018 at 6:51:33 AM UTC-7, J. Clarke wrote:
>
>> If you check the options in Windows 7 you will find that
>> virtualization is the default for just about everything.
>
>Huh? Are you talking about VDI? That's for computers connected to a server.

Right click on just about anything and look at advanced properties and
you'll find a default set to "run in separate memory space".
>
>> Note also that anything compiled with Visual Studio will by default
>> also compile to hardware-independent bytecode that has to run on an
>> emulation layer.
>
>Yes, that's true.
>
>John Savard

On Sunday, February 4, 2018 at 5:52:00 AM UTC-7, J. Clarke wrote:

> Right click on just about anything and look at advanced properties and
> you'll find a default set to "run in separate memory space".

Ah, yes. That's under the initial Shortcut tab. On my computer, that 
is grayed out, so I can't even clear the default.

Of course, a separate address space, while that's a measure used to 
protect against Meltdown, is not itself virtualization. That's just 
use of the virtual memory feature.

John Savard

On 2018-02-04, Quadibloc <jsa...@ecn.ab.ca> wrote:
> On Sunday, February 4, 2018 at 5:52:00 AM UTC-7, J. Clarke wrote:
>
>> Right click on just about anything and look at advanced properties and
>> you'll find a default set to "run in separate memory space".
>
> Ah, yes. That's under the initial Shortcut tab. On my computer, that 
> is grayed out, so I can't even clear the default.
>
> Of course, a separate address space, while that's a measure used to 
> protect against Meltdown, is not itself virtualization. That's just 
> use of the virtual memory feature.
>
> John Savard

<vision> 

The man arrives in his main office, and asks,
"Have we a computer secure against this problem?"
"Yes, Sir,"
producing a Raspberry Pi.
Stout man collapses, as they used to say on Mr. Funnybone.

</vision>


-- 
greymaus.ireland.ie
Just_Another_Grumpy_Old_Man

On Sat, 2018-02-03, J  Clarke wrote:
> On 2 Feb 2018 06:46:05 GMT, Jorgen Grahn <grahn...@snipabacken.se>
> wrote:
>
>>On Tue, 2018-01-30, Quadibloc wrote:
>>> On Tuesday, January 30, 2018 at 8:35:25 AM UTC-7, Jorgen Grahn wrote:
>>>> On Tue, 2018-01-30, Quadibloc wrote:
>>>
>>>> > On some tech news site, I came across a comment to the effect
>>>> > that things like Meltdown and Spectre wouldn't be such a big
>>>> > deal...
>>>
>>>> > if the only executable content our computers ran were programs we
>>>> > installed on them.
>>>
>>>> That ignores the multiuser aspect of computers.
>>>
>>> Well, if a computer is multi-user, you only want the admins to be able to 
>>> install software.
>
> "program" and "install software" are two different things.  I can
> write and run all the code I want on the company machine.  Until they
> gave me admin access a while back I was unable to install anything.

Yes; see the "Unix settles for this" below.
I guess I was still replying to the "


> "Install" means more these days than "copy an executable file".
>>
>>Hard and undesirable, IMHO: what good is a computer if you cannot
>>program it?  And how about interpreters: should I be allowed to write
>>my own shell or Perl scripts?
>>
>>Unix (which is what I prefer) settles for this: that a user cannot
>>/accidentally/ execute code which she either (a) has written herself
>>or (b) has been installed by an admin.
>>
>>And nowadays (c) Javascript and stuff in web pages she visits :-/
>>
>>/Jorgen


-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

On Tue, 2018-02-06, Jorgen Grahn wrote:
> On Sat, 2018-02-03, J  Clarke wrote:
...
>> "program" and "install software" are two different things.  I can
>> write and run all the code I want on the company machine.  Until they
>> gave me admin access a while back I was unable to install anything.
>
> Yes; see the "Unix settles for this" below.
> I guess I was still replying to the "

Posted by mistake, after deciding I didn't have to reply.
Please ignore.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .