Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #30723
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: 64-bit embedded computing is here and now |
| Date | 2021-06-11 16:24 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <sa0rco$ons$1@dont-email.me> (permalink) |
| References | (13 earlier) <s9u2q4$29e$1@dont-email.me> <s9uqcf$8ih$1@dont-email.me> <s9vgj7$67t$1@dont-email.me> <s9vjs7$r7m$1@dont-email.me> <s9voqh$ohc$1@dont-email.me> |
On 6/11/2021 6:35 AM, Dimiter_Popoff wrote:
> On 6/11/2021 15:10, Don Y wrote:
>> On 6/11/2021 4:14 AM, Dimiter_Popoff wrote:
>>> On 6/11/2021 7:55, Don Y wrote:
>>>> ...
>>>> As I tease more of your design out of you, it becomes apparent why
>>>> you "need" a flat address space. You push much of the responsibility
>>>> for managing the environment into the developer's hands. *He* decides
>>>> which regions of memory to share. He talks to the MMU (even if through
>>>> an API). He directly retrieves values from other tasks. Etc.
>>>
>>> It is not true that the developer is in control of all that. Messaging
>>> from one task to another goes through a system call.
>>
>> But the client directly retrieves the values. The OS doesn't provide
>> them (at least, that's what you said previously)
>
> I am not sure what this means. The recipient task has advertised a field
> where messages can be queued, the sending task makes a system call
> designating the message and which task is to receive it; during that
> call execution the message is written into the memory of the recipient.
> Then at some point later the recipient can see that and process the
> message. What more do you need?
>
>>
>>> Anyway, I am not interested in discussing dps here/now.
>>>
>>> The *only* thing I would like you to answer me is why you think
>>> a linear 64 bit address space can add vulnerability to a design.
>>
>> Please tell me where I said it -- in and of itself -- makes a
>> design vulnerable?
>
> This is how the exchange started:
>
>
>>>>> Dimiter_Popoff wrote:
>>>>>
>>>>>
>>>>> The real value in 64 bit integer registers and 64 bit address space is
>>>>> just that, having an orthogonal "endless" space (well I remember some
>>>>> 30 years ago 32 bits seemed sort of "endless" to me...).
>>>>>
>>>>> Not needing to assign overlapping logical addresses to anything
>>>>> can make a big difference to how the OS is done.
>>>>
>>>> That depends on what you expect from the OS. If you are
>>>> comfortable with the possibility of bugs propagating between
>>>> different subsystems, then you can live with a logical address
>>>> space that exactly coincides with a physical address space.
>>>
>>> So how does the linear 64 bt address space get in the way of
>>> any protection you want to implement? Pages are still 4 k and
>>> each has its own protection attributes governed by the OS,
>>> it is like that with 32 bit processors as well (I talk power, I am
>>> not interested in half baked stuff like ARM, risc-v etc., I don't
>>> know if there could be a problem like that with one of these).
>>
>> With a linear address space, you typically have to link EVERYTHING
>> as a single image to place each thing in its own piece of memory
>> (or use segment based addressing).
>
> Now if you have missed the "logical" word in my post I can
> understand why you went into all that. But I was quite explicit
> about it.
It's easier to get some part of a flat address space *wrong*.
And, as you've exposed (even if hiding behind an MMU) everything,
that presents an opportunity for SOMETHING to leak -- that
shouldn't.
Alpha (OS) took this to an extreme. Each object had its own
address space fitted neatly onto some number of (contiguous?)
pages.
When you invoked a method on an object, you trapped to the OS.
The OS marshalled your arguments into an "input page(s)"
and created an empty "ouput page(s)". It then built an address
space consisting of the input and output pages (at logical
addresses that an object recognized, by convention) AND the
page(s) for the object's code. NOTHING ELSE. Then, transfered
control to one of N entry points in the first page of the
object's implementation (another convention).
So, the object's code had free access to its inputs, its
own code and it's outputs. Attempting to reference anything else
would signal a protection violation. There *is* nothing else!
A bug, errant pointer, exploit, etc. would just land on
unmapped memory!
[Note that an object could invoke ANOTHER object -- but, that
object would then be built up in yet another address space
while the current object's address space was idled]
This approach makes it hard for "active" objects to be
made persistent (e.g., a *process* that is "doing something
yet has an object interface) so objects tend to want to be
passive.
I don't go to these extremes. But close!
An instance of a "foo" object is served by (an instance of)
a foo_object_server. That server can serve multiple foo objects
concurrently (and can even use multiple threads to do so).
The object_server accepts the messages for the object and
invokes the corresponding method in the context of that
particular object. Because it exists in an isolated address
space, no other objects/clients can examine the object's
implementation -- the code executed by the object_server
to handle each request/method as well as the "private data"
associated with an object instance. Nor can they interfere
with any of this.
Another instance of a foo_object_server can serve other
foo objects -- on the same node or on some other node.
[i.e., to migrate a foo object to another node, instantiate
a foo_object_server on the target node -- if one doesn't
already exist there -- and then transfer the internal
representation of the desired foo object to that other
server. And, arrange for all "Interfaces" to that
particular object to simultaneously be transferred
(so future connections to the object are unaware of
the migration)]
As my *_object_servers can be persistent, an object can be
active -- can continue doing something even after (or before!)
every request (method invocation) has been serviced. It's
up to the object designer to decide the semantics of
each method.
E.g., should garagedoor.open() start the opening process and
wait until it is complete before returning to the caller?
Or, should it just start the process and return immediately?
Should rosebush.irrigate() block the caller for the hour or two
it takes to irrigate?
> Anyway, I am glad we agree that a 64 bit logical address space
> is no obstacle to security. From there on it can only be something
> to make programming life easier.
It's not an obstacle. But, it's an *opportunity* for a bug to
manifest or information to leak or an exploit to gain a beachhead.
The less stuff that can be exposed (even accidentally), the less
opportunity for these problems to manifest.
Think of all the "account compromises" that have occurred.
All of the "personal/account information" that has leaked.
Why was that information accessible? I'm sure it wasn't
SUPPOSED to be accessible. But, why was it even resident
ANYWHERE on an out-facing machine?
If I make a purchase, I provide a CC number, name ("as it
appears on the card") and the CVC number off the back.
To validate my card, it would be foolish to:
select name, cvc from credit_cards where card_number = CC_provided
if name != name_provided
or cvc != cvc_provided
then reject_transaction
while this, by itself, is correct and "secure", the approach
requires the credit_cards table to contain ALL of the data for
every credit card. AND, has the potential to allow an
adversary to trick the software into revealing all or part of it!
If, OTOH, the implementation was:
if !verify(CC_provided, name_provided, cvc_provided)
then reject_transaction
all of the details can be hidden behind verify() which can
execute on a more secure processor with a more secure protocol.
E.g., compute a hash of these three values and ask the
DBMS if the hash is correct, without ever having the raw data
stored!
An adversary could try to *guess* a valid combination of
name/cc/cvc --- but, would have to repeatedly issue "validate()"
requests -- which can then attract suspicion.
[This is why I allow an object to sever an incoming connection
if *it* detects behaviours that it considers harmful or
suspicious; the OS has no way of making that determination!]
Making MORE things inaccessible (i.e., everything that doesn't
NEED to be accessible -- like Alpha's approach) improves
reliability and security. Because REAL implementations
always have oversights and bugs -- things that you hadn't
considered or for which you hadn't tested.
Again, your application and application domain is likely far
more benign than mine. The people operating your devices
are likely more technically capable (which MIGHT lead to
better process compliance). How likely would one of your
instruments find itself targeted by an attacker? And, your
budget is likely tighter than mine (in terms of money,
resources and performance).
I can *afford* a more featureful OS to offload more of the
work/vulnerability from developers. Doing so lets more
developers tinker in my environment. And, makes the
resulting design (which evolves as each developer adds
to the system) more robust from attack, fault, compromise.
[An adversary is more likely to target one of my systems
than yours: "Deposit $1,000 in this bitcoin account to
regain control over your home/factory/business..."]
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
64-bit embedded computing is here and now James Brakefield <jim.brakefield@ieee.org> - 2021-06-07 07:47 -0700
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-07 14:13 -0700
Re: 64-bit embedded computing is here and now Paul Rubin <no.email@nospam.invalid> - 2021-06-07 22:31 -0700
Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-08 07:59 +0200
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-08 00:39 -0700
Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-08 13:04 +0200
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-08 17:30 -0700
Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-09 09:17 +0200
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 03:12 -0700
Re: 64-bit embedded computing is here and now George Neuner <gneuner2@comcast.net> - 2021-06-12 12:58 -0400
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-12 12:40 -0700
Re: 64-bit embedded computing is here and now Paul Rubin <no.email@nospam.invalid> - 2021-06-09 09:41 -0700
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 10:12 -0700
Re: 64-bit embedded computing is here and now DJ Delorie <dj@delorie.com> - 2021-06-09 13:16 -0400
Re: 64-bit embedded computing is here and now Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2021-06-09 13:44 -0400
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-09 22:03 +0300
Re: 64-bit embedded computing is here and now Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2021-06-09 15:22 -0400
Re: 64-bit embedded computing is here and now Paul Rubin <no.email@nospam.invalid> - 2021-06-09 12:58 -0700
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 16:26 -0700
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-09 23:12 +0300
Re: 64-bit embedded computing is here and now James Brakefield <jim.brakefield@ieee.org> - 2021-06-08 12:38 -0700
Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-08 22:11 +0200
Re: 64-bit embedded computing is here and now James Brakefield <jim.brakefield@ieee.org> - 2021-06-08 14:25 -0700
Re: 64-bit embedded computing is here and now George Neuner <gneuner2@comcast.net> - 2021-06-09 00:16 -0400
Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-09 10:40 +0200
Re: 64-bit embedded computing is here and now Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2021-06-09 22:52 +0200
Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-10 09:37 +0200
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-09 01:01 +0300
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-08 18:29 -0700
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-09 20:56 +0300
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 17:12 -0700
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-10 13:45 +0300
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-10 06:55 -0700
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-10 18:32 +0300
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-10 14:09 -0700
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-11 01:13 +0300
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-10 21:55 -0700
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-11 14:14 +0300
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-11 05:10 -0700
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-11 16:35 +0300
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-11 16:24 -0700
Re: 64-bit embedded computing is here and now George Neuner <gneuner2@comcast.net> - 2021-06-14 05:41 -0400
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-08 16:51 -0700
Re: 64-bit embedded computing is here and now Paul Rubin <no.email@nospam.invalid> - 2021-06-08 18:20 -0700
Re: 64-bit embedded computing is here and now Theo <theom+news@chiark.greenend.org.uk> - 2021-06-09 18:07 +0100
Re: 64-bit embedded computing is here and now Paul Rubin <no.email@nospam.invalid> - 2021-06-09 10:34 -0700
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 16:37 -0700
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 16:43 -0700
Re: 64-bit embedded computing is here and now Theo <theom+news@chiark.greenend.org.uk> - 2021-06-08 15:46 +0100
Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-08 22:18 +0200
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-08 23:39 +0300
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-08 18:33 -0700
Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-09 10:59 +0200
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-09 21:00 +0300
Re: 64-bit embedded computing is here and now David Brown <david.brown@hesbynett.no> - 2021-06-09 20:55 +0200
Re: 64-bit embedded computing is here and now Dimiter_Popoff <dp@tgi-sci.com> - 2021-06-09 22:06 +0300
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-08 16:00 -0700
Re: 64-bit embedded computing is here and now Theo <theom+news@chiark.greenend.org.uk> - 2021-06-09 13:10 +0100
Re: 64-bit embedded computing is here and now Don Y <blockedofcourse@foo.invalid> - 2021-06-09 06:19 -0700
csiph-web