Path: ...!eternal-september.org!feeder3.eternal-september.org!i2pn.org!i2pn2.org!.POSTED!not-for-mail From: mitchalsup@aol.com (MitchAlsup1) Newsgroups: comp.arch Subject: Re: Stacks, was Segments Date: Wed, 5 Feb 2025 23:36:58 +0000 Organization: Rocksolid Light Message-ID: <876e9cf6b21da15dc541756be2e24049@www.novabbs.org> References: <04876fc002ab019a74c78113a36622f3@www.novabbs.org> <20250120125537.000075e0@yahoo.com> <43e21bd0bddea1733cd672c07a6319d4@www.novabbs.org> <4813354ce36072fc01ed5da902d798f6@www.novabbs.org> <0IboP.166940$V9s2.82811@fx34.iad> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: i2pn2.org; logging-data="2874462"; mail-complaints-to="usenet@i2pn2.org"; posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU"; User-Agent: Rocksolid Light X-Spam-Checker-Version: SpamAssassin 4.0.0 X-Rslight-Site: $2y$10$C1wI3I3irHQ2LPXWW1BeX.eGmXdRPbUVnI9/u/M2XYuVPxwsnrIT2 X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71 Bytes: 4221 Lines: 75 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.