|
Re: Shadow Stack and Landing Pad (SSLP) 14 day peer review. - Clarification
Georgios Christou
We would like to restate that this is a peer review, not public.
toggle quoted message
Show quoted text
Thanks, George, Ved On 27/3/23 17:07, gchri wrote:
Dear all, |
|
|
|
|
|
Shadow Stack and Landing Pad (SSLP) 14 day public review.
Georgios Christou
Dear all,
With the following mail we would like to ask for a 2 week public review on the proposed Shadow Stack and Landing Pads (SSLP) specification. You can find the specification document on GitHub (https://github.com/riscv/riscv-cfi). Please use the GitHub issues for the comments and questions. Kind regards, George, Ved |
|
|
|
|
|
Re: Are page walks required to snoop the D-cache?
andrew@...
On Thu, Mar 23, 2023 at 4:34 AM Peter Vrabel <Peter.Vrabel@...> wrote:
It is indeed valid for the page-table walker not to observe stores that have occurred since the last SFENCE.VMA instruction.
That thread is 4.5 years old, and the RISC-V Linux kernel port has changed quite a bit since then; the information there might be stale.
|
|
|
|
|
|
Are page walks required to snoop the D-cache?
Peter Vrabel
Hi All, Suppose a hart executes a store to create a new PTE, and then that hart executes a SINVAL.VMA with rs1 and rs2 set so as to affect the address of that PTE. Are subsequent page walks guaranteed to observe that PTE write? I believe the answer is no because the SINVAL.VMA only guarantees that the TLBs are invalidated, and does not guarantee that the PTE write is observed by the implicit reads triggered by the memory translation. I believe that an SFENCE.VMA with rs1 and rs2 set correctly is necessary to guarantee that the PTE write is observed. |
|
|
|
|
|
Re: [RISC-V][sig-runtime-integrity] [sig-trusted-computing] [RISC-V] [security] 2-3 day security f2f in the last week of April.
Hi Nick, yes on both - we will plan to end by mid-afternoon on Thursday. Also keeping a zoom call on the 2nd and 3rd day morning (pacific) sounds like a good idea to summarize the previous day and continue. thanks, Ravi On Mon, Mar 20, 2023 at 7:48 AM Nicholas Wood <Nicholas.Wood@...> wrote:
|
|
|
|
|
|
Re: [sig-trusted-computing] [RISC-V] [security] 2-3 day security f2f in the last week of April.
Nicholas Wood <Nicholas.Wood@...>
Thanks Ravi,
I think morning (Pacific time) zoom update calls (one hour?) on the Wednesday and Thursday is probably more social for most people? Than the proposed end of day call (Pacific time).
Can we plan to finish by mid-day on the Thursday?
From: sig-trusted-computing@... <sig-trusted-computing@...>
On Behalf Of Ravi Sahita
Sent: Saturday, March 18, 2023 12:02 AM To: RISC-V Security HC <security@...>; sig-trusted-computing@...; sig-runtime-integrity@...; tech-privileged@...; privileged-software@...; Stephano Cetola <stephano@...> Subject: [EXTERNAL] Re: [sig-trusted-computing] [RISC-V] [security] 2-3 day security f2f in the last week of April.
Hi,
The days that work for most folks per the poll are: April 25-27 (inclusive). Folks should arrange their travel plans accordingly.
The f2f will be in a meeting room on the 1st floor of the Rivos office in Mountain View (331 Fairchild Dr, Mountain View, CA 94043). The agenda is listed below for your feedback/edits/additions; materials, draft proposals to be reviewed before the meeting - see discussions on the Security model, AP-TEE, Smmtt, M-mode isolation etc.
*IO Domain isolation framework
* Caching and TLB considerations
Thanks, Ravi, Andy
On Wed, Mar 15, 2023 at 4:35 PM Ravi Sahita via lists.riscv.org [lists.riscv.org] <ravi=rivosinc.com@...> wrote:
|
|
|
|
|
|
ARC (Architecture Review Committee) minutes for the week of 3/14/23
Greg Favor
Note that there will not be an ARC meeting next week (and hence no minutes will appear). |
|
|
|
|
|
Draft of: ARC (Architecture Review Committee) minutes for the week of 3/14/23
Greg Favor
Note that there will not be an ARC meeting next week (and hence no minutes will appear). |
|
|
|
|
|
Re: [RISC-V] [security] 2-3 day security f2f in the last week of April.
Hi, Following up from the discussion at the Security HC this week - we discussed the pros of conducting a f2f for the mem isolation topic and there was general consensus to go ahead with it. The days that work for most folks per the poll are: April 25-27 (inclusive). Folks should arrange their travel plans accordingly. We discussed the meeting format to make it easier for people who may not be able to attend physically to sync up on the discussions and progress - - Allow remote folks to listen in during the day (Note we will be whiteboarding so it will be listen only for remote participants). - Arrange a zoom call at the end of each day to allow for remote interaction and summarize the key-points of the day. - Send out notes and follow up AIs after the f2f to the list. The f2f will be in a meeting room on the 1st floor of the Rivos office in Mountain View (331 Fairchild Dr, Mountain View, CA 94043). The agenda is listed below for your feedback/edits/additions; materials, draft proposals to be reviewed before the meeting - see discussions on the Security model, AP-TEE, Smmtt, M-mode isolation etc. Agenda: *Memory isolation sub-topics: - Canonical use cases - Semantics of assignment/ownership - Lookup (hardware) - Programming Interface - ISA support needed - Role of software (impact on ABI)*IO Domain isolation framework - Interaction with MMU, IOMMU, xPMP, IOPMP* Caching and TLB considerations * SOC infra, Platform implications * Extensibility Thanks, Ravi, Andy
|
|
|
|
|
|
Architecture Review Committee meeting minutes, 2023-03-07
andrew@...
We discussed a proposal for compressed variants of a subset of the CFI instructions and recommend pursuing it. (This proposal hasn't been written down yet; we will do so soon and will promptly circulate it.) We discussed the pointer-masking proposal again and debated how best to control whether access to this feature is enabled at each privilege mode, but we did not come to a conclusion. We will reach out to the TG to further discuss this topic. Much of this week's ARC meeting was spent discussing the most recent vector crypto spec. We are happy that it is quickly converging. We provided several comments to the TG: - Regarding the Zvkt extension, we wondered why the shift instructions aren't DVIT in their shift-amount arguments. Perhaps it is the case that existing algorithms don't care, but we wonder whether this assumption will hold in the long run. Note also that the scalar shift instructions are DVIT in their shift-amount arguments. - Also regarding Zvkt, we agreed with the proposal that most vector instructions should not be DVIT in their mask argument, as this facilitates density-time implementations. However, we suggest that the vmerge instructions be an exception to this rule, i.e., they _are_ DVIT in their mask argument. This scheme would preserve most of the benefit of the proposal while providing an escape hatch to support DVIT processing of vector conditionals. - We observe that Zvkb contains the bulk of what could be a robust, general vector bit-manipulation extension. We think it would be best to take this opportunity to convert Zvkb into "Zvbb", which will reduce the number of combinations of extensions that need to be supported while not materially burdening implementations. To that end, we recommend renaming the extension to Zvbb and adding the following instructions: - vwsll.{vv, vx, vi}, widening shift left logical. funct6=110101, funct3={000, 100, 011}, respectively. SEW=8..(ELEN/2); result EEW=2*SEW. Shift amount is taken mod lg(2*SEW). - vrev.v, reverse bits within elements. funct6=010010, funct3=010, vs1=01001. SEW=8..ELEN; result EEW=SEW. (We note that when SEW=8 this instruction is redundant with vbrev8.v; so be it.) - vclz.v, count leading zeros within elements. funct6=010010, funct3=010, vs1=01100. SEW=8..ELEN; result EEW=SEW. The result for zero-valued inputs is the value SEW. - vctz.v, count trailing zeros within elements. funct6=010010, funct3=010, vs1=01101. SEW=8..ELEN; result EEW=SEW. - vcpop.v, count bits set within elements. funct6=010010, funct3=010, vs1=01110. SEW=8..ELEN; result EEW=SEW. - We suggest that all instructions in Zvbb be included in the Zvkt set. - We suggest renaming vbrev8.v to vrevb.v, which is more consistent with Claire Wolf's original proposal and with the new vrev.v instruction. - We think the carryless multiplication instructions should be broken out into their own extension (Zvbc), rather than included in Zvbb, for the same reason this was done in the scalar bit-manipulation extensions. - It is mentioned that Zvknhb requires more than Zve32x, but it is not mentioned what _is_ required. We suggest changing this sentence to say that Zve64x is required (which implies that Zve32x is insufficient, so that part can go unstated). - We recommend that the vector crypto element group instructions be changed to state that use of vl that isn't divisible by EGS be reserved, rather than mandating an illegal-instruction exception. Removal of this mandate simplifies some microarchitectures. Raising the exception is, of course, still permitted. (The draft element groups spec, which was never frozen, will also be updated to be consistent with this recommendation. |
|
|
|
|
|
Re: [sig-trusted-computing] [RISC-V][sig-runtime-integrity] 2-3 day security f2f in the last week of April.
James Ball
Given that we are all architects, how about we first agree on the problem we are trying solve before debating potential solutions? Ravi, what problem(s) are you trying to solve? I'm guessing its something like RVI isn't making progress quickly enough for Rivos and/or others involved. If that's the problem, I tend to agree because I see a big gap on security features between RISC-V and competing ISAs and they are a moving target.
toggle quoted message
Show quoted text
+james+ -----Original Message-----
From: sig-trusted-computing@... <sig-trusted-computing@...> On Behalf Of mick@... Sent: Monday, March 13, 2023 7:35 PM To: sig-runtime-integrity@...; RISC-V Security HC <security@...>; tech-privileged@...; sig-trusted-computing@...; privileged-software@...; mark <markhimelstein@...>; Stephano Cetola <stephano@...> Subject: Re: [sig-trusted-computing] [RISC-V][sig-runtime-integrity] 2-3 day security f2f in the last week of April. WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hello Ravi, It won't be easy for many of us to come to such an event that's focused solely on security and is not a public RISC-V event, or let's say an event large enough that our companies/organizations will be willing to support, both in terms of traveling expences and time off from our other duties. Also the proposed days are a month and a half from now and there is no agenda, no format, no venue, nothing we can work with. We can't just go to our companies/organizations one month before the event with that and ask for permission to join, it's even harder for community members and individuals to arrange their schedule in such short notice. I agree we need a f2f meeting sooner than the RISC-V Summit at the end of the year, we used to have the RISC-V Workshop a couple of years back in Europe and we are trying to bring it back with the European RISC-V Summit -> https://riscv-europe.org/. I suggest we organize a f2f meeting there, if one day is not enough we can arrange something on the side, in any case it'll be easier for people to join. It'll be on June 5 - 9 so we'll have 4 days and we can easily do something during the weekend as well. Waiting another month shouldn't be that much of a problem, in fact it'll be easier for most people to make the appropriate arrangements until then. I'd also like to point out that although meeting on the side can be very productive, it shouldn't become the norm. We should be as inclusive as possible and use the mailing list if the weekly meetings are not enough. We have two hours a week (and an extra hour bi-weekly for the Security HC) where most people try to join, do we really need extra private meetings on the side ? It's not easy for the rest of the team to participate when we bring whole "packages" for discussion, we should start with something basic and build on top of it as a team. I'm seeing more presentations than actual discussion in our calls, and the role of the TGs/SIGs is much more than approving proposals, it's writing proposals together as a team. I understand that the whole discussion around the security model and domain isolation etc is complicated and that it's easier to make progress with fewer people, but that's why we have a task group for that (the security model tg), if more calls are needed then at least let's make them public so that more people can join, even if it means they'll only act as spectators. Regards, Nick On 3/9/23 21:04, Ravi Sahita wrote: Greetings, |
|
|
|
|
|
Re: [RISC-V][sig-runtime-integrity] 2-3 day security f2f in the last week of April.
mick@...
Hello Ravi,
toggle quoted message
Show quoted text
It won't be easy for many of us to come to such an event that's focused solely on security and is not a public RISC-V event, or let's say an event large enough that our companies/organizations will be willing to support, both in terms of traveling expences and time off from our other duties. Also the proposed days are a month and a half from now and there is no agenda, no format, no venue, nothing we can work with. We can't just go to our companies/organizations one month before the event with that and ask for permission to join, it's even harder for community members and individuals to arrange their schedule in such short notice. I agree we need a f2f meeting sooner than the RISC-V Summit at the end of the year, we used to have the RISC-V Workshop a couple of years back in Europe and we are trying to bring it back with the European RISC-V Summit -> https://riscv-europe.org/. I suggest we organize a f2f meeting there, if one day is not enough we can arrange something on the side, in any case it'll be easier for people to join. It'll be on June 5 - 9 so we'll have 4 days and we can easily do something during the weekend as well. Waiting another month shouldn't be that much of a problem, in fact it'll be easier for most people to make the appropriate arrangements until then. I'd also like to point out that although meeting on the side can be very productive, it shouldn't become the norm. We should be as inclusive as possible and use the mailing list if the weekly meetings are not enough. We have two hours a week (and an extra hour bi-weekly for the Security HC) where most people try to join, do we really need extra private meetings on the side ? It's not easy for the rest of the team to participate when we bring whole "packages" for discussion, we should start with something basic and build on top of it as a team. I'm seeing more presentations than actual discussion in our calls, and the role of the TGs/SIGs is much more than approving proposals, it's writing proposals together as a team. I understand that the whole discussion around the security model and domain isolation etc is complicated and that it's easier to make progress with fewer people, but that's why we have a task group for that (the security model tg), if more calls are needed then at least let's make them public so that more people can join, even if it means they'll only act as spectators. Regards, Nick On 3/9/23 21:04, Ravi Sahita wrote:
Greetings, |
|
|
|
|
|
Draft writeup of proposed Memory Ownership PMA (Smmtt)
Hi Priv TG, thanks, Ravi
|
|
|
|
|
|
Re: [RISC-V][sig-runtime-integrity] 2-3 day security f2f in the last week of April.
Nicholas Wood <Nicholas.Wood@...>
Thanks Ravi,
Is this on the agenda for the TC SIG or Security HC this week?
Agree it makes sense with focussed meetings on these topics – isolation model, device management model, interoperability with TZ/WG, and so on.
Probably would be useful as a kick-off for M-mode isolation as well.
Only caveat might be that intercontinental travel might be difficult to justify “just” for an RVI working meet. But also agree a f2f would be efficient in this case. I guess it depends on what the agenda might look like.
From: sig-runtime-integrity@... <sig-runtime-integrity@...>
On Behalf Of Ravi Sahita
Sent: Thursday, March 9, 2023 7:05 PM To: RISC-V Security HC <security@...>; tech-privileged@...; sig-trusted-computing@...; sig-runtime-integrity@...; privileged-software@...; mark <markhimelstein@...>; Stephano Cetola <stephano@...> Subject: [EXTERNAL] [RISC-V][sig-runtime-integrity] 2-3 day security f2f in the last week of April.
Greetings,
As active participants in the Security HC know, recently we have been discussing the security model for RISC-V with a focus on (domain) isolation framework. A lot of us have been meeting in extra working meetings to make progress on that topic. As a group, we think that it makes sense to have a Security f2f to be able to focus discussion on memory isolation capabilities and the required ISA building blocks.
To do that, we are planning a 2-3 day security f2f for this topic in the last week of April (in the week of 24 - 28). I wanted to invite folks actively working on this topic to join that session. It would be good if you can share your intent to attend f2f and 2-3 days that work via this doodle poll: https://doodle.com/meeting/participate/id/dLZx0xAa [doodle.com] - we will select a 2-3 day slot that works for most folks by next week's HC meeting.
The venue is TBD but expected to be in the bay area, California, USA - we plan to select some hotel conference room location. We expect a subset of folks from the Security HC, Priv IC and Priv Software to participate. We also expect this to be a working f2f meeting so live participation would be best for contributing, white boarding etc. As with any RVI meeting, we expect to share the summary of outcomes. Any feedback on making the planned f2f more effective is welcome.
Thanks, Ravi, Andy
|
|
|
|
|
|
2-3 day security f2f in the last week of April.
Greetings, As active participants in the Security HC know, recently we have been discussing the security model for RISC-V with a focus on (domain) isolation framework. A lot of us have been meeting in extra working meetings to make progress on that topic. As a group, we think that it makes sense to have a Security f2f to be able to focus discussion on memory isolation capabilities and the required ISA building blocks. To do that, we are planning a 2-3 day security f2f for this topic in the last week of April (in the week of 24 - 28). I wanted to invite folks actively working on this topic to join that session. It would be good if you can share your intent to attend f2f and 2-3 days that work via this doodle poll: https://doodle.com/meeting/participate/id/dLZx0xAa - we will select a 2-3 day slot that works for most folks by next week's HC meeting. The venue is TBD but expected to be in the bay area, California, USA - we plan to select some hotel conference room location. We expect a subset of folks from the Security HC, Priv IC and Priv Software to participate. We also expect this to be a working f2f meeting so live participation would be best for contributing, white boarding etc. As with any RVI meeting, we expect to share the summary of outcomes. Any feedback on making the planned f2f more effective is welcome. Thanks, Ravi, Andy |
|
|
|
|
|
Architecture Review Committee meeting minutes, 2023-02-28
Earl Killian
Overview
Most of the 2023-02-28 Architecture Review Committee (ARC) discussion concerned the Pointer Masking proposal. This was followed by a brief update on Zimops for CFI, and generalizing the AIA indirect CSR feature for use with counters. Pointer Masking (Zjpm* or just PM herein) Note: There have already been changes to the Pointer Masking proposal since the version some of the ARC reviewed. There was a discussion that the HLD etc. instructions should respect the PM of the mode that they are operating upon. There is a comment in the proposal about Zcmt that misunderstands that extension. Jump table accesses should be characterized as instruction accesses. We are concerned that PM should not change some basic operating system interfaces. In particular, the OS should not have to change its address space check, which is currently based on bit 63. We propose that bit 63 therefore be a copy of bit 38, 47, or 56 for Sv39, Sv48, and Sv57 respectively and that the hardware continue to check this in PM mode. We realize this leaves only 6 bits for Sv57, but we don’t think this feature is likely to be needed for Sv57 processes. For the same reason, the value that shows up in *tval registers (e.g. stval) should be the transformed address, not the effective address. This means that the page fault code need not be aware of the PM setting. There was a statement in the proposal about misaligned accesses that is not entirely correct. In any case, the ARC believes the PM spec should work the same whether misaligned accesses are handled in hw, or emulated in a trap handler that is not aware of PM. The proposal does not justify the use case for Zjpminst, and there was a point raised that this case should continue to be handled in software (e.g. by having sw remove the tag with two shifts) prior to JALR instructions. It is not expected that this as performance critical as load/store instructions. Zjpminst was also underspecified, and it is unclear what was intended. In some possible definitions of Zjpminst, the PC would have to be extended, which is considered a hardware cost that requires justification, and this would affect JALR and EPC values.. Also we suggest that Zjpminst be addressed in a future extension when the use case is clear and things like JALR and EPC requirements are developed. Much of the discussion of PM was about how to cleanly separate the Unpriv and Priv portions, and the misidentification of User mode with Unpriv. In the end the ARC tabled discussion of User-mode vs. Unpriv for a later date, but noted that to incorporate PM into the unpriv spec will require some rewrites. For example, Zjpm (an Unpriv spec by its very name) cannot refer to Sv{39,48,57}, which are priv spec concepts. The number of bits available to PM is in the unpriv space can only reference the execution environment. Also, Unpriv conformant code can run on implementations that lack a user mode, and there is an open/tabled question about whether including “User” in CSR names is appropriate. The ARC identified a virtualization hole in the definition of some of the CSRs. In particular, ignoring writes under a setting by a higher privilege level makes emulation impossible, and it is proposed that writes that are not allowed must trap. There was a discussion about how to minimize the cost of context switch overhead for what might be a single bit. When the PM proposal is further developed, the ARC proposes to work with the TG to find a home that minimizes the OS overhead (e.g. sstatus or something similar). Zimops The Control Flow Integrity (CFI) group has indicated they want the option of making the shadow-stack be the only return address stack, which would require a new ABI. There are issues with providing compressed instructions for both this purpose and for the shadow stack checking addition, and so the ARC proposes that only the shadow checking instructions would be have compressed format Zimops definitions, and the new ABI would need to use new non-Zimops instructions. Indirect CSRs It was concluded that the AIA indirect register feature should move into priv spec and be made usable for counters by generalizing it using three window registers. |
|
|
|
|
|
Re: Htval value when guest page fault occurs
Oscar Jupp
Thank you all for your response! That make much sense to me and what I am about to do. Best regards, Oscar Allen Baum <allen.baum@...> 于2023年3月4日周六 02:23写道：
|
|
|
|
|
|
Seeking reviewers for RISC-V System-on-Chip Design textbook
Colleagues,
James Stine, Ross Thompson, Sarah Harris, and I are writing a textbook on RISC-V System-on-Chip Design, to be published by Elsevier in 2024. It is written around an open-source configurable RISC-V processor hosted by OpenHW Group. We are looking for folks knowledgable about RISC-V design to review the manuscript. Please let me know if you would be interested. Prof. David Harris Harvey Mudd College |
|
|
|
|
|
Re: Htval value when guest page fault occurs
Ah,yes, as John just posted, by this as well
On Fri, Mar 3, 2023 at 10:21 AM Allen Baum via lists.riscv.org <allen.baum=esperantotech.com@...> wrote:
|
|
|
|
|
|
Re: Htval value when guest page fault occurs
Basically, the option to load xtval or mtval2 (or not) on any specific exception is a (currently) unnamed architectural option. There is no way (currently) to discover this without either - trying to execute something that triggers the trap and see if the data appears, or - a manufacturers assertion that it does or doesn't (which might be --embedded in a Device Tree, or --described by the manufacturers riscv-config YAML file in their ricsv-arch-test-reports repo) or eventually -- through the unified discovery extension. Note that there are upcoming profiles that require the option to load them for most trap causes:.
On Fri, Mar 3, 2023 at 5:27 AM mark <markhimelstein@...> wrote:
|
|
|
|
