Path: ...!eternal-september.org!feeder3.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail From: mitchalsup@aol.com (MitchAlsup1) Newsgroups: comp.arch Subject: Re: Stacks, was Segments Date: Thu, 6 Feb 2025 20:49:39 +0000 Organization: Rocksolid Light Message-ID: <4605d2464e8cd7dbe2aa76ef19129ec6@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> <876e9cf6b21da15dc541756be2e24049@www.novabbs.org> <710d0f743fb3204b909114db4429633d@www.novabbs.org> <7y7pP.2$JzO2.1@fx15.iad> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: i2pn2.org; logging-data="3009900"; mail-complaints-to="usenet@i2pn2.org"; posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU"; User-Agent: Rocksolid Light X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71 X-Spam-Checker-Version: SpamAssassin 4.0.0 X-Rslight-Site: $2y$10$DBPITTveCZqUvbDFl9rJbuzYbBgOX7OB3MS28Tr5WeIEcGuFHHCQq Bytes: 5679 Lines: 92 On Thu, 6 Feb 2025 18:51:12 +0000, EricP wrote: > MitchAlsup1 wrote: >> On Thu, 6 Feb 2025 16:41:45 +0000, EricP wrote: ----------------------------------- >> >> 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). In this case, HV needs to know its limitations and not access the device nor the secure memory. Probably by taking the memory out of the pool it "does normal stuff with" and take the device out of its list of accessible devices (at least for a while). > 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? I am thinking more like SR-IOV where HV loans a virtual device to a Guest OS, and Guest OS performs the I/O request, HV and SM are only there to deal with HV page faults and device errors. If a HV page fault occurs (which it will) a pretty secure corner of HV will construct a PTE mapping that/those page[s] only to page the missing page into memory so I/O can proceed. HV will then have to dismantle said mapping after the page arrives to restart device DMA. > 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... Yes, exactly. No normal access to the page, only swap access is allowed--although this can be alleviated by not paging secure memory::then HV just knows nothing about that/those pages until the process terminates where it can put the pages back in the normal pool after cleaning them out.