tech-privileged@lists.riscv.org

Home Messages Hashtags Subgroups

Messages

Between

and

Re: [tech-privileged] hypervisor extension: seL4 experience and feedback

Yea, I remember Non-Stop folks explaining how they were going to considerably simplify their implementation by not relying on lockstep, but instead relying on counting retired instructions. But they

By Allen Baum · #74 ·

Re: [tech-privileged] hypervisor extension: seL4 experience and feedback

Let me withdraw the part about RDTSC - I confused RISC-V RDCYCLE and RDTSC. However, my point about people using instruction retired count in real life for real functionality remains.

By Andy Glew Si5 · #73 ·

Re: [tech-privileged] hypervisor extension: seL4 experience and feedback

Intel's RDTSC is used not just for performance measurements, but also as timestamps, not just for databases, but also for enough generic Linux code that Intel was forced to ensure that RDTSC was

By Andy Glew Si5 · #72 ·

Re: Huawei review of different PMP enhancement schemes

John Hauser wrote: I don't understand how having extra bit patterns for the PMP config registers compromise security. Isn't it pretty much a given that the values loaded into the PMP address registers

By Jonathan Behrens <behrensj@...> · #71 ·

Re: Huawei review of different PMP enhancement schemes

Nick Kossifidis wrote: I agree that would be dangerous, but I intentionally excluded that possibility, so I don't understand. What is the exact encoding that you think allows this, when MSL >

By John Hauser · #70 ·

Re: Huawei review of different PMP enhancement schemes

Some thoughts on the various proposals on the spreadsheet (v0.3): M&L proposal: The purpose of M bit is not clear, I get that the idea is to be able to mark a rule that applies to M mode without

By mick@... · #69 ·

Re: [tech-privileged] hypervisor extension: seL4 experience and feedback

Hi Gernot and Yanyan, It's been a couple of months since you first sent (Dec. 4) your document reporting your experience adapting the seL4 microkernel to draft 0.4 of the RISC-V hypervisor extension,

By John Hauser · #68 ·

Re: [RISC-V] [tech-tee] [RISC-V] [tech-privileged] Huawei review of different PMP enhancement schemes

Ø why don't you instead simply not program any lock bits until you get to the point that you would have changed DPL from 1->0? Because we can’t program the permissions we need without locking

By Mr Tariq Kurd <tariq.kurd@...> · #67 ·

Re: Huawei review of different PMP enhancement schemes

Just as I have been asking why DMC is necessary, I have to ask why the DPL bit is necessary. If there is code that wants to reorder PMP entries while DPL is 1, but the lock bits are set - why don't

By Allen Baum · #66 ·

Re: Huawei review of different PMP enhancement schemes

Tariq Kurd wrote: Hi Tariq, I meant for the encodings with W = 1 and R = 0 to continue to be reserved, as the spreadsheet indicates, but you're right that I forgot to say so in my document. I have a

By John Hauser · #65 ·

Re: comments on PMP enhancements

It is just one extra bit if its combined with an existing CSR, otherwise its extra decoding, scan and DVT logic, (not to mention extra readmux and write enable, regardless of whether its merged into

By Allen Baum · #64 ·

Huawei review of different PMP enhancement schemes

Hi everyone, We have spent a considerable amount of time reviewing the different proposals and have come to some conclusions. 1. The PMP enhancement proposal can meet our needs with the

By Mr Tariq Kurd <tariq.kurd@...> · #63 ·

Re: comments on PMP enhancements

Hi Allen, The point I was trying to make about locked PMP entries, but failed to communicate before, is this: When a system starts up after reset, PMP is enforced according to a certain set of

By John Hauser · #62 ·

Re: [RISC-V] [tech-tee] [RISC-V] [tech-privileged] comments on PMP enhancements

Yes, the reason I labelled it separate M&L was because the existing "legacy" proposal essentially combines the functionality into a single "L" bit. > But: if an entry is created (necessarily by

By Allen Baum · #61 ·

Re: [RISC-V] [tech-tee] [RISC-V] [tech-privileged] comments on PMP enhancements

Hi Tariq, all, After a rethink, I actually think that the restriction imposed by lock is a good feature to security. For example, in your use case that BR wants to lockdown its sub-regions one by

By Joe Xie · #60 ·

Re: How can M mode emulate instructions if it is locked down?

Hi Andy, M-mode can use mstatus.mprv to access S/U-mode memory regions, provided that S/U-mode has read access to them. If any non-readable regions are configured then trap-and-emulate won't be

By Jonathan Behrens <behrensj@...> · #59 ·

How can M mode emulate instructions if it is locked down?

Creating a new thread, for a new topic, although I'm excerpting some old email as inspiration. Anyway: Andrew Waterman tells me that 1 of the big purposes of M-mode is to emulate instructions. For

By Andy Glew Si5 · #58 ·

Re: comments on PMP enhancements

I wrote: Allen Baum: By the "M & L proposal" I meant Tariq Kurd's proposal, the one I was speaking of. (On your own cheat sheet from yesterday, the tab for this proposal is labeled "sep_M&L". But I

By John Hauser · #57 ·

Re: comments on PMP enhancements

I wrote: Allen Baum: Sorry, I meant that, under the existing standard, locked PMP entries are intended to deny some or all accesses from M mode to a memory region. The RISC-V standard says, "In

By John Hauser · #56 ·

Re: comments on PMP enhancements

Jonathan Behrens wrote: Because the PMP table is explicitly searched in order for a match, locked entries must always be at the head of the table to be truly effective. When software wants to add a

By John Hauser · #55 ·

1261 - 1280 of 1334

Home Hashtags Subgroups Terms