Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch > #109362 > unrolled thread
| Started by | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| First post | 2024-10-01 19:02 +0000 |
| Last post | 2024-10-03 00:30 +0000 |
| Articles | 20 on this page of 456 — 31 participants |
Back to article view | Back to comp.arch
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) mitchalsup@aol.com (MitchAlsup1) - 2024-10-01 19:02 +0000
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) Thomas Koenig <tkoenig@netcologne.de> - 2024-10-01 20:00 +0000
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) mitchalsup@aol.com (MitchAlsup1) - 2024-10-01 21:04 +0000
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) Brett <ggtgp@yahoo.com> - 2024-10-01 23:38 +0000
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-03 00:31 +0000
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) Brett <ggtgp@yahoo.com> - 2024-10-03 01:26 +0000
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-03 06:28 +0000
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) David Brown <david.brown@hesbynett.no> - 2024-10-03 09:21 +0200
Byte ordering (was: Whether something is RISC or not) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-03 09:39 +0000
Re: Byte ordering (was: Whether something is RISC or not) David Brown <david.brown@hesbynett.no> - 2024-10-03 14:34 +0200
Re: Byte ordering (was: Whether something is RISC or not) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-03 22:17 +0000
Re: Byte ordering Lynn Wheeler <lynn@garlic.com> - 2024-10-03 15:33 -1000
Re: Byte ordering (was: Whether something is RISC or not) David Brown <david.brown@hesbynett.no> - 2024-10-04 11:23 +0200
Re: Byte ordering (was: Whether something is RISC or not) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-04 17:30 +0000
Re: Byte ordering BGB <cr88192@gmail.com> - 2024-10-04 14:05 -0500
Re: Byte ordering mitchalsup@aol.com (MitchAlsup1) - 2024-10-04 23:06 +0000
Re: Byte ordering BGB <cr88192@gmail.com> - 2024-10-04 19:44 -0500
Re: Byte ordering Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-05 06:35 +0000
Re: Byte ordering Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-05 06:34 +0000
Re: Byte ordering (was: Whether something is RISC or not) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-05 06:31 +0000
Re: Byte ordering (was: Whether something is RISC or not) Brett <ggtgp@yahoo.com> - 2024-10-05 17:52 +0000
Re: Byte ordering (was: Whether something is RISC or not) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-05 18:11 +0000
Re: Byte ordering (was: Whether something is RISC or not) Michael S <already5chosen@yahoo.com> - 2024-10-05 22:53 +0300
Re: Byte ordering Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-06 22:07 +0200
Re: Byte ordering (was: Whether something is RISC or not) Brett <ggtgp@yahoo.com> - 2024-10-06 21:53 +0000
Re: Byte ordering (was: Whether something is RISC or not) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-07 06:29 +0000
Re: Byte ordering (was: Whether something is RISC or not) Brett <ggtgp@yahoo.com> - 2024-10-07 16:16 +0000
Re: Byte ordering (was: Whether something is RISC or not) Michael S <already5chosen@yahoo.com> - 2024-10-07 19:57 +0300
Re: Byte ordering Stefan Monnier <monnier@iro.umontreal.ca> - 2024-10-07 16:00 -0400
Re: Byte ordering Michael S <already5chosen@yahoo.com> - 2024-10-08 00:11 +0300
Re: Byte ordering (was: Whether something is RISC or not) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-07 21:46 +0000
Re: Byte ordering Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-08 10:40 +0200
Re: Byte ordering David Brown <david.brown@hesbynett.no> - 2024-10-06 11:58 +0200
Re: Byte ordering anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-06 13:04 +0000
Re: Byte ordering jgd@cix.co.uk (John Dallman) - 2024-10-06 16:34 +0100
Re: Byte ordering Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-07 06:32 +0000
Re: Byte ordering jgd@cix.co.uk (John Dallman) - 2024-10-08 22:28 +0100
Re: Byte ordering EricP <ThatWouldBeTelling@thevillage.com> - 2024-10-09 13:37 -0400
VMS/NT memory management (was: Byte ordering) Stefan Monnier <monnier@iro.umontreal.ca> - 2024-10-09 16:01 -0400
Re: VMS/NT memory management (was: Byte ordering) scott@slp53.sl.home (Scott Lurndal) - 2024-10-09 23:16 +0000
Re: VMS/NT memory management EricP <ThatWouldBeTelling@thevillage.com> - 2024-10-11 15:21 -0400
Re: VMS/NT memory management scott@slp53.sl.home (Scott Lurndal) - 2024-10-12 15:20 +0000
Re: Byte ordering Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-14 23:55 +0000
Re: Byte ordering Michael S <already5chosen@yahoo.com> - 2024-10-15 11:16 +0300
Re: Byte ordering jgd@cix.co.uk (John Dallman) - 2024-10-15 18:40 +0100
Re: Byte ordering Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-18 05:56 +0000
Re: Byte ordering jgd@cix.co.uk (John Dallman) - 2024-10-15 18:40 +0100
Re: Byte ordering scott@slp53.sl.home (Scott Lurndal) - 2024-10-15 18:57 +0000
Re: Byte ordering George Neuner <gneuner2@comcast.net> - 2024-10-15 19:51 -0400
Re: Byte ordering Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-16 07:36 +0200
Re: Byte ordering David Brown <david.brown@hesbynett.no> - 2024-10-16 09:17 +0200
Re: Byte ordering George Neuner <gneuner2@comcast.net> - 2024-10-16 21:19 -0400
Re: Byte ordering David Brown <david.brown@hesbynett.no> - 2024-10-17 14:39 +0200
Re: clouds, not Byte ordering John Levine <johnl@taugh.com> - 2024-10-17 02:35 +0000
Re: clouds, not Byte ordering David Brown <david.brown@hesbynett.no> - 2024-10-17 14:41 +0200
Re: Byte ordering Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-18 05:57 +0000
Re: Byte ordering "Paul A. Clayton" <paaronclayton@gmail.com> - 2024-10-16 11:34 -0400
Re: Microkernels & Capabilities (was Re: Byte ordering) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-18 05:54 +0000
Re: Byte ordering Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-14 23:51 +0000
Re: Byte ordering mitchalsup@aol.com (MitchAlsup1) - 2024-10-15 00:17 +0000
80286 protected mode anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-07 07:33 +0000
Re: 80286 protected mode Lars Poulsen <lars@cleo.beagle-ears.com> - 2024-10-07 12:42 +0000
Re: 80286 protected mode Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-07 15:17 +0200
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-07 17:45 +0300
Re: 80286 protected mode Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-07 21:55 +0000
Re: 80286 protected mode Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-08 10:44 +0200
Re: 80286 protected mode Brett <ggtgp@yahoo.com> - 2024-10-07 16:32 +0000
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-07 20:03 +0300
Re: 80286 protected mode Brett <ggtgp@yahoo.com> - 2024-10-07 17:40 +0000
Re: 80286 protected mode Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-07 21:52 +0000
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-07 23:13 +0000
Re: 80286 protected mode Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-08 06:16 +0000
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-08 20:53 +0000
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-09 08:48 +0200
Re: 80286 protected mode Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-14 23:46 +0000
Re: 80286 protected mode anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-08 07:28 +0000
Re: 80286 protected mode Robert Finch <robfi680@gmail.com> - 2024-10-08 07:28 -0400
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-09 10:24 +0200
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-09 16:28 +0000
Re: 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-09 16:42 +0000
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-09 22:20 +0200
Re: 80286 protected mode Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2024-10-09 14:52 -0700
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-10 00:33 +0000
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-10 08:30 +0200
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-10 08:24 +0200
Re: 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-11 08:15 -0700
Re: 80286 protected mode Stefan Monnier <monnier@iro.umontreal.ca> - 2024-10-15 17:26 -0400
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-15 21:55 +0000
Re: 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-15 22:05 +0000
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-16 00:24 +0000
Re: C and turtles, 80286 protected mode John Levine <johnl@taugh.com> - 2024-10-16 01:08 +0000
Re: C and turtles, 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-16 02:48 +0000
Re: C and turtles, 80286 protected mode John Levine <johnl@taugh.com> - 2024-10-16 03:09 +0000
Re: C and turtles, 80286 protected mode Thomas Koenig <tkoenig@netcologne.de> - 2024-10-17 19:49 +0000
Re: C and turtles, 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-17 21:03 +0000
Re: C and turtles, 80286 protected mode Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-20 07:08 +0000
Re: C and turtles, 80286 protected mode George Neuner <gneuner2@comcast.net> - 2024-10-20 15:49 -0400
Re: C and turtles, 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-21 18:19 -0700
Re: C and turtles, 80286 protected mode George Neuner <gneuner2@comcast.net> - 2024-10-22 17:28 -0400
Re: C and turtles, 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-16 10:04 +0200
Re: C and turtles, 80286 protected mode "Paul A. Clayton" <paaronclayton@gmail.com> - 2024-10-16 15:07 -0400
Re: C and turtles, 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-16 19:41 +0000
Re: C and turtles, 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-17 16:13 +0200
Re: C and turtles, 80286 protected mode Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-20 07:07 +0000
Re: C and turtles, 80286 protected mode "Paul A. Clayton" <paaronclayton@gmail.com> - 2024-10-20 12:14 -0400
Re: 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-16 15:38 +0000
Re: 80286 protected mode George Neuner <gneuner2@comcast.net> - 2024-10-16 23:06 -0400
Re: 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-17 03:16 -0700
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-17 16:16 +0200
Re: 80286 protected mode Thomas Koenig <tkoenig@netcologne.de> - 2024-10-16 20:00 +0000
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-16 22:18 +0000
Re: 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-17 01:18 -0700
Re: 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-17 00:40 -0700
Re: fine points of dynamic memory allocation, not 80286 protected mode John Levine <johnl@taugh.com> - 2024-10-17 18:31 +0000
Re: fine points of dynamic memory allocation, not 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-17 19:01 +0000
Re: fine points of dynamic memory allocation, not 80286 protected mode John Levine <johnl@taugh.com> - 2024-10-17 19:32 +0000
Re: fine points of dynamic memory allocation, not 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-17 21:01 +0000
Re: fine points of dynamic memory allocation, not 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-18 07:12 -0700
Re: 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-17 02:48 -0700
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-16 09:38 +0200
Re: 80286 protected mode George Neuner <gneuner2@comcast.net> - 2024-10-16 23:32 -0400
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-17 16:25 +0200
Re: 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-17 03:17 -0700
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-16 09:21 +0200
Re: 80286 protected mode Stefan Monnier <monnier@iro.umontreal.ca> - 2024-10-16 11:18 -0400
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-16 19:57 +0200
Re: 80286 protected mode Stefan Monnier <monnier@iro.umontreal.ca> - 2024-10-21 14:04 -0400
Re: 80286 protected mode Vir Campestris <vir.campestris@invalid.invalid> - 2024-10-18 17:38 +0100
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-18 21:45 +0200
Re: 80286 protected mode Vir Campestris <vir.campestris@invalid.invalid> - 2024-10-20 21:51 +0100
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-21 08:58 +0200
Re: 80286 protected mode Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-21 09:21 +0200
Re: 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-21 18:32 -0700
Retirement hobby (was Re: 80286 protected mode) Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-22 08:27 +0200
Re: Retirement hobby (was Re: 80286 protected mode) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-23 07:25 -0700
Re: Retirement hobby (was Re: 80286 protected mode) mitchalsup@aol.com (MitchAlsup1) - 2024-10-23 18:11 +0000
Re: Retirement hobby (was Re: 80286 protected mode) scott@slp53.sl.home (Scott Lurndal) - 2024-10-23 18:27 +0000
Re: Retirement hobby (was Re: 80286 protected mode) Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-23 21:12 +0200
Re: Retirement hobby (was Re: 80286 protected mode) Vir Campestris <vir.campestris@invalid.invalid> - 2024-10-27 20:45 +0000
Re: Retirement hobby (was Re: 80286 protected mode) Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-23 21:11 +0200
Re: Retirement hobby (was Re: 80286 protected mode) mitchalsup@aol.com (MitchAlsup1) - 2024-10-23 21:01 +0000
Re: Retirement hobby (was Re: 80286 protected mode) Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-24 07:39 +0200
Re: Retirement hobby (was Re: 80286 protected mode) mitchalsup@aol.com (MitchAlsup1) - 2024-10-24 18:32 +0000
Re: Retirement hobby (was Re: 80286 protected mode) Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-28 11:39 +0100
Re: Retirement hobby (was Re: 80286 protected mode) Thomas Koenig <tkoenig@netcologne.de> - 2024-10-28 16:30 +0000
Re: Retirement hobby (was Re: 80286 protected mode) Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2024-10-28 10:12 -0700
Re: Retirement hobby (was Re: 80286 protected mode) Thomas Koenig <tkoenig@netcologne.de> - 2024-10-28 18:14 +0000
Re: Retirement hobby (was Re: 80286 protected mode) EricP <ThatWouldBeTelling@thevillage.com> - 2024-10-28 15:24 -0400
Re: Retirement hobby (was Re: 80286 protected mode) Thomas Koenig <tkoenig@netcologne.de> - 2024-10-29 06:33 +0000
Re: Retirement hobby (was Re: 80286 protected mode) Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-29 08:07 +0100
Re: Retirement hobby (was Re: 80286 protected mode) Thomas Koenig <tkoenig@netcologne.de> - 2024-10-29 19:57 +0000
Re: Retirement hobby (was Re: 80286 protected mode) mitchalsup@aol.com (MitchAlsup1) - 2024-10-29 20:21 +0000
Re: Retirement hobby (was Re: 80286 protected mode) Thomas Koenig <tkoenig@netcologne.de> - 2024-10-29 21:27 +0000
Re: Retirement hobby (was Re: 80286 protected mode) scott@slp53.sl.home (Scott Lurndal) - 2024-10-29 20:30 +0000
Re: Retirement hobby (was Re: 80286 protected mode) EricP <ThatWouldBeTelling@thevillage.com> - 2024-10-29 14:29 -0400
Re: Retirement hobby (was Re: 80286 protected mode) Stefan Monnier <monnier@iro.umontreal.ca> - 2024-10-29 14:19 -0400
Re: Retirement hobby (was Re: 80286 protected mode) Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-23 21:09 +0200
Re: Retirement hobby (was Re: 80286 protected mode) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-24 06:55 +0000
Re: Retirement hobby (was Re: 80286 protected mode) David Brown <david.brown@hesbynett.no> - 2024-10-24 10:00 +0200
Re: Retirement hobby (was Re: 80286 protected mode) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-24 16:34 +0000
Re: portable malloc Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-21 23:17 +0000
Re: portable malloc mitchalsup@aol.com (MitchAlsup1) - 2024-10-21 23:52 +0000
Re: portable malloc Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-22 01:09 +0000
Re: portable malloc George Neuner <gneuner2@comcast.net> - 2024-10-22 17:26 -0400
Re: portable malloc Vir Campestris <vir.campestris@invalid.invalid> - 2024-10-27 20:42 +0000
Re: portable malloc Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-27 21:04 +0000
Re: portable malloc David Schultz <david.schultz@earthlink.net> - 2024-10-27 17:55 -0500
Re: tiny portable malloc John Levine <johnl@taugh.com> - 2024-10-27 23:58 +0000
Re: 80286 protected mode Thomas Koenig <tkoenig@netcologne.de> - 2024-10-09 18:10 +0000
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-09 22:22 +0200
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-09 21:37 +0000
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-10 08:31 +0200
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-10 18:38 +0000
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-10 21:21 +0200
Re: 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-10 20:00 +0000
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-10 23:54 +0300
Re: 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-10 21:03 +0000
Re: 80286 protected mode "Brian G. Lucas" <bagel99@gmail.com> - 2024-10-10 16:19 -0500
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-11 13:37 +0200
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-11 15:13 +0300
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-11 16:54 +0200
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-13 12:00 +0300
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-13 14:10 +0200
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-10 21:30 +0000
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-11 14:10 +0200
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-11 18:55 +0000
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-12 00:02 +0200
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-11 23:32 +0000
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-12 17:16 +0200
Re: 80286 protected mode Bernd Linsel <bl1-thispartdoesnotbelonghere@gmx.com> - 2024-10-12 19:26 +0200
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-13 12:57 +0200
Re: 80286 protected mode Brett <ggtgp@yahoo.com> - 2024-10-13 19:36 +0000
Re: 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-13 19:43 +0000
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-13 23:01 +0300
Re: 80286 protected mode Brett <ggtgp@yahoo.com> - 2024-10-12 18:33 +0000
Re: 80286 protected mode Niklas Holsti <niklas.holsti@tidorum.invalid> - 2024-10-13 10:31 +0300
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-13 12:26 +0300
Re: 80286 protected mode Niklas Holsti <niklas.holsti@tidorum.invalid> - 2024-10-13 13:33 +0300
Re: 80286 protected mode "Brian G. Lucas" <bagel99@gmail.com> - 2024-10-13 15:32 -0500
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-13 13:58 +0200
Re: 80286 protected mode Brett <ggtgp@yahoo.com> - 2024-10-12 05:06 +0000
Re: 80286 protected mode "Brian G. Lucas" <bagel99@gmail.com> - 2024-10-12 12:36 -0500
Re: 80286 protected mode Brett <ggtgp@yahoo.com> - 2024-10-12 18:17 +0000
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-12 18:37 +0000
Re: 80286 protected mode Brett <ggtgp@yahoo.com> - 2024-10-13 01:25 +0000
Re: 80286 protected mode "Paul A. Clayton" <paaronclayton@gmail.com> - 2024-10-12 23:09 -0400
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-12 18:32 +0000
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-13 10:56 +0300
Re: 80286 protected mode "Paul A. Clayton" <paaronclayton@gmail.com> - 2024-10-13 13:32 -0400
Re: 80286 protected mode Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-13 21:21 +0200
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-14 15:19 +0200
Re: 80286 protected mode Terje Mathisen <terje.mathisen@tmsw.no> - 2024-10-14 16:40 +0200
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-14 17:19 +0200
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-14 19:08 +0300
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-15 10:53 +0200
memcpy and friend (was: 80286 protected mode) Michael S <already5chosen@yahoo.com> - 2024-10-15 13:12 +0300
Re: memcpy and friend (was: 80286 protected mode) David Brown <david.brown@hesbynett.no> - 2024-10-15 13:20 +0200
Re: memcpy and friend (was: 80286 protected mode) Michael S <already5chosen@yahoo.com> - 2024-10-15 14:55 +0300
Re: memcpy and friend (was: 80286 protected mode) David Brown <david.brown@hesbynett.no> - 2024-10-15 14:03 +0200
Re: 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-18 06:00 -0700
Re: 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-18 05:39 -0700
Re: 80286 protected mode Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-12 05:11 -0700
Re: 80286 protected mode anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-13 15:45 +0000
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-14 17:04 +0200
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-14 19:02 +0000
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-14 22:20 +0300
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-15 00:14 +0000
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-15 10:41 +0300
Re: 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-14 19:39 +0000
Re: 80286 protected mode mitchalsup@aol.com (MitchAlsup1) - 2024-10-15 00:15 +0000
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-18 12:47 +0300
Re: 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-18 14:06 +0000
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-18 17:34 +0300
Re: 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2024-10-18 16:19 +0000
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-19 19:46 +0300
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-15 12:38 +0200
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-15 14:22 +0300
Re: 80286 protected mode David Brown <david.brown@hesbynett.no> - 2024-10-15 14:09 +0200
Re: 80286 protected mode Brett <ggtgp@yahoo.com> - 2024-10-15 19:46 +0000
Re: 80286 protected mode John Levine <johnl@taugh.com> - 2024-10-08 16:00 +0000
Re: 80286 protected mode anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2024-10-08 16:23 +0000
Re: 80286 protected mode John Levine <johnl@taugh.com> - 2024-10-08 21:03 +0000
Re: 80286 protected mode Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-15 05:20 +0000
Re: 80286 protected mode Michael S <already5chosen@yahoo.com> - 2024-10-15 11:59 +0300
Re: 80286 protected mode Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-18 07:01 +0000
Re: Byte ordering antispam@fricas.org (Waldek Hebisch) - 2025-01-03 03:37 +0000
Re: Byte ordering anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-03 08:38 +0000
Re: Byte ordering scott@slp53.sl.home (Scott Lurndal) - 2025-01-03 18:11 +0000
Re: Byte ordering antispam@fricas.org (Waldek Hebisch) - 2025-01-04 22:40 +0000
Re: Byte ordering Terje Mathisen <terje.mathisen@tmsw.no> - 2025-01-05 08:54 +0100
80286 protected mode (was: Byte ordering) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-05 11:10 +0000
Re: 80286 protected mode (was: Byte ordering) Robert Swindells <rjs@fdy2.co.uk> - 2025-01-05 18:30 +0000
Re: 80286 protected mode "Brian G. Lucas" <bagel99@gmail.com> - 2025-01-05 16:38 -0500
Re: 80286 protected mode antispam@fricas.org (Waldek Hebisch) - 2025-01-05 21:49 +0000
Re: 80286 protected mode George Neuner <gneuner2@comcast.net> - 2025-01-05 23:01 -0500
Segments (was: 80286 protected mode) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-06 08:24 +0000
Re: Segments (was: 80286 protected mode) Michael S <already5chosen@yahoo.com> - 2025-01-06 14:41 +0200
Re: Segments Terje Mathisen <terje.mathisen@tmsw.no> - 2025-01-06 16:05 +0100
Re: Segments anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-06 16:36 +0000
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-06 19:49 +0000
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-06 19:41 +0000
Re: Segments Terje Mathisen <terje.mathisen@tmsw.no> - 2025-01-07 11:45 +0100
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-06 22:02 +0000
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-06 22:57 +0000
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-07 11:05 +0000
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-07 14:43 +0000
Re: Segments Michael S <already5chosen@yahoo.com> - 2025-01-07 17:04 +0200
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-07 15:28 +0000
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-07 16:41 +0000
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-07 20:16 +0000
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-07 21:26 +0000
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-07 22:01 +0000
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-07 23:16 +0000
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-08 11:53 +0000
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-11 22:31 +0000
Re: Segments Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-14 17:46 -0800
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-15 07:09 +0000
Re: Segments Michael S <already5chosen@yahoo.com> - 2025-01-15 14:00 +0200
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-15 18:00 +0000
Re: Segments Michael S <already5chosen@yahoo.com> - 2025-01-15 22:28 +0200
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-15 20:59 +0000
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-16 12:36 +0100
Re: Segments Michael S <already5chosen@yahoo.com> - 2025-01-16 14:35 +0200
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-16 13:59 +0100
Re: Segments antispam@fricas.org (Waldek Hebisch) - 2025-01-16 16:46 +0000
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-16 18:12 +0000
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-16 18:30 +0000
Re: Stacks, was Segments John Levine <johnl@taugh.com> - 2025-01-18 03:08 +0000
Re: Stacks, was Segments Niklas Holsti <niklas.holsti@tidorum.invalid> - 2025-01-18 10:59 +0200
Re: Stacks, was Segments John Levine <johnl@taugh.com> - 2025-01-18 19:41 +0000
Re: Stacks, was Segments David Brown <david.brown@hesbynett.no> - 2025-01-19 17:33 +0100
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-19 18:28 +0000
Re: Stacks, was Segments Michael S <already5chosen@yahoo.com> - 2025-01-20 12:55 +0200
Re: Stacks, was Segments antispam@fricas.org (Waldek Hebisch) - 2025-01-20 11:12 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-20 22:05 +0000
Re: Stacks, was Segments Michael S <already5chosen@yahoo.com> - 2025-01-21 01:25 +0200
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-21 00:17 +0000
Re: Stacks, was Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-21 06:21 +0000
Re: Stacks, was Segments Bill Findlay <findlaybill@blueyonder.co.uk> - 2025-01-21 10:36 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-21 17:49 +0000
Re: Stacks, was Segments Stefan Monnier <monnier@iro.umontreal.ca> - 2025-02-03 14:09 -0500
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-03 21:13 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-03 21:23 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-03 22:47 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-03 23:11 +0000
Re: Stacks, was Segments EricP <ThatWouldBeTelling@thevillage.com> - 2025-02-05 12:11 -0500
Re: Stacks, was Segments EricP <ThatWouldBeTelling@thevillage.com> - 2025-02-05 14:55 -0500
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-05 23:36 +0000
Re: Stacks, was Segments EricP <ThatWouldBeTelling@thevillage.com> - 2025-02-06 11:41 -0500
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-06 17:13 +0000
Re: Stacks, was Segments EricP <ThatWouldBeTelling@thevillage.com> - 2025-02-06 13:51 -0500
Re: Stacks, was Segments Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-02-06 12:06 -0800
Re: Stacks, was Segments EricP <ThatWouldBeTelling@thevillage.com> - 2025-02-06 16:53 -0500
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-07 02:53 +0000
Re: Stacks, was Segments EricP <ThatWouldBeTelling@thevillage.com> - 2025-02-09 15:45 -0500
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-09 21:03 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-07 02:39 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-07 13:57 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-07 18:25 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-07 20:32 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-08 22:19 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-10 20:18 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-10 23:40 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-11 14:04 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-11 20:19 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-11 20:49 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-11 23:29 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-12 00:34 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-13 16:42 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-13 18:12 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-13 21:48 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-13 22:23 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-14 19:13 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-14 19:51 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-14 21:50 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-15 15:31 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-15 23:28 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-16 19:56 +0000
Re: Stacks, was Segments Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-02-11 09:30 -0800
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-11 18:19 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-02-06 20:49 +0000
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-02-05 21:31 +0000
Re: Stacks, was Segments Niklas Holsti <niklas.holsti@tidorum.invalid> - 2025-01-19 23:37 +0200
Re: Stacks, was Segments David Brown <david.brown@hesbynett.no> - 2025-01-20 09:00 +0100
Re: Stacks, was Segments Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-27 17:26 -0800
Re: Stacks, was Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-18 16:30 +0000
Re: Stacks, was Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-18 17:40 +0000
Re: Segments Michael S <already5chosen@yahoo.com> - 2025-01-16 20:46 +0200
Re: Segments antispam@fricas.org (Waldek Hebisch) - 2025-01-16 20:34 +0000
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-16 21:02 +0000
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-16 22:16 +0100
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-16 21:40 +0000
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-17 10:20 +0100
Re: Segments "Brian G. Lucas" <bagel99@gmail.com> - 2025-01-17 10:08 -0500
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-17 15:17 +0000
Re: Segments jgd@cix.co.uk (John Dallman) - 2025-01-19 18:49 +0000
Re: Segments antispam@fricas.org (Waldek Hebisch) - 2025-01-17 02:22 +0000
Re: Segments Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-16 19:52 -0800
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-17 15:52 +0100
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-17 15:30 +0100
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-17 16:42 +0000
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-17 18:21 +0100
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-17 20:08 +0000
Re: Segments George Neuner <gneuner2@comcast.net> - 2025-01-21 20:30 -0500
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-22 02:19 +0000
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-22 14:58 +0000
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-22 17:45 +0000
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-22 20:00 +0000
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-22 22:25 +0000
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-22 22:44 +0000
Re: Segments Michael S <already5chosen@yahoo.com> - 2025-01-23 01:39 +0200
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-23 01:00 +0000
Re: Segments Michael S <already5chosen@yahoo.com> - 2025-01-23 11:52 +0200
Re: Segments Michael S <already5chosen@yahoo.com> - 2025-01-23 17:41 +0200
Re: Segments EricP <ThatWouldBeTelling@thevillage.com> - 2025-01-23 14:22 -0500
Re: Segments anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-23 08:14 +0000
Re: Segments Michael S <already5chosen@yahoo.com> - 2025-01-23 12:23 +0200
Re: Segments anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-23 12:39 +0000
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-23 14:04 +0000
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-23 14:31 +0000
Re: Segments Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-27 17:18 -0800
Re: Segments Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-23 14:02 -0800
Re: Segments George Neuner <gneuner2@comcast.net> - 2025-01-23 11:50 -0500
Re: Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-23 17:18 +0000
Re: stack sizes, Segments John Levine <johnl@taugh.com> - 2025-01-22 02:54 +0000
Re: stack sizes, Segments Michael S <already5chosen@yahoo.com> - 2025-01-22 15:25 +0200
Re: stack sizes, Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-22 15:01 +0000
Re: stack sizes, Segments Michael S <already5chosen@yahoo.com> - 2025-01-23 01:45 +0200
Re: stack sizes, Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-23 01:07 +0000
Re: stack sizes, Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-23 02:47 +0000
Re: stack sizes, Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-23 14:00 +0000
Re: stack sizes, Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-23 17:49 +0000
Re: stack sizes, Segments scott@slp53.sl.home (Scott Lurndal) - 2025-01-23 19:45 +0000
Re: stack sizes, Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-23 20:04 +0000
Re: stack sizes, Segments anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-24 08:11 +0000
Re: stack sizes, Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-24 14:50 +0000
Re: stack sizes, Segments anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-23 07:24 +0000
Re: stack sizes, Segments George Neuner <gneuner2@comcast.net> - 2025-01-22 20:28 -0500
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-16 11:43 +0100
Re: Segments Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-15 13:42 -0800
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-15 22:39 +0000
Re: Segments Terje Mathisen <terje.mathisen@tmsw.no> - 2025-01-16 10:11 +0100
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-16 13:11 +0100
Re: Segments Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-16 13:10 -0800
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-16 22:23 +0100
Re: Segments Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-01-16 09:15 -0800
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-16 17:24 +0000
Re: Segments Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-01-16 09:55 -0800
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-16 18:23 +0000
Re: Segments Terje Mathisen <terje.mathisen@tmsw.no> - 2025-01-16 20:22 +0100
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-16 19:14 +0000
Re: Segments Terje Mathisen <terje.mathisen@tmsw.no> - 2025-01-16 20:12 +0100
Re: Segments Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-16 15:18 -0800
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-16 23:39 +0000
Re: Segments Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-16 17:04 -0800
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-17 02:10 +0000
Re: Segments David Brown <david.brown@hesbynett.no> - 2025-01-17 16:15 +0100
Re: Segments Terje Mathisen <terje.mathisen@tmsw.no> - 2025-01-17 18:02 +0100
Re: Segments Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-17 10:55 -0800
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-17 19:27 +0000
Re: Segments Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-01-17 21:05 -0800
Re: Segments Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-01-20 12:29 -0800
Re: Segments Terje Mathisen <terje.mathisen@tmsw.no> - 2025-01-22 14:15 +0100
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-22 18:44 +0000
Re: Segments mitchalsup@aol.com (MitchAlsup1) - 2025-01-06 23:41 +0000
Re: Segments Thomas Koenig <tkoenig@netcologne.de> - 2025-01-07 10:53 +0000
Re: Segments Andy Valencia <vandys@vsta.org> - 2025-01-11 13:59 -0800
Re: what's a segment, 80286 protected mode John Levine <johnl@taugh.com> - 2025-01-06 18:58 +0000
Re: what's a segment, 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2025-01-06 19:45 +0000
Re: what's a segment, 80286 protected mode scott@slp53.sl.home (Scott Lurndal) - 2025-01-06 19:48 +0000
Re: what's a segment, 80286 protected mode Lynn Wheeler <lynn@garlic.com> - 2025-01-06 17:28 -1000
Re: Byte ordering scott@slp53.sl.home (Scott Lurndal) - 2025-01-05 15:20 +0000
Re: the 286, Byte ordering John Levine <johnl@taugh.com> - 2025-01-05 02:56 +0000
Re: the 286, Byte ordering mitchalsup@aol.com (MitchAlsup1) - 2025-01-05 03:55 +0000
Re: the 286, Byte ordering jgd@cix.co.uk (John Dallman) - 2025-01-05 15:15 +0000
Re: the 286, Byte ordering scott@slp53.sl.home (Scott Lurndal) - 2025-01-05 15:23 +0000
Re: the 286, Byte ordering anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-01-05 17:51 +0000
Re: the 286, Byte ordering mitchalsup@aol.com (MitchAlsup1) - 2025-01-05 19:40 +0000
Re: the 286, Byte ordering John Levine <johnl@taugh.com> - 2025-01-05 20:01 +0000
Re: the 286, Byte ordering Brett <ggtgp@yahoo.com> - 2025-01-05 20:46 +0000
Re: the 286, Byte ordering mitchalsup@aol.com (MitchAlsup1) - 2025-01-05 20:55 +0000
Re: the 286, Byte ordering Terje Mathisen <terje.mathisen@tmsw.no> - 2025-01-05 22:01 +0100
Re: the 286, Byte ordering jgd@cix.co.uk (John Dallman) - 2025-01-06 00:35 +0000
Re: the 286, Byte ordering mitchalsup@aol.com (MitchAlsup1) - 2025-01-06 03:02 +0000
Re: the 286, Byte ordering Michael S <already5chosen@yahoo.com> - 2025-01-06 15:19 +0200
Re: Byte ordering jgd@cix.co.uk (John Dallman) - 2025-01-05 14:48 +0000
Re: Byte ordering (was: Whether something is RISC or not) Michael S <already5chosen@yahoo.com> - 2024-10-06 18:50 +0300
Re: Byte ordering (was: Whether something is RISC or not) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-07 06:33 +0000
Re: Byte ordering (was: Whether something is RISC or not) jgd@cix.co.uk (John Dallman) - 2024-10-03 23:49 +0100
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) Thomas Koenig <tkoenig@netcologne.de> - 2024-10-02 20:23 +0000
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) David Schultz <david.schultz@earthlink.net> - 2024-10-02 10:07 -0500
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) Brett <ggtgp@yahoo.com> - 2024-10-02 16:08 +0000
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) David Schultz <david.schultz@earthlink.net> - 2024-10-02 13:51 -0500
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) mitchalsup@aol.com (MitchAlsup1) - 2024-10-02 21:34 +0000
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) David Schultz <david.schultz@earthlink.net> - 2024-10-02 18:55 -0500
Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-10-03 00:30 +0000
Page 16 of 23 — ← Prev page 1 … 14 15 [16] 17 18 … 23 Next page →
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-02-03 14:09 -0500 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <jwv5xlqlua6.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #110592 |
> It is like there is a privilege level between application and GuestOS.
> {{I spent all afternoon trying to think of a name for this privilege
> above application "non-privileged" and below "privileged". Maybe
> meso-privileged ?!?
handyman?
Stefan
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-02-03 21:13 +0000 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <UjaoP.1955231$Uup4.1752891@fx10.iad> |
| In reply to | #110691 |
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> It is like there is a privilege level between application and GuestOS.
>> {{I spent all afternoon trying to think of a name for this privilege
>> above application "non-privileged" and below "privileged". Maybe
>> meso-privileged ?!?
>
>handyman?
Application -> Library -> OS -> Hypervisor -> Secure Monitor
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-02-03 21:23 +0000 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <4813354ce36072fc01ed5da902d798f6@www.novabbs.org> |
| In reply to | #110696 |
On Mon, 3 Feb 2025 21:13:24 +0000, Scott Lurndal wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> It is like there is a privilege level between application and GuestOS.
>>> {{I spent all afternoon trying to think of a name for this privilege
>>> above application "non-privileged" and below "privileged". Maybe
>>> meso-privileged ?!?
>>
>>handyman?
>
> Application -> Library -> OS -> Hypervisor -> Secure Monitor
{Sandbox -> user -> application -> Library} ->{sual}×{GuestOS, HV, SM}
??
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-02-03 22:47 +0000 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <0IboP.166940$V9s2.82811@fx34.iad> |
| In reply to | #110697 |
mitchalsup@aol.com (MitchAlsup1) writes:
>On Mon, 3 Feb 2025 21:13:24 +0000, Scott Lurndal wrote:
>
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>> It is like there is a privilege level between application and GuestOS.
>>>> {{I spent all afternoon trying to think of a name for this privilege
>>>> above application "non-privileged" and below "privileged". Maybe
>>>> meso-privileged ?!?
>>>
>>>handyman?
>>
>> Application -> Library -> OS -> Hypervisor -> Secure Monitor
>
>
>{Sandbox -> user -> application -> Library} ->{sual}×{GuestOS, HV, SM}
>
>??
You need to precisely define your terms. What are sandbox
and user in this context?
The hypervisor is optional, as would be a library.
The Burroughs Large systems and HP-3000 segmented libraries
were distinct entities with attributes.
Code in a library could be more privileged than the application
when acting on behalf of the application, for example; but the
application could not take advantage of the permissions assigned
to the library it was linked with without using interfaces
provided by the library.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-02-03 23:11 +0000 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <c81b575bb969c63fc7a58fc4ba13a19b@www.novabbs.org> |
| In reply to | #110703 |
On Mon, 3 Feb 2025 22:47:24 +0000, Scott Lurndal wrote:
> mitchalsup@aol.com (MitchAlsup1) writes:
>>On Mon, 3 Feb 2025 21:13:24 +0000, Scott Lurndal wrote:
>>
>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>>> It is like there is a privilege level between application and GuestOS.
>>>>> {{I spent all afternoon trying to think of a name for this privilege
>>>>> above application "non-privileged" and below "privileged". Maybe
>>>>> meso-privileged ?!?
>>>>
>>>>handyman?
>>>
>>> Application -> Library -> OS -> Hypervisor -> Secure Monitor
>>
>>
>>{Sandbox -> user -> application -> Library} ->{sual}×{GuestOS, HV, SM}
>>
>>??
>
> You need to precisely define your terms. What are sandbox
> and user in this context?
It is all about manipulating access rights without modifying
what is stored in the TLB (so you don't have to reload any
entries to change access rights.) It is sort of like what
the G-bit does (global) {except in my architecture globality
is controlled by ASID.}
Sandbox is a privilege level where one cannot be granted both
write and execute access at the same time. There may be other
restrictions, too; like access to control registers user may
be allowed to write.
Library would include all the trusted stuff, but also ld.so
and any JITs. JITs can only create code for sandboxes. So,
JIT can write to JITcache but sandbox cannot using the same
PTE entry. ld.so can write GOT while user and application
cannot write GOT (or execute GOT).
User is the privilege level where sandbox does not apply but
also there is no ability to over-access things protected by
PTE.RWE.
Application is a privilege level where PTE.RWE can sometimes
be usurped--such as DMA from a device needing to write into
a execute only page.
Where does memmove() come from is not the library ??
Libraries have a SW-kind of trust even if they are
devoid of HW kinds of trust (PTE.RWE overrides).
But these levels are just talking point at this point.
> The hypervisor is optional, as would be a library.
It cannot be a library of process !!
It is not a library of GuestOS !
it is certainly not a library of Secure Monitor !!
>
> The Burroughs Large systems and HP-3000 segmented libraries
> were distinct entities with attributes.
And could change (update/upgrade) the library while the process
was running !!
> Code in a library could be more privileged than the application
> when acting on behalf of the application, for example; but the
> application could not take advantage of the permissions assigned
> to the library it was linked with without using interfaces
> provided by the library.
No disagreement.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2025-02-05 12:11 -0500 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <d_MoP.118782$XfF8.100434@fx04.iad> |
| In reply to | #110704 |
MitchAlsup1 wrote:
> On Mon, 3 Feb 2025 22:47:24 +0000, Scott Lurndal wrote:
>
>> mitchalsup@aol.com (MitchAlsup1) writes:
>>> On Mon, 3 Feb 2025 21:13:24 +0000, Scott Lurndal wrote:
>>>
>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>>>> It is like there is a privilege level between application and
>>>>>> GuestOS.
>>>>>> {{I spent all afternoon trying to think of a name for this privilege
>>>>>> above application "non-privileged" and below "privileged". Maybe
>>>>>> meso-privileged ?!?
>>>>>
>>>>> handyman?
>>>>
>>>> Application -> Library -> OS -> Hypervisor -> Secure Monitor
>>>
>>>
>>> {Sandbox -> user -> application -> Library} ->{sual}×{GuestOS, HV, SM}
>>>
>>> ??
>>
>> You need to precisely define your terms. What are sandbox
>> and user in this context?
>
> It is all about manipulating access rights without modifying
> what is stored in the TLB (so you don't have to reload any
> entries to change access rights.) It is sort of like what
> the G-bit does (global) {except in my architecture globality
> is controlled by ASID.}
>
> Sandbox is a privilege level where one cannot be granted both
> write and execute access at the same time. There may be other
> restrictions, too; like access to control registers user may
> be allowed to write.
>
> Library would include all the trusted stuff, but also ld.so
> and any JITs. JITs can only create code for sandboxes. So,
> JIT can write to JITcache but sandbox cannot using the same
> PTE entry. ld.so can write GOT while user and application
> cannot write GOT (or execute GOT).
>
> User is the privilege level where sandbox does not apply but
> also there is no ability to over-access things protected by
> PTE.RWE.
>
> Application is a privilege level where PTE.RWE can sometimes
> be usurped--such as DMA from a device needing to write into
> a execute only page.
>
> Where does memmove() come from is not the library ??
>
> Libraries have a SW-kind of trust even if they are
> devoid of HW kinds of trust (PTE.RWE overrides).
>
> But these levels are just talking point at this point.
It sounds you want something like the VAX privilege/protection mechanism.
It had 4 privilege levels: User, Supervisor, Executive, Kernel.
Each PTE grants R, RW or na (no-access) rights for each priv level.
(Read access implied Execute)
Naively that would take 4*2 = 8 bits in each 32-bit PTE.
However they reduce the combinations with a simple set of rules:
- if any priv level has read access then higher levels have read also.
- if any priv level has write access then higher levels have write also.
That brings the PTE access control field down to 4-bits for all
for priv levels.
For comparison, x64 PTE has 3 bits for 2 priv levels.
=====================================
For the present day we would want REW access control.
Naively this would require 4*3 = 12 bits in each PTE.
If apply the rules:
- we only need a meaningful subset of combinations: na, R, RE, RW, REW.
- no higher priv level can have less access than a lower priv level.
- we can save 1 combo because all 4 priv levels = na is redundant
with the PTE Present bit being clear.
we can get this all down to a 4-bit PTE field:
Usr Sup Exc Krn
--- --- --- ---
na na na R
na na na RE
na na na RW
na na na REW
na na R R
na na RE RE
...
R R R R
...
REW REW REW REW
The core's (thread's) privilege mode would enable access to the pages.
The PTE's access control field, which is derived from the kind of
mapped memory section, would not have to change between different threads.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2025-02-05 14:55 -0500 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <MmPoP.612616$px2.353443@fx13.iad> |
| In reply to | #110732 |
EricP wrote: > > ===================================== > For the present day we would want REW access control. > Naively this would require 4*3 = 12 bits in each PTE. > > If apply the rules: > - we only need a meaningful subset of combinations: na, R, RE, RW, REW. > - no higher priv level can have less access than a lower priv level. > - we can save 1 combo because all 4 priv levels = na is redundant > with the PTE Present bit being clear. > > we can get this all down to a 4-bit PTE field: > > Usr Sup Exc Krn > --- --- --- --- > na na na R > na na na RE > na na na RW > na na na REW > na na R R > na na RE RE > .... > R R R R > .... > REW REW REW REW > > The core's (thread's) privilege mode would enable access to the pages. > The PTE's access control field, which is derived from the kind of > mapped memory section, would not have to change between different threads. Or if you want the flexibility to choose your own REW combinations, the 4-bit PTE access control field is an index to a 16 entry array of 12-bit values for the four privilege levels. That's better because then the OS can decide how it wants the different memory sections and thread to behave and removes the strict hardwired hierarchy of the prior rules. The next problem though might be finding 4 bits in the PTE. (That is how I see the PTE's 2 or 3 Cache Control bits to work. Also there are separate CC lookup tables for interior table PTE's and leaf table PTE's entries.)
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-02-05 23:36 +0000 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <876e9cf6b21da15dc541756be2e24049@www.novabbs.org> |
| In reply to | #110732 |
On Wed, 5 Feb 2025 17:11:57 +0000, EricP wrote:
> MitchAlsup1 wrote:
>>
>> But these levels are just talking point at this point.
>
> It sounds you want something like the VAX privilege/protection
> mechanism.
> It had 4 privilege levels: User, Supervisor, Executive, Kernel.
> Each PTE grants R, RW or na (no-access) rights for each priv level.
> (Read access implied Execute)
> Naively that would take 4*2 = 8 bits in each 32-bit PTE.
>
> However they reduce the combinations with a simple set of rules:
> - if any priv level has read access then higher levels have read also.
> - if any priv level has write access then higher levels have write also.
>
> That brings the PTE access control field down to 4-bits for all
> for priv levels.
Yes, but in VAX's time we did not have applications that did not want
the OS to look at their data (banking, video streaming, ...) or a
massive number of attackers causing an increased demand for protection
{even to the point of resurrecting capability machines (CHERRI)}.
> For comparison, x64 PTE has 3 bits for 2 priv levels.
>
EricP: thank you for the following thoughts.
On Wed, 5 Feb 2025 19:55:14 +0000, EricP wrote:
> EricP wrote:
>>
>> =====================================
>> For the present day we would want REW access control.
>> Naively this would require 4*3 = 12 bits in each PTE.
>>
>> If apply the rules:
>> - we only need a meaningful subset of combinations: na, R, RE, RW, REW.
>> - no higher priv level can have less access than a lower priv level.
>> - we can save 1 combo because all 4 priv levels = na is redundant
>> with the PTE Present bit being clear.
>>
>> we can get this all down to a 4-bit PTE field:
>>
>> Usr Sup Exc Krn
>> --- --- --- ---
>> na na na R
>> na na na RE
>> na na na RW
>> na na na REW
>> na na R R
>> na na RE RE
>> ....
>> R R R R
>> ....
>> REW REW REW REW
>>
>> The core's (thread's) privilege mode would enable access to the pages.
>> The PTE's access control field, which is derived from the kind of
>> mapped memory section, would not have to change between different
>> threads.
>
> Or if you want the flexibility to choose your own REW combinations,
> the 4-bit PTE access control field is an index to a 16 entry array
> of 12-bit values for the four privilege levels.
>
> That's better because then the OS can decide how it wants
> the different memory sections and thread to behave and
> removes the strict hardwired hierarchy of the prior rules.
>
> The next problem though might be finding 4 bits in the PTE.
Another PTE bit I can find. Placing the 16×12 vector is more difficult,
even when I position it as 4 places of 16×3.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2025-02-06 11:41 -0500 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <cD5pP.2723581$FOb4.2209520@fx15.iad> |
| In reply to | #110741 |
MitchAlsup1 wrote: > On Wed, 5 Feb 2025 19:55:14 +0000, EricP wrote: > >> EricP wrote: >>> >>> ===================================== >>> For the present day we would want REW access control. >>> Naively this would require 4*3 = 12 bits in each PTE. >>> >>> If apply the rules: >>> - we only need a meaningful subset of combinations: na, R, RE, RW, REW. >>> - no higher priv level can have less access than a lower priv level. >>> - we can save 1 combo because all 4 priv levels = na is redundant >>> with the PTE Present bit being clear. >>> >>> we can get this all down to a 4-bit PTE field: >>> >>> Usr Sup Exc Krn >>> --- --- --- --- >>> na na na R >>> na na na RE >>> na na na RW >>> na na na REW >>> na na R R >>> na na RE RE >>> .... >>> R R R R >>> .... >>> REW REW REW REW >>> >>> The core's (thread's) privilege mode would enable access to the pages. >>> The PTE's access control field, which is derived from the kind of >>> mapped memory section, would not have to change between different >>> threads. >> >> Or if you want the flexibility to choose your own REW combinations, >> the 4-bit PTE access control field is an index to a 16 entry array >> of 12-bit values for the four privilege levels. >> >> That's better because then the OS can decide how it wants >> the different memory sections and thread to behave and >> removes the strict hardwired hierarchy of the prior rules. >> >> The next problem though might be finding 4 bits in the PTE. > > Another PTE bit I can find. Placing the 16×12 vector is more difficult, > even when I position it as 4 places of 16×3. I don't understand what you said. The 4-bit Access Control (AC) field is in the PTE. The 16 row x 12-bit AC-to-allowed-access programmable HW lookup table is in the MMU. The core's 2-bit mode selects-muxes one of the 3-bit allowed access fields from the indexed 12-bits to extract the 3 R-E-W bits. The 2-bit mode comes from the LD/ST uOp, which was set to the mode active when the instruction was decoded (so it can pipeline mode changes).
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-02-06 17:13 +0000 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <710d0f743fb3204b909114db4429633d@www.novabbs.org> |
| In reply to | #110754 |
On Thu, 6 Feb 2025 16:41:45 +0000, EricP wrote: > MitchAlsup1 wrote: >> On Wed, 5 Feb 2025 19:55:14 +0000, EricP wrote: >> >>> EricP wrote: >>>> >>>> ===================================== >>>> For the present day we would want REW access control. >>>> Naively this would require 4*3 = 12 bits in each PTE. >>>> >>>> If apply the rules: >>>> - we only need a meaningful subset of combinations: na, R, RE, RW, REW. >>>> - no higher priv level can have less access than a lower priv level. >>>> - we can save 1 combo because all 4 priv levels = na is redundant >>>> with the PTE Present bit being clear. >>>> >>>> we can get this all down to a 4-bit PTE field: >>>> >>>> Usr Sup Exc Krn >>>> --- --- --- --- >>>> na na na R >>>> na na na RE >>>> na na na RW >>>> na na na REW >>>> na na R R >>>> na na RE RE >>>> .... >>>> R R R R >>>> .... >>>> REW REW REW REW >>>> >>>> The core's (thread's) privilege mode would enable access to the pages. >>>> The PTE's access control field, which is derived from the kind of >>>> mapped memory section, would not have to change between different >>>> threads. >>> >>> Or if you want the flexibility to choose your own REW combinations, >>> the 4-bit PTE access control field is an index to a 16 entry array >>> of 12-bit values for the four privilege levels. >>> >>> That's better because then the OS can decide how it wants >>> the different memory sections and thread to behave and >>> removes the strict hardwired hierarchy of the prior rules. >>> >>> The next problem though might be finding 4 bits in the PTE. >> >> Another PTE bit I can find. Placing the 16×12 vector is more difficult, >> even when I position it as 4 places of 16×3. > > I don't understand what you said. > The 4-bit Access Control (AC) field is in the PTE. Currently, PTE uses a 3-bit access control field, and PTE has 2-bits spare. So making access control larger is easy. > The 16 row x 12-bit AC-to-allowed-access programmable HW lookup table > is in the MMU. How does 16×12 get to the MMU (or I/O MMU) ?? in such a way that super cannot see things Hyper can see and the same with secure. So, somewhere in the various control blocks I need to find space without changing the overall use pattern of the control blocks and tables. Which is why I alluded to 4×16×3 each interpretation of the 4-bit access control is stored it its own natural place. It also means each layer can apply its own interpretation (mapping). > The core's 2-bit mode selects-muxes one of the 3-bit allowed access > fields from the indexed 12-bits to extract the 3 R-E-W bits. That much is straightforward. > The 2-bit mode comes from the LD/ST uOp, which was set to the mode > active when the instruction was decoded (so it can pipeline mode > changes). Yes, core-state index follows the memref down the pipe. Core-state index is written into MMI/O/device control block for the DMA portion of a command, other CD indexes are associated with I/O page faults and device errors.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2025-02-06 13:51 -0500 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <7y7pP.2$JzO2.1@fx15.iad> |
| In reply to | #110756 |
MitchAlsup1 wrote: > On Thu, 6 Feb 2025 16:41:45 +0000, EricP wrote: > >> MitchAlsup1 wrote: >>> On Wed, 5 Feb 2025 19:55:14 +0000, EricP wrote: >>> >>>> EricP wrote: >>>>> >>>>> ===================================== >>>>> For the present day we would want REW access control. >>>>> Naively this would require 4*3 = 12 bits in each PTE. >>>>> >>>>> If apply the rules: >>>>> - we only need a meaningful subset of combinations: na, R, RE, RW, >>>>> REW. >>>>> - no higher priv level can have less access than a lower priv level. >>>>> - we can save 1 combo because all 4 priv levels = na is redundant >>>>> with the PTE Present bit being clear. >>>>> >>>>> we can get this all down to a 4-bit PTE field: >>>>> >>>>> Usr Sup Exc Krn >>>>> --- --- --- --- >>>>> na na na R >>>>> na na na RE >>>>> na na na RW >>>>> na na na REW >>>>> na na R R >>>>> na na RE RE >>>>> .... >>>>> R R R R >>>>> .... >>>>> REW REW REW REW >>>>> >>>>> The core's (thread's) privilege mode would enable access to the pages. >>>>> The PTE's access control field, which is derived from the kind of >>>>> mapped memory section, would not have to change between different >>>>> threads. >>>> >>>> Or if you want the flexibility to choose your own REW combinations, >>>> the 4-bit PTE access control field is an index to a 16 entry array >>>> of 12-bit values for the four privilege levels. >>>> >>>> That's better because then the OS can decide how it wants >>>> the different memory sections and thread to behave and >>>> removes the strict hardwired hierarchy of the prior rules. >>>> >>>> The next problem though might be finding 4 bits in the PTE. >>> >>> Another PTE bit I can find. Placing the 16×12 vector is more difficult, >>> even when I position it as 4 places of 16×3. >> >> I don't understand what you said. >> The 4-bit Access Control (AC) field is in the PTE. > > Currently, PTE uses a 3-bit access control field, and PTE has > 2-bits spare. So making access control larger is easy. > >> The 16 row x 12-bit AC-to-allowed-access programmable HW lookup table >> is in the MMU. > > How does 16×12 get to the MMU (or I/O MMU) ?? in such a way that super > cannot see things Hyper can see and the same with secure. So, somewhere > in the various control blocks I need to find space without changing > the overall use pattern of the control blocks and tables. Which is > why I alluded to 4×16×3 each interpretation of the 4-bit access control > is stored it its own natural place. It also means each layer can apply > its own interpretation (mapping). Its just an SRAM loaded by the boot ROM before the Hypervisor boots. The super-secure version of boot ROM loads a table with values (Sandbox, User, Kernel, Hypervisor): Snd Usr Krn Hyp na na na R na na na RE na na na RW na na na REW na na R na na na RE na na na RW na na na REW na na R R na na RE RE na ... REW REW REW na which grants mode 0 (Hyp) no direct RW access to any memory outside itself. Boot ROM sets an optional table lock so even hypervisor cannot later grant itself access permission to less priv memory by changing the table. >> The core's 2-bit mode selects-muxes one of the 3-bit allowed access >> fields from the indexed 12-bits to extract the 3 R-E-W bits. > > That much is straightforward. > >> The 2-bit mode comes from the LD/ST uOp, which was set to the mode >> active when the instruction was decoded (so it can pipeline mode >> changes). > > Yes, core-state index follows the memref down the pipe. > Core-state index is written into MMI/O/device control block for the > DMA portion of a command, other CD indexes are associated with I/O > page faults and device errors. Not sure how this would work with device IO and DMA. Say a secure kernel that owns a disk drive with secrets that even the HV is not authorized to see (so HV operators don't need Top Secret clearance). The Hypervisor has to pass to a hardware device DMA access to a memory frame that it has no access to itself. How does one block the HV from setting the IOMMU to DMA the device's secrets into its own memory? Hmmm... something like: once a secure HV passes a physical frame address to a secure kernel then it cannot take it back, it can only ask that kernel for it back. Which means that the HV looses control of any core or IOMMU PTE's that map that frame until it is handed back. That would seem to imply that once an HV gives memory to a secure guest kernel that it can only page that guest with its permission. Hmmm...
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-02-06 12:06 -0800 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <vo34o7$30da3$1@dont-email.me> |
| In reply to | #110758 |
On 2/6/2025 10:51 AM, EricP wrote: > MitchAlsup1 wrote: >> On Thu, 6 Feb 2025 16:41:45 +0000, EricP wrote: >> >>> MitchAlsup1 wrote: >>>> On Wed, 5 Feb 2025 19:55:14 +0000, EricP wrote: >>>> >>>>> EricP wrote: >>>>>> >>>>>> ===================================== >>>>>> For the present day we would want REW access control. >>>>>> Naively this would require 4*3 = 12 bits in each PTE. >>>>>> >>>>>> If apply the rules: >>>>>> - we only need a meaningful subset of combinations: na, R, RE, RW, >>>>>> REW. >>>>>> - no higher priv level can have less access than a lower priv level. >>>>>> - we can save 1 combo because all 4 priv levels = na is redundant >>>>>> with the PTE Present bit being clear. >>>>>> >>>>>> we can get this all down to a 4-bit PTE field: >>>>>> >>>>>> Usr Sup Exc Krn >>>>>> --- --- --- --- >>>>>> na na na R >>>>>> na na na RE >>>>>> na na na RW >>>>>> na na na REW >>>>>> na na R R >>>>>> na na RE RE >>>>>> .... >>>>>> R R R R >>>>>> .... >>>>>> REW REW REW REW >>>>>> >>>>>> The core's (thread's) privilege mode would enable access to the >>>>>> pages. >>>>>> The PTE's access control field, which is derived from the kind of >>>>>> mapped memory section, would not have to change between different >>>>>> threads. >>>>> >>>>> Or if you want the flexibility to choose your own REW combinations, >>>>> the 4-bit PTE access control field is an index to a 16 entry array >>>>> of 12-bit values for the four privilege levels. >>>>> >>>>> That's better because then the OS can decide how it wants >>>>> the different memory sections and thread to behave and >>>>> removes the strict hardwired hierarchy of the prior rules. >>>>> >>>>> The next problem though might be finding 4 bits in the PTE. >>>> >>>> Another PTE bit I can find. Placing the 16×12 vector is more difficult, >>>> even when I position it as 4 places of 16×3. >>> >>> I don't understand what you said. >>> The 4-bit Access Control (AC) field is in the PTE. >> >> Currently, PTE uses a 3-bit access control field, and PTE has >> 2-bits spare. So making access control larger is easy. >> >>> The 16 row x 12-bit AC-to-allowed-access programmable HW lookup table >>> is in the MMU. >> >> How does 16×12 get to the MMU (or I/O MMU) ?? in such a way that super >> cannot see things Hyper can see and the same with secure. So, somewhere >> in the various control blocks I need to find space without changing >> the overall use pattern of the control blocks and tables. Which is >> why I alluded to 4×16×3 each interpretation of the 4-bit access control >> is stored it its own natural place. It also means each layer can apply >> its own interpretation (mapping). > > Its just an SRAM loaded by the boot ROM before the Hypervisor boots. > The super-secure version of boot ROM loads a table with values > (Sandbox, User, Kernel, Hypervisor): > > Snd Usr Krn Hyp > na na na R > na na na RE > na na na RW > na na na REW > na na R na > na na RE na > na na RW na > na na REW na > na R R na > na RE RE na > ... > REW REW REW na > > which grants mode 0 (Hyp) no direct RW access to any memory outside itself. > Boot ROM sets an optional table lock so even hypervisor cannot later > grant itself access permission to less priv memory by changing the table. > >>> The core's 2-bit mode selects-muxes one of the 3-bit allowed access >>> fields from the indexed 12-bits to extract the 3 R-E-W bits. >> >> That much is straightforward. >> >>> The 2-bit mode comes from the LD/ST uOp, which was set to the mode >>> active when the instruction was decoded (so it can pipeline mode >>> changes). >> >> Yes, core-state index follows the memref down the pipe. >> Core-state index is written into MMI/O/device control block for the >> DMA portion of a command, other CD indexes are associated with I/O >> page faults and device errors. > > Not sure how this would work with device IO and DMA. > Say a secure kernel that owns a disk drive with secrets that even the HV > is not authorized to see (so HV operators don't need Top Secret clearance). > The Hypervisor has to pass to a hardware device DMA access to a memory > frame that it has no access to itself. How does one block the HV from > setting the IOMMU to DMA the device's secrets into its own memory? > > Hmmm... something like: once a secure HV passes a physical frame address > to a secure kernel then it cannot take it back, it can only ask that > kernel for it back. Which means that the HV looses control of any > core or IOMMU PTE's that map that frame until it is handed back. > > That would seem to imply that once an HV gives memory to a secure > guest kernel that it can only page that guest with its permission. > Hmmm... I am a little confused here. When you talk about I0MMU addresses, are you talking about memory addresses or disk addresses? ISTM that protecting memory of lower privileged programs is useless if a higher privileged program can force a page out to disk, then can read the data from the disk drive itself. Of course, the same is true for data written to disk by a lesser privileged program. If the higher privileged program can read the file, then it can compromise security. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2025-02-06 16:53 -0500 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <TbapP.44$CBr7.11@fx44.iad> |
| In reply to | #110760 |
Stephen Fuld wrote: > On 2/6/2025 10:51 AM, EricP wrote: >> MitchAlsup1 wrote: >>> On Thu, 6 Feb 2025 16:41:45 +0000, EricP wrote: >>> >>>> MitchAlsup1 wrote: >>>>> On Wed, 5 Feb 2025 19:55:14 +0000, EricP wrote: >>>>> >>>>>> EricP wrote: >>>>>>> >>>>>>> ===================================== >>>>>>> For the present day we would want REW access control. >>>>>>> Naively this would require 4*3 = 12 bits in each PTE. >>>>>>> >>>>>>> If apply the rules: >>>>>>> - we only need a meaningful subset of combinations: na, R, RE, >>>>>>> RW, REW. >>>>>>> - no higher priv level can have less access than a lower priv level. >>>>>>> - we can save 1 combo because all 4 priv levels = na is redundant >>>>>>> with the PTE Present bit being clear. >>>>>>> >>>>>>> we can get this all down to a 4-bit PTE field: >>>>>>> >>>>>>> Usr Sup Exc Krn >>>>>>> --- --- --- --- >>>>>>> na na na R >>>>>>> na na na RE >>>>>>> na na na RW >>>>>>> na na na REW >>>>>>> na na R R >>>>>>> na na RE RE >>>>>>> .... >>>>>>> R R R R >>>>>>> .... >>>>>>> REW REW REW REW >>>>>>> >>>>>>> The core's (thread's) privilege mode would enable access to the >>>>>>> pages. >>>>>>> The PTE's access control field, which is derived from the kind of >>>>>>> mapped memory section, would not have to change between different >>>>>>> threads. >>>>>> >>>>>> Or if you want the flexibility to choose your own REW combinations, >>>>>> the 4-bit PTE access control field is an index to a 16 entry array >>>>>> of 12-bit values for the four privilege levels. >>>>>> >>>>>> That's better because then the OS can decide how it wants >>>>>> the different memory sections and thread to behave and >>>>>> removes the strict hardwired hierarchy of the prior rules. >>>>>> >>>>>> The next problem though might be finding 4 bits in the PTE. >>>>> >>>>> Another PTE bit I can find. Placing the 16×12 vector is more >>>>> difficult, >>>>> even when I position it as 4 places of 16×3. >>>> >>>> I don't understand what you said. >>>> The 4-bit Access Control (AC) field is in the PTE. >>> >>> Currently, PTE uses a 3-bit access control field, and PTE has >>> 2-bits spare. So making access control larger is easy. >>> >>>> The 16 row x 12-bit AC-to-allowed-access programmable HW lookup table >>>> is in the MMU. >>> >>> How does 16×12 get to the MMU (or I/O MMU) ?? in such a way that super >>> cannot see things Hyper can see and the same with secure. So, somewhere >>> in the various control blocks I need to find space without changing >>> the overall use pattern of the control blocks and tables. Which is >>> why I alluded to 4×16×3 each interpretation of the 4-bit access control >>> is stored it its own natural place. It also means each layer can apply >>> its own interpretation (mapping). >> >> Its just an SRAM loaded by the boot ROM before the Hypervisor boots. >> The super-secure version of boot ROM loads a table with values >> (Sandbox, User, Kernel, Hypervisor): >> >> Snd Usr Krn Hyp >> na na na R >> na na na RE >> na na na RW >> na na na REW >> na na R na >> na na RE na >> na na RW na >> na na REW na >> na R R na >> na RE RE na >> ... >> REW REW REW na >> >> which grants mode 0 (Hyp) no direct RW access to any memory outside >> itself. >> Boot ROM sets an optional table lock so even hypervisor cannot later >> grant itself access permission to less priv memory by changing the table. >> >>>> The core's 2-bit mode selects-muxes one of the 3-bit allowed access >>>> fields from the indexed 12-bits to extract the 3 R-E-W bits. >>> >>> That much is straightforward. >>> >>>> The 2-bit mode comes from the LD/ST uOp, which was set to the mode >>>> active when the instruction was decoded (so it can pipeline mode >>>> changes). >>> >>> Yes, core-state index follows the memref down the pipe. >>> Core-state index is written into MMI/O/device control block for the >>> DMA portion of a command, other CD indexes are associated with I/O >>> page faults and device errors. >> >> Not sure how this would work with device IO and DMA. >> Say a secure kernel that owns a disk drive with secrets that even the HV >> is not authorized to see (so HV operators don't need Top Secret >> clearance). >> The Hypervisor has to pass to a hardware device DMA access to a memory >> frame that it has no access to itself. How does one block the HV from >> setting the IOMMU to DMA the device's secrets into its own memory? >> >> Hmmm... something like: once a secure HV passes a physical frame address >> to a secure kernel then it cannot take it back, it can only ask that >> kernel for it back. Which means that the HV looses control of any >> core or IOMMU PTE's that map that frame until it is handed back. >> >> That would seem to imply that once an HV gives memory to a secure >> guest kernel that it can only page that guest with its permission. >> Hmmm... > > I am a little confused here. When you talk about I0MMU addresses, are > you talking about memory addresses or disk addresses? ISTM that > protecting memory of lower privileged programs is useless if a higher > privileged program can force a page out to disk, then can read the data > from the disk drive itself. Of course, the same is true for data > written to disk by a lesser privileged program. If the higher > privileged program can read the file, then it can compromise security. I'm just kinda free associating what the consequences of restricting the HV's access to lesser privilege levels might be. As I understand it, the AMD secure HV approach is that memory owned by a guest kernel and its applications is encrypted and only the guest kernel has the key. Memory content is only decrypted while inside the core. As the key is only stored inside that guest kernel memory there is no way for HV to get at it. So it doesn't matter that the HV has access to guest memory because it can only see encrypted memory values. Presumably such data is encrypted on disk so intercepting a DMA gives you nothing. But it doesn't look like blocking HV access to the guest kernel, user, or sandbox memory accomplishes the same security because the HV can always diddle its own page tables to grant itself access.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-02-07 02:53 +0000 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <53523df618d4ccb47978c68c5dc7c171@www.novabbs.org> |
| In reply to | #110764 |
On Thu, 6 Feb 2025 21:53:27 +0000, EricP wrote:
> Stephen Fuld wrote:
>> -----------------
>>
>> I am a little confused here. When you talk about I0MMU addresses, are
>> you talking about memory addresses or disk addresses? ISTM that
>> protecting memory of lower privileged programs is useless if a higher
>> privileged program can force a page out to disk, then can read the data
>> from the disk drive itself. Of course, the same is true for data
>> written to disk by a lesser privileged program. If the higher
>> privileged program can read the file, then it can compromise security.
>
> I'm just kinda free associating what the consequences of restricting
> the HV's access to lesser privilege levels might be.
>
> As I understand it, the AMD secure HV approach is that memory owned by a
> guest kernel and its applications is encrypted and only the guest kernel
> has the key. Memory content is only decrypted while inside the core.
> As the key is only stored inside that guest kernel memory there is
> no way for HV to get at it.
Interesting, so you can see the data you just can't interpret the
bit-patterns. This still leaves the door open for malicious action.
> So it doesn't matter that the HV has access to guest memory because it
> can only see encrypted memory values. Presumably such data is encrypted
> on disk so intercepting a DMA gives you nothing.
It maters if HV can access (especially modify) what is in storage
(not memory), making it impossible for secure process from using
his own data !
> But it doesn't look like blocking HV access to the guest kernel, user,
> or sandbox memory accomplishes the same security because the HV can
> always diddle its own page tables to grant itself access.
My 66000 does it differently. HV can create a PTE that translates
"anywhere", but cannot use the VA of Guest OS or SM in order to
use that PTE. There are 4 VAS privilege levels::
HoB = 0 nest HoB = 1 nest
application: application VAS yes no access X
Guest OS application VAS yes Guest OS VAS yes
HyperVisor HyperVisor VAS no Guest OS VAS yes
Secure HyperVisor VAS no SM VAS no
So, HV has no 'direct' path to Application VAS using standard
memory access protocols.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2025-02-09 15:45 -0500 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <Vt8qP.588847$iNI.121220@fx14.iad> |
| In reply to | #110768 |
MitchAlsup1 wrote: > On Thu, 6 Feb 2025 21:53:27 +0000, EricP wrote: > >> Stephen Fuld wrote: >>> ----------------- >>> >>> I am a little confused here. When you talk about I0MMU addresses, are >>> you talking about memory addresses or disk addresses? ISTM that >>> protecting memory of lower privileged programs is useless if a higher >>> privileged program can force a page out to disk, then can read the data >>> from the disk drive itself. Of course, the same is true for data >>> written to disk by a lesser privileged program. If the higher >>> privileged program can read the file, then it can compromise security. >> >> I'm just kinda free associating what the consequences of restricting >> the HV's access to lesser privilege levels might be. >> >> As I understand it, the AMD secure HV approach is that memory owned by a >> guest kernel and its applications is encrypted and only the guest kernel >> has the key. Memory content is only decrypted while inside the core. >> As the key is only stored inside that guest kernel memory there is >> no way for HV to get at it. > > Interesting, so you can see the data you just can't interpret the > bit-patterns. This still leaves the door open for malicious action. Yes. Their Secure VM sounds exactly like what a timeshare vendor might want if they desire to sell services to governments and businesses that have secrets that rogue operators must provably not access. Also blocks accidental leaks between guests so you could have multiple such secure guest OS on the same host. >> So it doesn't matter that the HV has access to guest memory because it >> can only see encrypted memory values. Presumably such data is encrypted >> on disk so intercepting a DMA gives you nothing. > > It maters if HV can access (especially modify) what is in storage > (not memory), making it impossible for secure process from using > his own data ! Yes a rogue or buggy HV could DoS a guest OS by scrambling its data. Or an ECC memory error on critical memory location, like the key. >> But it doesn't look like blocking HV access to the guest kernel, user, >> or sandbox memory accomplishes the same security because the HV can >> always diddle its own page tables to grant itself access. > > My 66000 does it differently. HV can create a PTE that translates > "anywhere", but cannot use the VA of Guest OS or SM in order to > use that PTE. There are 4 VAS privilege levels:: > > HoB = 0 nest HoB = 1 nest > application: application VAS yes no access X > Guest OS application VAS yes Guest OS VAS yes > HyperVisor HyperVisor VAS no Guest OS VAS yes > Secure HyperVisor VAS no SM VAS no > > So, HV has no 'direct' path to Application VAS using standard > memory access protocols. But the physical memory in use by that guest can be remapped by rogue HV to be in its own virtual space and then accessed.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-02-09 21:03 +0000 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <11e171425c30ac125629c0b2ff600979@www.novabbs.org> |
| In reply to | #110793 |
On Sun, 9 Feb 2025 20:45:13 +0000, EricP wrote: > MitchAlsup1 wrote: >> On Thu, 6 Feb 2025 21:53:27 +0000, EricP wrote: >> >>> Stephen Fuld wrote: >>>> ----------------- >>>> >>>> I am a little confused here. When you talk about I0MMU addresses, are >>>> you talking about memory addresses or disk addresses? ISTM that >>>> protecting memory of lower privileged programs is useless if a higher >>>> privileged program can force a page out to disk, then can read the data >>>> from the disk drive itself. Of course, the same is true for data >>>> written to disk by a lesser privileged program. If the higher >>>> privileged program can read the file, then it can compromise security. >>> >>> I'm just kinda free associating what the consequences of restricting >>> the HV's access to lesser privilege levels might be. >>> >>> As I understand it, the AMD secure HV approach is that memory owned by a >>> guest kernel and its applications is encrypted and only the guest kernel >>> has the key. Memory content is only decrypted while inside the core. >>> As the key is only stored inside that guest kernel memory there is >>> no way for HV to get at it. >> >> Interesting, so you can see the data you just can't interpret the >> bit-patterns. This still leaves the door open for malicious action. > > Yes. Their Secure VM sounds exactly like what a timeshare vendor might > want > if they desire to sell services to governments and businesses that have > secrets that rogue operators must provably not access. Just enough to gain the confidence of *.gov buyers, without enough to prevent NSA from using the data. > Also blocks accidental leaks between guests so you could have multiple > such secure guest OS on the same host. > >>> So it doesn't matter that the HV has access to guest memory because it >>> can only see encrypted memory values. Presumably such data is encrypted >>> on disk so intercepting a DMA gives you nothing. >> >> It maters if HV can access (especially modify) what is in storage >> (not memory), making it impossible for secure process from using >> his own data ! > > Yes a rogue or buggy HV could DoS a guest OS by scrambling its data. > Or an ECC memory error on critical memory location, like the key. > >>> But it doesn't look like blocking HV access to the guest kernel, user, >>> or sandbox memory accomplishes the same security because the HV can >>> always diddle its own page tables to grant itself access. >> >> My 66000 does it differently. HV can create a PTE that translates >> "anywhere", but cannot use the VA of Guest OS or SM in order to >> use that PTE. There are 4 VAS privilege levels:: >> >> HoB = 0 nest HoB = 1 nest >> application: application VAS yes no access X >> Guest OS application VAS yes Guest OS VAS yes >> HyperVisor HyperVisor VAS no Guest OS VAS yes >> Secure HyperVisor VAS no SM VAS no >> >> So, HV has no 'direct' path to Application VAS using standard >> memory access protocols. > > But the physical memory in use by that guest can be remapped > by rogue HV to be in its own virtual space and then accessed. You can never get away from the notion that the code creating PTP and PTE bit patterns, or manipulating Root pointers requires a certain amount of trust.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-02-07 02:39 +0000 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <d077ddea425004a4ba671872727d9937@www.novabbs.org> |
| In reply to | #110760 |
On Thu, 6 Feb 2025 20:06:31 +0000, Stephen Fuld wrote: > On 2/6/2025 10:51 AM, EricP wrote: >> MitchAlsup1 wrote: >>> On Thu, 6 Feb 2025 16:41:45 +0000, EricP wrote: >>>------------------- >> Not sure how this would work with device IO and DMA. >> Say a secure kernel that owns a disk drive with secrets that even the HV >> is not authorized to see (so HV operators don't need Top Secret >> clearance). >> The Hypervisor has to pass to a hardware device DMA access to a memory >> frame that it has no access to itself. How does one block the HV from >> setting the IOMMU to DMA the device's secrets into its own memory? >> >> Hmmm... something like: once a secure HV passes a physical frame address >> to a secure kernel then it cannot take it back, it can only ask that >> kernel for it back. Which means that the HV looses control of any >> core or IOMMU PTE's that map that frame until it is handed back. >> >> That would seem to imply that once an HV gives memory to a secure >> guest kernel that it can only page that guest with its permission. >> Hmmm... > > I am a little confused here. When you talk about I0MMU addresses, are > you talking about memory addresses or disk addresses? I/O MMU does not see the device commands containing the sector on the disk to be accessed, Mostly, CPUs write directly to the CRs of the device to start a command, bypassing I/O MMU as raw data. In my block diagrams of HostBridge, I show I/O MMU only on the receiving side of PCIe transport links. all the outbound traffic has already been translated by a core MMMU, unless one allows a device to send commands to another device. I/O MMU sees the virtual address of where DMA is accessing, translating accordingly. I/O MMU sees the virtual address of MSI-X interrupts, page faults and errors. > ISTM that > protecting memory of lower privileged programs is useless if a higher > privileged program can force a page out to disk, then can read the data > from the disk drive itself. Protecting a process without privilege from a process WITH privilege requires more than a little trust in the privileged process(s). This is why there is a Secure Monitor over HyperVisor to take HV out of the control loop for "secure stuff". By assuming the duties of HV wrt accessing unprivileged memory of storage, SM minimizes the footprint where trust is required. > Of course, the same is true for data > written to disk by a lesser privileged program. If the higher > privileged program can read the file, then it can compromise security.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-02-07 13:57 +0000 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <zjopP.47$2mO5.6@fx36.iad> |
| In reply to | #110767 |
mitchalsup@aol.com (MitchAlsup1) writes: >On Thu, 6 Feb 2025 20:06:31 +0000, Stephen Fuld wrote: > >> On 2/6/2025 10:51 AM, EricP wrote: >>> MitchAlsup1 wrote: >>>> On Thu, 6 Feb 2025 16:41:45 +0000, EricP wrote: >>>>------------------- >>> Not sure how this would work with device IO and DMA. >>> Say a secure kernel that owns a disk drive with secrets that even the HV >>> is not authorized to see (so HV operators don't need Top Secret >>> clearance). >>> The Hypervisor has to pass to a hardware device DMA access to a memory >>> frame that it has no access to itself. How does one block the HV from >>> setting the IOMMU to DMA the device's secrets into its own memory? >>> >>> Hmmm... something like: once a secure HV passes a physical frame address >>> to a secure kernel then it cannot take it back, it can only ask that >>> kernel for it back. Which means that the HV looses control of any >>> core or IOMMU PTE's that map that frame until it is handed back. >>> >>> That would seem to imply that once an HV gives memory to a secure >>> guest kernel that it can only page that guest with its permission. >>> Hmmm... >> >> I am a little confused here. When you talk about I0MMU addresses, are >> you talking about memory addresses or disk addresses? > >I/O MMU does not see the device commands containing the sector on >the disk to be accessed, Mostly, CPUs write directly to the CRs >of the device to start a command, bypassing I/O MMU as raw data. That is indeed the case. The IOMMU is on the inbound path from the PCIe controller to the internal bus/mesh structure. Note that there is a translation on the outbound path from the host address space to the PCIe memory space - this is often 1:1, but need not be so. This translation happens in the PCIe controller when creating the a TLP that contains an address before sending the TLP to the endpoint. Take an AHCI controller, for example, where the only device BAR is 32-bits; if a host wants to map the AHCI controller at a 64-bit address, the controller needs to map that 64-bit address window into a 32-bit 3DW TLP to be sent to the endpoint function. The ARM SMMU is split into two - one that translates inbound addresses that are not marked secure by the endpoint, and one that translates addresses that are marked secure by the endpoint (or by some host bridge between the endpoint and the host internal bus structures which is configured by the secure software). The secure side is managed by the secure monitor; the non-secure side by the HV or bare-metal OS. > >In my block diagrams of HostBridge, I show I/O MMU only on the >receiving side of PCIe transport links. all the outbound traffic >has already been translated by a core MMMU, unless one allows >a device to send commands to another device. > >I/O MMU sees the virtual address of where DMA is accessing, translating >accordingly. > >I/O MMU sees the virtual address of MSI-X interrupts, page faults and >errors. By page faults, I assume you're referring to the PCIe PRI (Page Request Interface) and ATS capabilities. > >> ISTM that >> protecting memory of lower privileged programs is useless if a higher >> privileged program can force a page out to disk, then can read the data >> from the disk drive itself. > >Protecting a process without privilege from a process WITH privilege >requires more than a little trust in the privileged process(s). >This is why there is a Secure Monitor over HyperVisor to take HV out >of the control loop for "secure stuff". By assuming the duties of >HV wrt accessing unprivileged memory of storage, SM minimizes the >footprint where trust is required. ARM has a "RM" (Realm Monitor) that sits between the HV and the SM to manage memory visiblity and security. https://developer.arm.com/documentation/den0127/0200/Software-components/Realm-Management-Monitor > >> Of course, the same is true for data >> written to disk by a lesser privileged program. If the higher >> privileged program can read the file, then it can compromise security. Assuming the file is not secured via other means such as cryptography.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-02-07 18:25 +0000 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <ada844d833260891012f585b6beddb1a@www.novabbs.org> |
| In reply to | #110772 |
On Fri, 7 Feb 2025 13:57:51 +0000, Scott Lurndal wrote:
> mitchalsup@aol.com (MitchAlsup1) writes:
>>On Thu, 6 Feb 2025 20:06:31 +0000, Stephen Fuld wrote:
>>
>>> On 2/6/2025 10:51 AM, EricP wrote:
>>>> MitchAlsup1 wrote:
>>>>> On Thu, 6 Feb 2025 16:41:45 +0000, EricP wrote:
>>>>>-------------------
>>>> Not sure how this would work with device IO and DMA.
>>>> Say a secure kernel that owns a disk drive with secrets that even the HV
>>>> is not authorized to see (so HV operators don't need Top Secret
>>>> clearance).
>>>> The Hypervisor has to pass to a hardware device DMA access to a memory
>>>> frame that it has no access to itself. How does one block the HV from
>>>> setting the IOMMU to DMA the device's secrets into its own memory?
>>>>
>>>> Hmmm... something like: once a secure HV passes a physical frame address
>>>> to a secure kernel then it cannot take it back, it can only ask that
>>>> kernel for it back. Which means that the HV looses control of any
>>>> core or IOMMU PTE's that map that frame until it is handed back.
>>>>
>>>> That would seem to imply that once an HV gives memory to a secure
>>>> guest kernel that it can only page that guest with its permission.
>>>> Hmmm...
>>>
>>> I am a little confused here. When you talk about I0MMU addresses, are
>>> you talking about memory addresses or disk addresses?
>>
>>I/O MMU does not see the device commands containing the sector on
>>the disk to be accessed, Mostly, CPUs write directly to the CRs
>>of the device to start a command, bypassing I/O MMU as raw data.
>
> That is indeed the case. The IOMMU is on the inbound path
> from the PCIe controller to the internal bus/mesh structure.
>
> Note that there is a translation on the outbound path from
> the host address space to the PCIe memory space - this is
> often 1:1, but need not be so. This translation happens
> in the PCIe controller when creating the a TLP that contains
> an address before sending the TLP to the endpoint. Take
Is there any reason this cannot happen in the core MMU ??
Guest OS uses a virtual device address given to it from HV.
HV sets up the 2nd nesting of translation to translate this
to "what HostBridge needs" to route commands to device control
registers. The handoff can be done by spoofing config space
of having HV simply hand Guest OS a list of devices it can
discover/configure/use.
> an AHCI controller, for example, where the only device
> BAR is 32-bits; if a host wants to map the AHCI controller
> at a 64-bit address, the controller needs to map that 64-bit
> address window into a 32-bit 3DW TLP to be sent to the endpoint
> function.
This is one of the reasons My 66000 architecture has a unique
MMI/O address space--you can setup a 32-bit BAR to put a
page of control registers in 32-bit address space without
conflict. {{If I understand correctly}} Core MMU, then,
translates normal device virtual control register addresses
such that the request is routed to where the device is looking
{{which has 32 high order bits zero.}}
On the other hand--it would take a very big system indeed to
overflow the 32-bit MMI/O space, although ECAM can access
42-bit device CR MMI/O space.
> The ARM SMMU is split into two - one that translates inbound
> addresses that are not marked secure by the endpoint, and
> one that translates addresses that are marked secure by the
> endpoint (or by some host bridge between the endpoint and
> the host internal bus structures which is configured by
> the secure software). The secure side is managed by the
> secure monitor; the non-secure side by the HV or bare-metal
> OS.
>
>>
>>In my block diagrams of HostBridge, I show I/O MMU only on the
>>receiving side of PCIe transport links. all the outbound traffic
>>has already been translated by a core MMMU, unless one allows
>>a device to send commands to another device.
>>
>>I/O MMU sees the virtual address of where DMA is accessing, translating
>>accordingly.
>>
>>I/O MMU sees the virtual address of MSI-X interrupts, page faults and
>>errors.
>
> By page faults, I assume you're referring to the PCIe PRI (Page Request
> Interface) and ATS capabilities.
>
>>
>>> ISTM that
>>> protecting memory of lower privileged programs is useless if a higher
>>> privileged program can force a page out to disk, then can read the data
>>> from the disk drive itself.
>>
>>Protecting a process without privilege from a process WITH privilege
>>requires more than a little trust in the privileged process(s).
>>This is why there is a Secure Monitor over HyperVisor to take HV out
>>of the control loop for "secure stuff". By assuming the duties of
>>HV wrt accessing unprivileged memory of storage, SM minimizes the
>>footprint where trust is required.
>
> ARM has a "RM" (Realm Monitor) that sits between the HV and the SM
> to manage memory visiblity and security.
>
> https://developer.arm.com/documentation/den0127/0200/Software-components/Realm-Management-Monitor
>
>>
>>> Of course, the same is true for data
>>> written to disk by a lesser privileged program. If the higher
>>> privileged program can read the file, then it can compromise security.
>
> Assuming the file is not secured via other means such as cryptography.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-02-07 20:32 +0000 |
| Subject | Re: Stacks, was Segments |
| Message-ID | <H5upP.2$72m1.1@fx11.iad> |
| In reply to | #110776 |
mitchalsup@aol.com (MitchAlsup1) writes:
>On Fri, 7 Feb 2025 13:57:51 +0000, Scott Lurndal wrote:
>
>> mitchalsup@aol.com (MitchAlsup1) writes:
>>>On Thu, 6 Feb 2025 20:06:31 +0000, Stephen Fuld wrote:
>>>
>>>> On 2/6/2025 10:51 AM, EricP wrote:
>>>>> MitchAlsup1 wrote:
>>>>>> On Thu, 6 Feb 2025 16:41:45 +0000, EricP wrote:
>>>>>>-------------------
>>>>> Not sure how this would work with device IO and DMA.
>>>>> Say a secure kernel that owns a disk drive with secrets that even the HV
>>>>> is not authorized to see (so HV operators don't need Top Secret
>>>>> clearance).
>>>>> The Hypervisor has to pass to a hardware device DMA access to a memory
>>>>> frame that it has no access to itself. How does one block the HV from
>>>>> setting the IOMMU to DMA the device's secrets into its own memory?
>>>>>
>>>>> Hmmm... something like: once a secure HV passes a physical frame address
>>>>> to a secure kernel then it cannot take it back, it can only ask that
>>>>> kernel for it back. Which means that the HV looses control of any
>>>>> core or IOMMU PTE's that map that frame until it is handed back.
>>>>>
>>>>> That would seem to imply that once an HV gives memory to a secure
>>>>> guest kernel that it can only page that guest with its permission.
>>>>> Hmmm...
>>>>
>>>> I am a little confused here. When you talk about I0MMU addresses, are
>>>> you talking about memory addresses or disk addresses?
>>>
>>>I/O MMU does not see the device commands containing the sector on
>>>the disk to be accessed, Mostly, CPUs write directly to the CRs
>>>of the device to start a command, bypassing I/O MMU as raw data.
>>
>> That is indeed the case. The IOMMU is on the inbound path
>> from the PCIe controller to the internal bus/mesh structure.
>>
>> Note that there is a translation on the outbound path from
>> the host address space to the PCIe memory space - this is
>> often 1:1, but need not be so. This translation happens
>> in the PCIe controller when creating the a TLP that contains
>> an address before sending the TLP to the endpoint. Take
>
>Is there any reason this cannot happen in the core MMU ??
How do you map the translation table to the device? Why
would you wish to have the CPU translating I/O virtual
addresses? The IOMMU tables are per device, and they
can be configured to map the minimum amount of the address
space (even updated per-I/O if desired) required to support
the completion of an inbound DMA from the device.
>
>Guest OS uses a virtual device address given to it from HV.
>HV sets up the 2nd nesting of translation to translate this
>to "what HostBridge needs" to route commands to device control
>registers. The handoff can be done by spoofing config space
>of having HV simply hand Guest OS a list of devices it can
>discover/configure/use.
The IOMMU only is involved in DMA transactions _initiated_ by
the device, not by the CPUs. They're two completely different
concepts.
>
>> an AHCI controller, for example, where the only device
>> BAR is 32-bits; if a host wants to map the AHCI controller
>> at a 64-bit address, the controller needs to map that 64-bit
>> address window into a 32-bit 3DW TLP to be sent to the endpoint
>> function.
>
>This is one of the reasons My 66000 architecture has a unique
>MMI/O address space--you can setup a 32-bit BAR to put a
>page of control registers in 32-bit address space without
>conflict. {{If I understand correctly}} Core MMU, then,
>translates normal device virtual control register addresses
>such that the request is routed to where the device is looking
>{{which has 32 high order bits zero.}}
Most systems have DRAM located at physical address zero, and
a 4GB DRAM is pretty small these days. So you either need
to make a hole in the DRAM or provide a mapping mechanism to
map a 64-bit address into a 32-bit bar when sending TLPs
to the AHCI controller.
Systems that aren't intel compatible will designate a range
of the 64-bit physical address space (near the top) and will
map regions in that range to the 32-bit bar via translation
registers in the PCIe controller.
>
>On the other hand--it would take a very big system indeed to
>overflow the 32-bit MMI/O space, although ECAM can access
>42-bit device CR MMI/O space.
Leaving aside the small size of the legacy Intel I/O space
(16-bit addresses), history seems to have favored single
address space systems, so I suspect such a MMI/O space will
not be favored by many.
[toc] | [prev] | [next] | [standalone]
Page 16 of 23 — ← Prev page 1 … 14 15 [16] 17 18 … 23 Next page →
Back to top | Article view | comp.arch
csiph-web