Sean Halle wrote:

I have to admit that
I didn't get a chance to dive deep enough to get a firm grasp on the
implications of the proposed changes as far as changes to the amount of
state that would be needed to support the upstream kernel on a distro like
Fedora for high performance. It appears at first blush that there would be
no impact.. but there are many subtleties involved.. could you put our
mind at rest about the consequences on logic to implement and especially
impact on number of CSRs (assuming a high performance core and a distro
like Fedora)?

Hi Sean,

I'm afraid I wasn't completely clear on what question you're asking.
Is your baseline case a Fedora OS that doesn't configure PMP? I don't
know the current behavior of Fedora, but it's certainly possible it
doesn't use PMP to date. If that's the case, the number of PMP entries
your system would need per hart is obviously minimized, possibly zero.
That said, your existing hardware may implement some number of PMP
entries anyway, and I would not know what that number is, for purposes
of comparison. So I think there are yet too many unknowns in this
question for me to try to answer.

In terms of the cost of my proposal for four security levels versus
the task group's working proposal, it's impossible to give any exact
numbers without an actual implementation, but I can suggest some
ballpark estimates. First, there is a cost per PMP entry of one
flip-flop (definitely) and perhaps a dozen additional gates. Add to
that another maybe two dozen gates shared by all PMP entries; how many
gates, I'm not sure. Altogether that should be relatively small
on a per-PMP-entry basis. By far, the most expensive parts of a PMP
implementation have got to be the address CSRs and the checking for
address matches, both of which are unchanged by any of these security
enhancement proposals, either the working proposal or mine.

With my proposal, some systems might need fewer PMP entries than with
the working proposal, which could be a net hardware savings if fewer
entries are actually implemented. Such (potential) savings would be
very much software-dependent.

Regards,

- John Hauser