RISC-V Security Analysis Paper / Talk

[Don A. Bailey]

Hi All,

I have developed a security analysis of the current RISC-V architecture and public implementations. I'll release the paper at the Hack In The Box security conference this April, where I'll present my findings to the public. 

My interest is to identify areas of risk and develop remediation and mitigation strategies with RISC-V working groups. I believe that RISC-V is an exciting and innovative technology that could have a significant impact on risk reduction in consumer and industrial computing, and I hope that my findings can, even in some small way, assist with this. 

In the meantime, I'd love to hear from you if you have found or believe there may be issues of security in either the ISA or a particular implementation. I'd be glad to review your concerns and add them (cited) to the white paper to ensure these issues are, at the least, vocalized and investigated. This doesn't only apply to the RISC-V ISA or a particular processor, but:

 - Kernels on RISC-V (what security features are or are not implemented) 

 - Compiler support for modern security options

 - Library support

 - Firmware implementation issues

 - Debug toolchain issues of privilege

Thank you,

Don A. Bailey

Founder / CEO

Lab Mouse Security

@InfoSecMouse

https://www.securitymouse.com/

[Ray Van De Walker]

I think there’s a need for several items:

1.       A secured RISC-V needs a security state machine. The state should be reliably available to all levels, so the software can behave responsibly. S levels and above need a way to report a breach. I think the state machine should be application-dependent, except maybe the sign bit is clear for insecure states (or something).

2.       If RISC-V adds significant security features, over time it’s likely to grow into an entire security module, feature-by-feature, maybe in H-level BMIs. I’d hide the whole thing now, behind a single BMI call with a function code to select APIs. Make the upper half of function codes application-defined. The bottom half can be standardized, RFU for now. Maybe make function code 0 the way to test if a function code is implemented. Or something.

3.       The debug unit needs some standard form of lightweight, firmware-controlled security.  If it is controlled by firmware, then it can integrate with any security system, and adding passwords, challenge-response and crypto security is possible, maybe without turning the spec, IP or (possibly) silicon.   An exact scheme would be something like: reset disabled to prevent reset-timing attacks, then enable automatically after some number of instructions (e.g. 4096), unless the firmware configures debug to be disabled.  I think it should have the option to have the firmware disable it until the next reset (prevents software breaches), or disable it until enabled (permits complex debug authorization).

4.       The RISC-V privileged register set desperately needs a software watchdog.  (It’s transcendentally weird to see a NMI without a watchdog.) It’s useful for security, safety, reliability and EMI recovery. For security because it can set the security interval. I think the default time should be about 1.5 seconds. I think the choice of starting enabled or disabled should be by a trim, because applications have legitimately different requirements. (All of my applications at work need to start with a watchdog enabled.)

5.       I think secure boots should be simple (banks and government need them), and insecure operation should be possible (a civil right), with reliable notification of the insecurity (e.g. by a security-state inquiry), so secured apps can run responsibly.

6.       Affordable (cheap) IoT RISC-V CPUs running out of (slow) flash are going to be slow at running intensive things like ECC authentications.   A standardized crypto coprocessor interface in the BMI would be helpful. At this stage, an RFU would be enough. Any preexisting coprocessor interface is fine, BTW.

7.       Hardware random-number-generators are useful for small slow systems. They don’t have access to much entropy. A standardized BMI or even a register would be helpful. Cheap ones tend to be nondeterministic, so a data-ready interrupt is truly helpful.

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAFkuX4uFVDfYnFM5i06-QF-Dc8-XN07RvpcCmFLOUdDov68nAA%40mail.gmail.com.

[Jacob Bachmeyer]

Ray Van De Walker wrote:
>
> 3. The debug unit needs some standard form of lightweight,
> firmware-controlled security. If it is controlled by firmware, then
> it can integrate with any security system, and adding passwords,
> challenge-response and crypto security is possible, maybe without
> turning the spec, IP or (possibly) silicon. An exact scheme would be
> something like: reset disabled to prevent reset-timing attacks, then
> enable automatically after some number of instructions (e.g. 4096),
> unless the firmware configures debug to be disabled. I think it
> should have the option to have the firmware disable it until the next
> reset (prevents software breaches), or disable it until enabled
> (permits complex debug authorization).
>

I have been thinking about this, since the "RISC-V general purpose
system" proposal I have been planning includes a diagnostic interface
(standard label "RVDIAG" with a standard connector and pinout) with
significant power. (It would be a standardized "firmware unbrick" port
with full DMA capabilities at debug-mode privilege, among other uses.)
To protect against attacks, I was planning to propose that RVDIAG would
only be enabled if a diagnostic pad is connected at power-on. Hardware
would be expected to enforce zeroing RAM when powering up with RVDIAG
active (to prevent "cold boot" attacks--connect diagnostic pad to
running machine and cycle power, then dump memory and look for secrets).

> 5. I think secure boots should be simple (banks and government
> need them), and insecure operation should be possible (a civil right),
> with reliable notification of the insecurity (e.g. by a security-state
> inquiry), so secured apps can run responsibly.
>

I suggest looking at this from a different perspective--what matters is
not the difficulty of loading "some other program" but the ability for
the owner of the machine, with physical access, to determine with
absolute certainty what was actually loaded and is running. This is
something often omitted in "secure boot" models that I have seen (like
UEFI), yet is fundamentally what (to use your examples) banks and
governments need.

In other words, focus on integrity verification, rather than on signed
code. The rough boot outline (for "PC-like" hardware and up) I have
is: (1) power-on-reset, (2) service processor starts with a standard
init0 image running from a small internal mask ROM, (3) init0 checks if
service-network-link1 is up, if not, service-network-link1 is disabled
until the next power cycle (the processor that is connected to the
RVDIAG port is required to have RVDIAG on link1; other processors in an
SMP system are required to use link1 to connect "towards" the processor
that is connected to the RVDIAG port), (4) init0 checks for an SPI flash
chip with a valid header and attempts to load the primary (higher
sequence number) copy of init1 from the SPI chip, falling back to the
backup copy of init1 if the digest does not match the header block in
SPI flash, falling back to "unbrick mode" if that is also invalid or
there is no SPI flash chip connected to "this processor", (5) init0
emits the digest of the loaded init1 on the RVDIAG port (if "simple log
mode" is selected; think send-only UART) and ensures that said digest is
present in the "boot digest log" (a small region of EEPROM inside the
processor module that stores a list of init1 images successfully loaded
and can be read using RVDIAG, but cannot be written once init1 is
started; if you cannot account for every digest in this log, you have a
problem), (6) init0 passes control to init1 in service processor SRAM,
(7) init1 initializes and configures the main processor's DRAM
interface, (8) init1 loads a monitor from SPI flash into main DRAM and
starts the main processor, (9) (implementation option) (a) service
processor shuts down and its SRAM is returned to the main processor's
cache array or (b) service processor continues to do something useful,
(10) (implementation option) inter-processor interrupts and/or TLB
flushes, etc. are sent using the service network rather than using
cycles on the main interconnect that provides cache-coherent memory
access. In an SMP system, only one processor module (the one connected
to the RVDIAG port) is required to have an SPI flash chip attached; the
init1 image is expected to use the unbrick mode of init0 to load itself
into service processor SRAM on other processor modules. (Lacking SPI
flash chips, other processor modules will automatically enter unbrick
mode at power-up.)

This model has one big advantage: there are no critical secrets. The
init1 module can do whatever it wants, including verifying a signature
on the monitor if desired. The init1 module can also be freely
replaced, guaranteeing that civil rights will be respected, at least as
far as "run code of your choice on your computer" is concerned. The
init0 module is in mask ROM, providing a root-of-trust that the reported
digest actually is the digest of the loaded init1. The security of this
model depends only on the inability of an attacker to find collisions
for the digest used. An init1 that enforces code signing can be simply
replaced if the key is compromised.


-- Jacob

[Stefan O'Rear]

On Tue, Jan 10, 2017 at 11:58 AM, Ray Van De Walker
<ray.van...@silergy.com> wrote:
> 1. A secured RISC-V needs a security state machine.

I would very much appreciate it if people would stop using the terms
"secure" and "security". They are so broad as to be effectively
meaningless except in the context of a defined threat model.

> The state should
> be reliably available to all levels, so the software can behave responsibly.

I veto any new functionality which is not Popek-Goldberg
virtualizable. S-mode needs full control over what U-mode sees.

> S levels and above need a way to report a breach. I think the state machine
> should be application-dependent, except maybe the sign bit is clear for
> insecure states (or something).
>
> 2. If RISC-V adds significant security features, over time it’s likely
> to grow into an entire security module, feature-by-feature, maybe in H-level
> BMIs. I’d hide the whole thing now, behind a single BMI call with a function
> code to select APIs. Make the upper half of function codes
> application-defined. The bottom half can be standardized, RFU for now. Maybe
> make function code 0 the way to test if a function code is implemented. Or
> something.

Please keep anti-tamper (secure boot / DRM) mode outside the main
platform and privilege spec. It's inappropriate for many use cases
and we don't know enough to make a 50-year plan for it. Radical
simplicity in the core is how we make this work.

"Cryptographic accelerators" and "hardware which is tamper-resistant
so that the mfg can trust it when the entities with physical access
are assumed hostile" are essentially non-overlapping concepts. They
need to be handled separately, and you're confusing the issues by
using the vague term "security".

> 7. Hardware random-number-generators are useful for small slow
> systems. They don’t have access to much entropy. A standardized BMI or even
> a register would be helpful. Cheap ones tend to be nondeterministic, so a
> data-ready interrupt is truly helpful.

RNGs are a third issue, which is useful in conjunction with
cryptographic accelerators.

Systems which are deployed in hostile environments will generally want
all three of RNGs, cryptoaccelerators, and tamper resistance/evidence,
but they are not the same issue.

-s

[Stefan Wallentowitz]

Hi,

On 10.01.2017 20:58, Ray Van De Walker wrote:

> 5. I think secure boots should be simple (banks and government
> need them), and insecure operation should be possible (a civil right),
> with reliable notification of the insecurity (e.g. by a security-state
> inquiry), so secured apps can run responsibly.

I want to second that, but similar to Stefan O'Rear put the focus on
trusted execution. It becomes more and more available on commodity
devices, mostly implementing the Global Platform Trusted Execution
Environment (TEE) standard. The biggest problem is the deployment of the
trusted anchor and having a standardized way of deploying trusted
applications. Especially the latter goes a bit beyond an ISA or
ecosystem spec. Anyways those are two things that may be of interest for
RISC-V security:

- A standardized way of accessing non-volatile memory. In proprietary
platforms this is under heavy NDA and tends to be very different.

- A practical and open public key management infrastructure that fits
the user needs. The critical part here is how trust is properly
delegated without locking out the end user.

Cheers,
Stefan

[lk...@lkcl.net]

  One of the "perspective" problems with "Trusted Computing Platform" is that the word "trust" is not actually focussed at the user, it's focussed at *not* trusting *any* user (including the owner of the device).  The word "trust" is actually focussed at *Corporate interests*.  "Trust us to make sure we look after YOUR interests" - after all, they've got the money, they drive the sales of devices that can play movies and songs, they want their cut... and they want people to be locked out, right the way to the screen with HDCP.  4k video players now won't even play a film unless you have an *internet* connection for god's sake.

It's therefore no coincidence that the FSF and others refer to TCP as "Treacherous Computing Platform". 

Huge Corporate Media Interests love it.  They *genuinely* believe that by locking the bootloader using e-fuses, RSA-signing the kernel and going from there to control applications and even cause certain types of peripherals to hard-fail and permanently brick themselves (USB portable DVD-RW drives being the most notorious example), is a really, really good idea.

In Intel's case they implemented an entire dedicated back-door processor (under pressure and threat from the NSA that they would not receive export licenses for their products), which became so complicated that of *course* it contained massive security flaws, in particular in things like a (proprietary, of course) SSL engine which, through not receiving proper peer review and audit, of *course* was a total security fail, present and undetected for *years*.  More details on this can be found here:

https://libreboot.org/faq.html#intelme

Then we get into nightmare scenarios where genuine Intel Signing Keys are, I hear, available for sale via underground forums.  Want to run undetectable back-door spying firmware on Whitehouse computers that's impossible to detect with Anti-virus software, anyone?  Thanks to the *NSA*, you can! *face-palm*...

 Several really *really* knowledgeable people (most of them on the "receiving end" in the Software Libre Community because they are the ones who have to do all the reverse-engineering of these "secret" secure systems) can go on and on about this, all giving the exact same warnings: "Trusted" Computing is *NOT* to be trusted.  There's a wonderful phrase which I saw written out in mathematical notation when working for Internet Security Systems, "Security tends to zero as the number of idiots tends to infinity", which is incredibly funny and insightful at the same time.

 So, Don: the bottom line is: as Stefan O'Rear, Stefan Wallentowitz have pointed out, and anyone knowledgeable with the details will be able to confirm: *any* kind of "secure" path from boot through to OS that is not under the direct control and responsibility of the *user* is a recipe for disaster that not only fails to do its intended job due to incompetence and the spiralling complexity of implementing the nebulous over-loaded concept of "security", but results in the user losing the right to own their own hardware, losing the right to the applications of THEIR choice, being spied upon and completely unable to detect it without spending thousands of dollars on specialist equipment or independent researchers, and ultimately causes them to not only fear technology but also to throw it into landfill.

 Now, inevitably some Corporate interests are *going* to try it on.  The RISC-V Foundation *will* be approached relentlessly in various different guises and forms by Corporate Media-Mogul-sponsored interests with a view to getting DRM and Treacherous Computing in via the back door.  They will be easy to spot.  They may even try threats and bribery: this is the American Mafia, after all.  The question thus becomes: whether the RISC-V Foundation wants to be responsible and accountable for *empowering* such ineffective and highly unethical Corporate-driven known-failed strategies, by getting involved in "Standardising" it.

 Even proposals that could allow *users* the freedom to control boot-loader and firmware RSA-signing keys could be abused by such Corporate interests, by instead of allowing the keys to be loaded over removable media as intented, the keys are placed at factory-install time into tamper-resistant on-board processors (see NXP / Freescale offerings such as the iMX7) hard-wired to the PCB with hidden inner-layer tracks that blow e-fuses and *permanently brick the user's legitimately-purchased product*.

 So whilst there do exist genuine and legitimate reasons for wanting to do secure computing (mission-critical safety systems, financial platforms), there's a strong ethical dilemma in play, here, that the RISC-V Foundation has a hard choice to make on where to draw the line, and I don't envy you for being in this position, at all.

l.

[Jacob Bachmeyer]

lk...@lkcl.net wrote:
> [...] Then we get into nightmare scenarios where genuine Intel

> Signing Keys are, I hear, available for sale via underground forums.

> [...]

If true, this illustrates *exactly* my point earlier: *ANY* system that
relies on secrets for its security *will* be compromised in the real
world eventually. Secrets leak.

I advocate that the "root trust anchor" in general-purpose RISC-V
systems be a hardware component or mask-ROM early-init "firmware" module
(inside the processor module) that simply records (and dumps) the digest
of the next-stage startup firmware, then passes control to said firmware
loaded from outboard flash. The user can (and for
banking/government/other-critical-applications is responsible to) verify
the digest of the firmware that was *actually* *used* to boot the
machine. That next-stage image can perform whatever signature
verification is desired, but can also be *verifiably* replaced /in toto/
when its keys are inevitably compromised or the machine changes hands
and the new owner has different keys.

[This adds one small detail to that proposal: each entry in the init1
digest log also needs a will-not-see-this-again flag that can be set, to
allow a new owner to ensure that any collisions an attacker may have for
a previous owner's firmware will be detected when the list is read using
the RVDIAG port and the have-seen-this-again flag is set.]


-- Jacob

[Luke Kenneth Casson Leighton]

On Mon, Apr 23, 2018 at 4:36 AM, Jacob Bachmeyer <jcb6...@gmail.com> wrote:
> lk...@lkcl.net wrote:
>>
>> [...] Then we get into nightmare scenarios where genuine Intel Signing
>> Keys are, I hear, available for sale via underground forums. [...]
>
>
> If true, this illustrates *exactly* my point earlier: *ANY* system that
> relies on secrets for its security *will* be compromised in the real world
> eventually. Secrets leak.

yes.

> I advocate that the "root trust anchor" in general-purpose RISC-V systems be
> a hardware component or mask-ROM early-init "firmware" module (inside the
> processor module)

Unfortunately, the next phase is to create a PCB that physically
locks out access to the RVDIAG port with a tamper-resistant
co-processor where the traces are buried from BGA pads down to inner
layers using blind vias on both the tamper-resistant external
co-processor and the main RISC-V core.

Once that is done the manufacturers are free and clear to abuse the
proposal as a means to implement Treacherous Computing [and also
implement secure financial systems which *are* needed], by extending
the scheme to prevent and prohibit OS code from being chain-loaded and
thus on to prevent and prohibit *applications* from being loaded in
turn.

Even more unfortunateiy, this applies generally: any scheme that is
proposed which is *intended* to provide user freedom of choice and
protection will have a similar uncontrollable fatal flaw at the design
and manufacturing phase *not* the RISC-V Standards phase, and is
consequently outside of the control of the RISC-V Foundation.

Thus, providing such proposals logically and inevitably actually
*empowers* unethical Corporations to achieve their goals of exerting
control over users.

Quoting the 1983 Film War Games [1], "A strange game. The only
winning move is not to play at all".

l.

[1] https://en.wikipedia.org/wiki/WarGames

[Jacob Bachmeyer]

Luke Kenneth Casson Leighton wrote:
> On Mon, Apr 23, 2018 at 4:36 AM, Jacob Bachmeyer <jcb6...@gmail.com> wrote:
>
>> lk...@lkcl.net wrote:
>>
>>> [...] Then we get into nightmare scenarios where genuine Intel Signing
>>> Keys are, I hear, available for sale via underground forums. [...]
>>>
>> If true, this illustrates *exactly* my point earlier: *ANY* system that
>> relies on secrets for its security *will* be compromised in the real world
>> eventually. Secrets leak.
>>
>
> yes.
>
>
>> I advocate that the "root trust anchor" in general-purpose RISC-V systems be
>> a hardware component or mask-ROM early-init "firmware" module (inside the
>> processor module)
>>
>
> Unfortunately, the next phase is to create a PCB that physically
> locks out access to the RVDIAG port with a tamper-resistant
> co-processor where the traces are buried from BGA pads down to inner
> layers using blind vias on both the tamper-resistant external
> co-processor and the main RISC-V core.
>

That would not be a conforming implementation: the standard would
specify a short list of options for the RVDIAG connector and would
mandate (1) the connector *must* be available *and* populated, (2)
*must* be connected *directly* to either the main RISC-V processor or a
nearly-transparent IEEE1355 router (permitted only if the system would
otherwise require multiple RVDIAG ports, which are also permitted) with
a standardized command set that provides *transparent* channels to
anywhere in the RVDIAG service network, (3) *must* have a standard
pin-out with the "RVDIAG" label oriented such as to indicate pin 1 and
located within a defined area near the connector. The short list of
connector options would begin with a simple 2xN .100" pin header and
conforming implementations would be *required* to use the first
connector on the list that they can physically accommodate. Systems
with space constraints (such as laptops) would be permitted to use other
lower-profile options farther down the list. Systems that cannot
accommodate *any* of the RVDIAG connector options (including perhaps a
thin-card-edge connector for tablet form factors) are not eligible for
the "general-purpose RISC-V" logo, even if they use processor modules
that *do* carry the logo.

> Once that is done the manufacturers are free and clear to abuse the
> proposal as a means to implement Treacherous Computing [and also
> implement secure financial systems which *are* needed], by extending
> the scheme to prevent and prohibit OS code from being chain-loaded and
> thus on to prevent and prohibit *applications* from being loaded in
> turn.
>

Such a machine is not general-purpose and would not qualify for the
"general-purpose RISC-V" logo. Building such a system is allowed --
just do not route RVDIAG anywhere at all; init0 can load init1 without
needing input from a diagnostic pad. Even the "simple digest dump" mode
uses fewer wires than the full RVDIAG, so a unidirectional output is
allowed. The RVDIAG port is basically "root" at the monitor level,
which is why it requires physical access; systems that cannot tolerate
such a port are not general-purpose anyway.

> Even more unfortunateiy, this applies generally: any scheme that is
> proposed which is *intended* to provide user freedom of choice and
> protection will have a similar uncontrollable fatal flaw at the design
> and manufacturing phase *not* the RISC-V Standards phase, and is
> consequently outside of the control of the RISC-V Foundation.
>

The solution is easy and is part of providing the incentive for
processors to support the scheme: for an overall system to carry the
"general-purpose RISC-V" logo, the RVDIAG interface must be available as
intended. Integrating a "special" diagnostic pad is *not* a
general-purpose system. The Foundation would retain veto power over
such misuse of the logo. (Perhaps even separate-but-related logos for
"general-purpose RISC-V processor" and "general-purpose RISC-V system"?)

> Thus, providing such proposals logically and inevitably actually
> *empowers* unethical Corporations to achieve their goals of exerting
> control over users.

How does it empower such unethical behavior when the conformance to the
general-purpose profile is optional anyway? Embedded microcontrollers
(even embedded application processors) probably would not use it.


-- Jacob

[Luke Kenneth Casson Leighton]

On Tue, Apr 24, 2018 at 3:44 AM, Jacob Bachmeyer <jcb6...@gmail.com> wrote:

>> Unfortunately, the next phase is to create a PCB that physically
>> locks out access to the RVDIAG port with a tamper-resistant
>> co-processor where the traces are buried from BGA pads down to inner
>> layers using blind vias on both the tamper-resistant external
>> co-processor and the main RISC-V core.
>>
>
>
> That would not be a conforming implementation: the standard would specify a
> short list of options for the RVDIAG connector and would mandate (1) the
> connector *must* be available *and* populated,

> [...]

ok so interestingly this is part of the reason I came up with EOMA68
(an "aggregation" standard i.e. a collection of other hardware
standards. it's a bit more than that but that's the short version).
EOMA68 is basically designed to ensure that computer components are
not thrown due to the end-user being so frustrated with their
limitations (DRM, vendor lock-in, etc.) that they throw out the
*entire* device.

EOMA68 *explicitly* prohibits the use of DRM-locking on the boot
process and the OS. It does however *permit* proprietary OSes and
proprietary boot chains... as long as an end-user has the right (and
the full documentation) to *replace everything*.

This helps keep Computer Cards out of landfill.

Point being: I've made a 6-year long-term study of this area.

One of the reasons that the Allwinner A20 was picked as the first
processor to use in the series was because it happened to be a (cheap)
"unbrickable" design. Six pins are provided which mutiplex SD/MMC (as
one of the bootROM sources to load a 16k first-stage bootloader from,
into SRAM) and then 4-pin JTAG plus 2-pin UART onto the *exact* same
pins.

What that means is that during power-up, Allwinner can simply plug in
an *EXTERNAL* special break-out board for their (larrrrge) customers
who are having problems... *without opening up the product*, and
that's really really incredibly important.

It *just so happens* that the exact same feature means that end-users
could (a) always boot from the external (over-riding absolute highest
priority) SD/MMC slot... oh and also advanced end-users could debug
the mass-produced device as well. It earned the A20 a "100%
unbrickable" reputation.

By contrast, the Rockchip RK3288 made the fatal mistake of having
eMMC as the "highest over-riding priority" boot device... consequently
if any phase of the bootloader on the eMMC became corrupted, the
entire mass-producd device is unrecoverable and ends up in landfill.

The point is: anything that does not go this far is effectively
useless at keeping mass-produced product out of landfill.... and
anything that *does* go that far (in a *processor* Standard - not a
hardware standard but a *processor* Standard) will be rejected by the
majority of licensees.

Not to mention that it will be completely ineffective at stopping
China RISC-V-clones from ignoring the Standard entirely... another
reason why making public and standard the means and method to put any
kind of DRM into RISC-V is a bad, bad idea.

>> Even more unfortunateiy, this applies generally: any scheme that is
>> proposed which is *intended* to provide user freedom of choice and
>> protection will have a similar uncontrollable fatal flaw at the design
>> and manufacturing phase *not* the RISC-V Standards phase, and is
>> consequently outside of the control of the RISC-V Foundation.
>
> The solution is easy and is part of providing the incentive for processors
> to support the scheme: for an overall system to carry the "general-purpose
> RISC-V" logo, the RVDIAG interface must be available as intended.
> Integrating a "special" diagnostic pad is *not* a general-purpose system.
> The Foundation would retain veto power over such misuse of the logo.
> (Perhaps even separate-but-related logos for "general-purpose RISC-V
> processor" and "general-purpose RISC-V system"?)

Ok follow the money trail. What's the incentive for Corporations to
make RISC-V mass-produced commodity processors? Reduced royalties
(more profit), lower power (reduction in BOM particularly
battery-operated therefore more profit), higher performance (more
people buy therefore more profit)... oh and DRM because the Media
Cartels / Mafia don't flat-out reject it and refuse to work with it
because they can't make ABSOLUTELY certain that people will "copy
movies"... thus no profit, thus no product.

Did you know that LG consider it to be a FAILURE on their part if you
even NOTICE that they are criminally infringing the GPLv2 in their
products?

And that Mediatek and other companies designing mass-volume products
here in Taiwan absolutely refuse to even give you datasheets about
their products? You approach them, you give them cash up-front for a
product concept, then THEY design it, THEY develop the source code
(all of it), THEY manufacture it, THEY ship the *finished product* by
the QTY N millions to your chosen sea port... all without you ever
even seeing a single datasheet, line of source code, or even a
schematic?

Providing even the *slightest* technically-feasible hints about how
to go about DRM-ifying such products plays *right* into such company's
hands. If it's Standardised and published and there are Reference
Implementations and even source code for 1st stage bootloaders,
u-boot, coreboot and the linux kernel that makes it *even easier* for
them!

All this despite the fact that Financial (and Military etc.) systems
really do *genuinely* need the exact same kinds of lock-down
methodologies. Here's a design that indicates that there is a genuine
market for tamper-resistant designs:

https://www.crowdsupply.com/design-shift/orwl

Hilariously they use an Intel SSD which of course you can't know if
the firmware for that is secure (or tampered with), and they *say*
they use AES (in hardware) but can that *actually* be trusted to be
the case. But leaving that "wark-wark" aside, the MAX32550 is
basically what keeps the whole thing under lock and key. Any kind of
tampering with the case is automatically detected: crypto keys are
destroyed instantly and the data's gone.

The point is: any action (or inaction) that empowers companies to act
in an unethical way is, by definition through logical reasoning,
itself unethical.

l.

[Jacob Bachmeyer]

Luke Kenneth Casson Leighton wrote:

> On Tue, Apr 24, 2018 at 3:44 AM, Jacob Bachmeyer <jcb6...@gmail.com> wrote:
>
>>> Unfortunately, the next phase is to create a PCB that physically
>>> locks out access to the RVDIAG port with a tamper-resistant
>>> co-processor where the traces are buried from BGA pads down to inner
>>> layers using blind vias on both the tamper-resistant external
>>> co-processor and the main RISC-V core.
>>>
>> That would not be a conforming implementation: the standard would specify a
>> short list of options for the RVDIAG connector and would mandate (1) the
>> connector *must* be available *and* populated,
>> [...]
>>
>

> [...]

>
> EOMA68 *explicitly* prohibits the use of DRM-locking on the boot
> process and the OS. It does however *permit* proprietary OSes and
> proprietary boot chains... as long as an end-user has the right (and
> the full documentation) to *replace everything*.
>

This is the intended result for "general-purpose RISC-V" and a RISC-V
PC, yes.

> This helps keep Computer Cards out of landfill.
>
> Point being: I've made a 6-year long-term study of this area.
>
> One of the reasons that the Allwinner A20 was picked as the first
> processor to use in the series was because it happened to be a (cheap)
> "unbrickable" design. Six pins are provided which mutiplex SD/MMC (as
> one of the bootROM sources to load a 16k first-stage bootloader from,
> into SRAM) and then 4-pin JTAG plus 2-pin UART onto the *exact* same
> pins.
>
> What that means is that during power-up, Allwinner can simply plug in
> an *EXTERNAL* special break-out board for their (larrrrge) customers
> who are having problems... *without opening up the product*, and
> that's really really incredibly important.
>

On the other hand, the use of a dedicated port that requires some
disassembly to access and/or can be physically placed behind a locked
door increases the risk of an Evil Maid attack somewhat. (Such an
attack has a chance to succeed until the user actually connects a
diagnostic pad or readout device and discovers the tampering. The
tampering *will* be discovered, but that discovery may be delayed long
enough for the attacker to have already stolen enough information to
consider the attack successful.)

> It *just so happens* that the exact same feature means that end-users
> could (a) always boot from the external (over-riding absolute highest
> priority) SD/MMC slot... oh and also advanced end-users could debug
> the mass-produced device as well. It earned the A20 a "100%
> unbrickable" reputation.
>

While this is interesting, it also is at a different level than the the
process that I am proposing: the purpose of init0 is (in PC terms) to
load a BIOS image, not an OS image. The image loaded by init0 is
responsible for such steps as initializing DRAM (which also makes a new
issue of *how* hardware is supposed to enforce clearing DRAM before
enabling RVDIAG on a cold start) and has access to the same SPI ROM it
was loaded from, as a convenient place to store a bootloader that can
load an OS from mass storage as the next step.

In other words, init1 is part of the boot ROM. This is for PC-class
hardware, which tolerates a higher degree of non-integration than the
typical tablet or phone.

> By contrast, the Rockchip RK3288 made the fatal mistake of having
> eMMC as the "highest over-riding priority" boot device... consequently
> if any phase of the bootloader on the eMMC became corrupted, the
> entire mass-producd device is unrecoverable and ends up in landfill.
>
> The point is: anything that does not go this far is effectively
> useless at keeping mass-produced product out of landfill.... and
> anything that *does* go that far (in a *processor* Standard - not a
> hardware standard but a *processor* Standard) will be rejected by the
> majority of licensees.
>

The "general-purpose RISC-V processor" is simply a processor module that
"does its part" to support that spec. There is no proposal to make this
mandatory in any way for RISC-V beyond a RISC-V PC system architecture
(which would also be useful for servers, larger network equipment, etc.).

> Not to mention that it will be completely ineffective at stopping
> China RISC-V-clones from ignoring the Standard entirely... another
> reason why making public and standard the means and method to put any
> kind of DRM into RISC-V is a bad, bad idea.
>

There is nothing proposed that would prevent building embedded or
application-specific processors that do not follow this design at all.
Indeed, the expected design for a microcontroller-like device is to
store the entire boot/system/app blob in internal flash, probably
programmed using either a custom interface or JTAG.

>>> Even more unfortunateiy, this applies generally: any scheme that is
>>> proposed which is *intended* to provide user freedom of choice and
>>> protection will have a similar uncontrollable fatal flaw at the design
>>> and manufacturing phase *not* the RISC-V Standards phase, and is
>>> consequently outside of the control of the RISC-V Foundation.
>>>
>> The solution is easy and is part of providing the incentive for processors
>> to support the scheme: for an overall system to carry the "general-purpose
>> RISC-V" logo, the RVDIAG interface must be available as intended.
>> Integrating a "special" diagnostic pad is *not* a general-purpose system.
>> The Foundation would retain veto power over such misuse of the logo.
>> (Perhaps even separate-but-related logos for "general-purpose RISC-V
>> processor" and "general-purpose RISC-V system"?)
>>
>
> Ok follow the money trail. What's the incentive for Corporations to
> make RISC-V mass-produced commodity processors?

The incentive: consumer demand for such a product. I believe that you
may know a fairly large initiative that would be interested. :-)

> [...]

>
> Providing even the *slightest* technically-feasible hints about how
> to go about DRM-ifying such products plays *right* into such company's
> hands. If it's Standardised and published and there are Reference
> Implementations and even source code for 1st stage bootloaders,
> u-boot, coreboot and the linux kernel that makes it *even easier* for
> them!
>

The *only* DRM-ish requirement in my proposal is that a digest of the
loaded "next-stage" be emitted before execution of that stage begins.
There is nothing technical to enforce this aside beyond the
non-replaceable init0 doing its part. Note that the history of stages
loaded during boot is *not* available to the running system; it is
dumped out the RVDIAG port during boot and is then gone.

> All this despite the fact that Financial (and Military etc.) systems
> really do *genuinely* need the exact same kinds of lock-down
> methodologies.

While such applications may simply not use "general-purpose RISC-V"
(they could certainly be called special-purpose), the better option is
to simply include a small hardware readout that stores the digests
emitted during startup and displays them upon request. If a custom
"locked" init1 is used, only the init1 digest (emitted by init0) need be
displayed on the front panel, to confirm that the "locked" init1 is
actually the init1 used. Ensuring that the displayed digest is the
known digest for the intended init1 is the user's problem.

> [...]

>
> The point is: any action (or inaction) that empowers companies to act
> in an unethical way is, by definition through logical reasoning,
> itself unethical.
>

So, by that reasoning, *not* advancing some "better" boot process and
simply permitting UEFI to be adopted (as was proposed at one point)
would have been unethical. :-)


-- Jacob

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

then we are talking about exactly the same thing. in u-boot
terminology the phase at which DRAM is initialised is called "SPL"
boot.

yes. and i will recommend an "unbrickable" embedded
allwinner-a20-style eGON-ROM -> boot0 -> boot1 -> u-boot ->
linux/kernel -> OS approach. no standards required.

>> [...]
>>
>> Providing even the *slightest* technically-feasible hints about how
>> to go about DRM-ifying such products plays *right* into such company's
>> hands. If it's Standardised and published and there are Reference
>> Implementations and even source code for 1st stage bootloaders,
>> u-boot, coreboot and the linux kernel that makes it *even easier* for
>> them!
>>
>
>
> The *only* DRM-ish requirement in my proposal is that a digest of the loaded
> "next-stage" be emitted before execution of that stage begins. There is
> nothing technical to enforce this aside beyond the non-replaceable init0
> doing its part.

except that it can be abused by proprietary OS writers.

> Note that the history of stages loaded during boot is *not*
> available to the running system; it is dumped out the RVDIAG port during
> boot and is then gone.
>
>> All this despite the fact that Financial (and Military etc.) systems
>> really do *genuinely* need the exact same kinds of lock-down
>> methodologies.
>
>
> While such applications may simply not use "general-purpose RISC-V" (they
> could certainly be called special-purpose), the better option is to simply
> include a small hardware readout that stores the digests emitted during
> startup and displays them upon request. If a custom "locked" init1 is used,
> only the init1 digest (emitted by init0) need be displayed on the front
> panel, to confirm that the "locked" init1 is actually the init1 used.
> Ensuring that the displayed digest is the known digest for the intended
> init1 is the user's problem.
>
>> [...]
>>
>> The point is: any action (or inaction) that empowers companies to act
>> in an unethical way is, by definition through logical reasoning,
>> itself unethical.
>>
>
>
> So, by that reasoning, *not* advancing some "better" boot process and simply
> permitting UEFI to be adopted (as was proposed at one point) would have been
> unethical. :-)

:)

for exactly the same reasons UEFI will also fail to be widely
adopted. it's too heavy.

[Jacob Bachmeyer]

Luke Kenneth Casson Leighton wrote:
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
>
> On Wed, Apr 25, 2018 at 3:31 AM, Jacob Bachmeyer <jcb6...@gmail.com> wrote:
>
>> Luke Kenneth Casson Leighton wrote:
>>
>>> On Tue, Apr 24, 2018 at 3:44 AM, Jacob Bachmeyer <jcb6...@gmail.com>
>>> wrote:
>>>

>> [...]

>>
>>> It *just so happens* that the exact same feature means that end-users
>>> could (a) always boot from the external (over-riding absolute highest
>>> priority) SD/MMC slot... oh and also advanced end-users could debug
>>> the mass-produced device as well. It earned the A20 a "100%
>>> unbrickable" reputation.
>>>
>> While this is interesting, it also is at a different level than the the
>> process that I am proposing: the purpose of init0 is (in PC terms) to load
>> a BIOS image, not an OS image. The image loaded by init0 is responsible for
>> such steps as initializing DRAM (which also makes a new issue of *how*
>> hardware is supposed to enforce clearing DRAM before enabling RVDIAG on a
>> cold start) and has access to the same SPI ROM it was loaded from, as a
>> convenient place to store a bootloader that can load an OS from mass storage
>> as the next step.
>>
>
> then we are talking about exactly the same thing. in u-boot
> terminology the phase at which DRAM is initialised is called "SPL"
> boot.
>

There is a minor wrinkle here. I envision a large system that uses a
service processor (with its own SRAM, possibly physically part of the
main processor's cache) on which init0 and init1 would run. The main
processor always has DRAM available and is not started until DRAM is
available.

>> [...]

>>>>> Even more unfortunateiy, this applies generally: any scheme that is
>>>>> proposed which is *intended* to provide user freedom of choice and
>>>>> protection will have a similar uncontrollable fatal flaw at the design
>>>>> and manufacturing phase *not* the RISC-V Standards phase, and is
>>>>> consequently outside of the control of the RISC-V Foundation.
>>>>>
>>>>>
>>>> The solution is easy and is part of providing the incentive for
>>>> processors
>>>> to support the scheme: for an overall system to carry the
>>>> "general-purpose
>>>> RISC-V" logo, the RVDIAG interface must be available as intended.
>>>> Integrating a "special" diagnostic pad is *not* a general-purpose system.
>>>> The Foundation would retain veto power over such misuse of the logo.
>>>> (Perhaps even separate-but-related logos for "general-purpose RISC-V
>>>> processor" and "general-purpose RISC-V system"?)
>>>>
>>>>
>>> Ok follow the money trail. What's the incentive for Corporations to
>>> make RISC-V mass-produced commodity processors?
>>>
>> The incentive: consumer demand for such a product. I believe that you may
>> know a fairly large initiative that would be interested. :-)
>>
>
> yes. and i will recommend an "unbrickable" embedded
> allwinner-a20-style eGON-ROM -> boot0 -> boot1 -> u-boot ->
> linux/kernel -> OS approach. no standards required.
>

The main concern driving the proposal for standard init0 images is an
anti-firmware-rootkit effort. Holding manufacturers to using specific
trustworthy images and placing them in mask ROM, with no place to store
other code, ensures that a compromised system can be effectively purged
and reset to a "known good" state -- and that "new from factory" *is* a
"known good" state. :-)

My proposed boot process essentially *is* your "A20-style" approach:
init0 -> init1 -> (on main processor) monitor (a component that ARM
systems do not have) -> GRUB -> kernel -> OS. Everything after init0 is
replaceable. A diagnostic pad can push the system through the process
starting at any stage after init0.

>>> [...]
>>>
>>> Providing even the *slightest* technically-feasible hints about how
>>> to go about DRM-ifying such products plays *right* into such company's
>>> hands. If it's Standardised and published and there are Reference
>>> Implementations and even source code for 1st stage bootloaders,
>>> u-boot, coreboot and the linux kernel that makes it *even easier* for
>>> them!
>>>
>> The *only* DRM-ish requirement in my proposal is that a digest of the loaded
>> "next-stage" be emitted before execution of that stage begins. There is
>> nothing technical to enforce this aside beyond the non-replaceable init0
>> doing its part.
>>
>
> except that it can be abused by proprietary OS writers.
>

How can it be abused? The digest chain is *not* available to the
running system, which cannot be trusted to report its own subversion by
a malicious loader anyway. It can *only* be read using the RVDIAG port.

>> Note that the history of stages loaded during boot is *not*
>> available to the running system; it is dumped out the RVDIAG port during
>> boot and is then gone.
>>
>>

>>> [...]
>>>
>>> The point is: any action (or inaction) that empowers companies to act
>>> in an unethical way is, by definition through logical reasoning,
>>> itself unethical.
>>>
>> So, by that reasoning, *not* advancing some "better" boot process and simply
>> permitting UEFI to be adopted (as was proposed at one point) would have been
>> unethical. :-)
>>
>
> :)
>
> for exactly the same reasons UEFI will also fail to be widely
> adopted. it's too heavy.

Please cite a current-production "PC" that does not have UEFI. For
bonus points, please cite one that will boot with 100% Free software and
firmware.


-- Jacob

[Luke Kenneth Casson Leighton]

On Fri, Apr 27, 2018 at 5:53 AM, Jacob Bachmeyer <jcb6...@gmail.com> wrote:

> There is a minor wrinkle here. I envision a large system that uses a
> service processor (with its own SRAM, possibly physically part of the main
> processor's cache) on which init0 and init1 would run.

again, this is standard practice in the (so-called) embedded world:
all of the 32 and 64-bit Allwinner series processors and the 32 and
64-bit Rockchip RK series are known to have internal SRAM of between
16 and 32k in size into which the first "DRAM PLL GPIO and next-stage
peripheral initialisation" phase is loaded. the RK3288 in particular
has that SRAM at a known fixed physical address, accessible even after
first boot (a quite handy feature).

although some of the Allwinner processors (the A31) used OR1K for
ultra-low-power (sleep) management i don't believe it's general
practice to have a separate "boot servicing" processor as the main
core suffices perfectly well. Intel's disastrous "Management" Engine
is the main exception to this rule (that i've heard of).

> Please cite a current-production "PC" that does not have UEFI. For bonus
> points, please cite one that will boot with 100% Free software and firmware.

from our off-list discussions i understand where you're going with
this (and i have been working for six years towards bringing to market
so-called "embedded" processors up to a more general-purpose usage....
none of which support UEFI).

however it has been such a painful hit-and-miss (actually... 100%
miss taking all the requirements into consideration) now i am also
working with the Shakti Group, to help them to bring about their
government-backed mandate of having fully-auditable NSA-spyware-free
hardware, at *all* levels: embedded right the way through to
ultra-high-performance VLIW Clustered Supercomputers. i will be
strongly advocating to them that UEFI *not* be part of that, and given
their spyware-free mandate they will be open to and in favour of such
discussions.

now - does that mean that i will also advocate any *other* kind of
standardisation in the boot process (beyond that of "unbrickable"
entirely open design and boot processes)? ABSOLUTELY NOT on the basis
that doing so *will* make it easier for DRM proponents to abuse it.
they're pretty much guaranteed to hijack any well-intentioned
standardisation process and *turn* it from anti-DRM *into* DRM... with
one strategically well-placed easily-justified seductive
bribe^wcompelling argument (yes Tim Berners Lee, i'm talking to you).

i notice a pattern here, jacob, that continuing discussions allows
you the opportunity to refine the approach that you're taking (a
phenomenon i really appreciate of any group discussion). so along the
same ethical lines that we discussed (off-list), by virtue of the
logical chain that goes, "i discuss with jacob, jacob refines idea,
idea gets standardised, standard gets abused by DRM proponents" it is,
logically, unethical of me to continue this particular topic of
conversation. much as i enjoy finding that there's someone with
similar like-minded interests, please excuse me, with much regret, if
i do not respond on this particular topic further. i look forward to
other conversations with you.

l.

[Jacob Bachmeyer]

Luke Kenneth Casson Leighton wrote:

> On Fri, Apr 27, 2018 at 5:53 AM, Jacob Bachmeyer <jcb6...@gmail.com> wrote:
>
>> There is a minor wrinkle here. I envision a large system that uses a
>> service processor (with its own SRAM, possibly physically part of the main
>> processor's cache) on which init0 and init1 would run.
>>
>
> again, this is standard practice in the (so-called) embedded world:
> all of the 32 and 64-bit Allwinner series processors and the 32 and
> 64-bit Rockchip RK series are known to have internal SRAM of between
> 16 and 32k in size into which the first "DRAM PLL GPIO and next-stage
> peripheral initialisation" phase is loaded. the RK3288 in particular
> has that SRAM at a known fixed physical address, accessible even after
> first boot (a quite handy feature).
>
> although some of the Allwinner processors (the A31) used OR1K for
> ultra-low-power (sleep) management i don't believe it's general
> practice to have a separate "boot servicing" processor as the main
> core suffices perfectly well. Intel's disastrous "Management" Engine
> is the main exception to this rule (that i've heard of).
>

IIRC, POWER8/POWER9 use a similar approach, with an embedded PowerPC
that boots the system (very slowly -- IBM got cute and decided the
service processor should also run Linux, so the service processor itself
takes a minute or so to boot, during which time the machine appears
dead). Larger IBM systems have generally used some kind of supporting
control/service computer since doing so became feasible. The concept is
not limited to IBM either -- the KL10 PDP-10 machines used an embedded
PDP-11/40 as a service processor.

>> Please cite a current-production "PC" that does not have UEFI. For bonus
>> points, please cite one that will boot with 100% Free software and firmware.
>>
>
> from our off-list discussions i understand where you're going with
> this (and i have been working for six years towards bringing to market
> so-called "embedded" processors up to a more general-purpose usage....
> none of which support UEFI).
>
> however it has been such a painful hit-and-miss (actually... 100%
> miss taking all the requirements into consideration) now i am also
> working with the Shakti Group, to help them to bring about their
> government-backed mandate of having fully-auditable NSA-spyware-free
> hardware, at *all* levels: embedded right the way through to
> ultra-high-performance VLIW Clustered Supercomputers. i will be
> strongly advocating to them that UEFI *not* be part of that, and given
> their spyware-free mandate they will be open to and in favour of such
> discussions.
>

I look forward to seeing these efforts bear fruit.

> now - does that mean that i will also advocate any *other* kind of
> standardisation in the boot process (beyond that of "unbrickable"
> entirely open design and boot processes)? ABSOLUTELY NOT on the basis
> that doing so *will* make it easier for DRM proponents to abuse it.
> they're pretty much guaranteed to hijack any well-intentioned
> standardisation process and *turn* it from anti-DRM *into* DRM... with
> one strategically well-placed easily-justified seductive
> bribe^wcompelling argument (yes Tim Berners Lee, i'm talking to you).
>

So you advocate for diffuse boot strategies, under the premise that they
cannot all be corrupted?

> i notice a pattern here, jacob, that continuing discussions allows
> you the opportunity to refine the approach that you're taking (a
> phenomenon i really appreciate of any group discussion).

That is the purpose of discussion, yes.

> so along the
> same ethical lines that we discussed (off-list), by virtue of the
> logical chain that goes, "i discuss with jacob, jacob refines idea,
> idea gets standardised, standard gets abused by DRM proponents" it is,
> logically, unethical of me to continue this particular topic of
> conversation. much as i enjoy finding that there's someone with
> similar like-minded interests, please excuse me, with much regret, if
> i do not respond on this particular topic further. i look forward to
> other conversations with you.

I will ask you a question here: since you have offered an example of a
non-conformant system that makes the RVDIAG interface inaccessible, and
the example of the Allwinner A20, which uses the "external" SD port as
the highest overriding boot source, what prevents a "DRMCo" manufacturer
from corrupting your A20-like "unbrickable" model in the exact same
way: using a "tamper-resistant" DRM-enforcing processor to emulate an
SD card and connecting it to the highest-priority boot source interface,
instead of routing that interface to the external socket as intended?

I believe that, if you examine the issues carefully enough, you will
find that both of our proposals have the exact same potential for abuse
by DRM proponents.


-- Jacob

[Luke Kenneth Casson Leighton]

On Sat, Apr 28, 2018 at 5:07 AM, Jacob Bachmeyer <jcb6...@gmail.com> wrote:

> So you advocate for diffuse boot strategies, under the premise that they
> cannot all be corrupted?

oooooo i promised i wouldn't answer but a good question i can't
resist, damnit :)

not quite: no matter what you do i think someone, somewhere, will
find a way to introduce Trusted^WTreacherous Computing. the trick is:
do you make it *easy* for them to do, or *harder* for them to do? me?
i choose "harder".

> I will ask you a question here: since you have offered an example of a
> non-conformant system that makes the RVDIAG interface inaccessible, and the
> example of the Allwinner A20, which uses the "external" SD port as the
> highest overriding boot source, what prevents a "DRMCo" manufacturer from
> corrupting your A20-like "unbrickable" model in the exact same way: using a
> "tamper-resistant" DRM-enforcing processor to emulate an SD card and
> connecting it to the highest-priority boot source interface, instead of
> routing that interface to the external socket as intended?

on the face of it: nothing. a *superficial* analysis shows that "all
processors are the same" with respect to Treacherous Computing.

> I believe that, if you examine the issues carefully enough, you will find
> that both of our proposals have the exact same potential for abuse by DRM
> proponents.

exactly. with one exception: you're advocating the creation of
standards: publication of information and standardisation of the same,
which makes it EASIER for Cartels to create Treacherous Computing, as
the pieces they require are now much more easily and readily available
for them to abuse.

companies that have Treacherous Computing components that are in
mass-volume production... because they're standardised (and thus
worth-while making money from), for example.

i will NOT be working on any such standardisation efforts.


but there's a deeper difference: if you're familiar with TrustZone,
it's called "Trust Zone" because the Cartels can TRUST that their DRM
will be pedalled onto people, preventing the user from having control
over and ownership of their devices.

so let's call it what it is: TreacherousZone.

i will also be strongly advocating that TreacherousZone *NOT* be part
of the processors that i am helping to be brought into existence
(which is separate and distinct from creating an IOMMU, an IOMMU being
just *one* component that's abused by TreacherousZone) . any Cartel
looking at these processors will go "argh! we can't possibly use
these processors for doing our DRM pedalling onto unsuspecting users!
anyone can hack them and root them and gain access to... everything!!!
argh o noes!"

whilst at the same annoying time being keenly aware that for
financial systems you need precisely this exact capability (secure
isolation). *sigh*.

l.

[Jacob Bachmeyer]

Luke Kenneth Casson Leighton wrote:

> On Sat, Apr 28, 2018 at 5:07 AM, Jacob Bachmeyer <jcb6...@gmail.com> wrote:
>
>> So you advocate for diffuse boot strategies, under the premise that they
>> cannot all be corrupted?
>>
>
> oooooo i promised i wouldn't answer but a good question i can't
> resist, damnit :)
>
> not quite: no matter what you do i think someone, somewhere, will
> find a way to introduce Trusted^WTreacherous Computing. the trick is:
> do you make it *easy* for them to do, or *harder* for them to do? me?
> i choose "harder".
>

I approach this from a different direction: how can we best make it
difficult to *sell* Treacherous Computing systems?

I believe that an "open general-purpose RISC-V" badge would have
significant value in the marketplace as a "this product does not contain
treacherous computing features" indication. Ultimately, the vendors are
in business to sell equipment, and I expect that, given an informed
choice and a clear way to tell the difference, most users will buy
non-treacherous-computing devices.

This could even cause push-back against DRM-pushing media companies,
when people eventually notice that "open general-purpose" and "works
with FooCorp streaming" are mutually-exclusive and start asking pointed
questions. "Because we think all of our customers are thieves" will
*not* be a well-received answer. :-)

[Note that I will respect your concerns and set my proposal for a
standard trustworthy boot process aside for this discussion, until I can
actually understand and address your concerns or you drop the discussion.]

>> I will ask you a question here: since you have offered an example of a
>> non-conformant system that makes the RVDIAG interface inaccessible, and the
>> example of the Allwinner A20, which uses the "external" SD port as the
>> highest overriding boot source, what prevents a "DRMCo" manufacturer from
>> corrupting your A20-like "unbrickable" model in the exact same way: using a
>> "tamper-resistant" DRM-enforcing processor to emulate an SD card and
>> connecting it to the highest-priority boot source interface, instead of
>> routing that interface to the external socket as intended?
>>
>
> on the face of it: nothing. a *superficial* analysis shows that "all
> processors are the same" with respect to Treacherous Computing.
>

Please explain how further analysis contradicts that initial conclusion.

>> I believe that, if you examine the issues carefully enough, you will find
>> that both of our proposals have the exact same potential for abuse by DRM
>> proponents.
>>
>
> exactly. with one exception: you're advocating the creation of
> standards: publication of information and standardisation of the same,
> which makes it EASIER for Cartels to create Treacherous Computing, as
> the pieces they require are now much more easily and readily available
> for them to abuse.
>
> companies that have Treacherous Computing components that are in
> mass-volume production... because they're standardised (and thus
> worth-while making money from), for example.
>
> i will NOT be working on any such standardisation efforts.
>

Then the "DRM cartel" will simply make their *own* standard and attempt
to pass it off as "the industry standard". (Possible example: UEFI
secure boot) Your refusal to standardize anti-lock-out simply means
that a "DRM cartel" scheme can be pushed as "the" standard, instead of
having to compete with an open community standard that actively stands
for the GNU notion of a "loyal computer"
(<URL:https://www.gnu.org/philosophy/loyal-computers.html>).


[... rest of reply omitted, as it amounted to ways my proposal meets
your stated concerns, but we are discussing the ethics of proceeding on
this at the moment...]


-- Jacob

[Luke Kenneth Casson Leighton]

On Sun, Apr 29, 2018 at 3:57 AM, Jacob Bachmeyer <jcb6...@gmail.com> wrote:

> I approach this from a different direction: how can we best make it
> difficult to *sell* Treacherous Computing systems?
>
> I believe that an "open general-purpose RISC-V" badge would have significant
> value in the marketplace as a "this product does not contain treacherous
> computing features" indication.

which is a good idea.... and doesn't need the RISC-V's permission,
involvement, or modifications to the ISA to do it [translation: good
idea... starting to wander into off-topic territory]

> Ultimately, the vendors are in business to
> sell equipment, and I expect that, given an informed choice and a clear way
> to tell the difference, most users will buy non-treacherous-computing
> devices.

or, if by volume the numbers are large enough it'll kinda happen by
accident. *funnily enough* the shakti group happens to be developing,
first, processors that will go into smartphones, tablets, netbooks and
so on, and the group doing the development has links to the India
Government 1 BILLION dollar education and government procurement
budget.

intel, google and other companies inexplicably are veeery nice to
them, i don't know whyyyyy ;)

> Then the "DRM cartel" will simply make their *own* standard and attempt to
> pass it off as "the industry standard". (Possible example: UEFI secure
> boot) Your refusal to standardize anti-lock-out simply means that a "DRM
> cartel" scheme can be pushed as "the" standard, instead of having to compete
> with an open community standard that actively stands for the GNU notion of a
> "loyal computer"

see above. overwhelm them by volume.

l.

[Jacob Bachmeyer]

Luke Kenneth Casson Leighton wrote:

> On Sun, Apr 29, 2018 at 3:57 AM, Jacob Bachmeyer <jcb6...@gmail.com> wrote:
>
>> I approach this from a different direction: how can we best make it
>> difficult to *sell* Treacherous Computing systems?
>>
>> I believe that an "open general-purpose RISC-V" badge would have significant
>> value in the marketplace as a "this product does not contain treacherous
>> computing features" indication.
>>
>
> which is a good idea.... and doesn't need the RISC-V's permission,
> involvement, or modifications to the ISA to do it [translation: good
> idea... starting to wander into off-topic territory]
>

Correct; "open general-purpose" is not part of the base ISA and never
will be. However, the ISA spec did touch on this at one time, and past
discussions on boot processes were held on isa-dev. This list is simply
the "best fit", since I know of no forum where the concept is an "exact
fit". (Some parts of the larger proposal (standard processor sockets
for various system interconnects, exact details of RVDIAG connector,
etc.) rightly belong on hw-dev.)

Also, some organization needs to be the "face" of the approach and
protect the "open general-purpose RISC-V" logo to ensure that it is only
used on systems that actually meet the purpose. I was hoping that the
Libre RISC-V group might be interested in the idea, if the RISC-V
Foundation does not itself take that role.

Further, UEFI on RISC-V *was* proposed and a prototype presented
(slides:
<URL:https://riscv.org/wp-content/uploads/2016/01/Tues1415-RISC-V-and-UEFI.pdf>)
at the 3rd RISC-V Workshop (along with a complete or near-complete port
of coreboot (slides:
<URL:https://riscv.org/wp-content/uploads/2016/01/Tues1345-riscvcoreboot.pdf>)).
I believe that HPEnterprise dropped out of of the RISC-V Foundation
after their efforts to make UEFI *the* RISC-V firmware standard were
rebuffed.

>> Ultimately, the vendors are in business to
>> sell equipment, and I expect that, given an informed choice and a clear way
>> to tell the difference, most users will buy non-treacherous-computing
>> devices.
>>
>
> or, if by volume the numbers are large enough it'll kinda happen by
> accident.

Without some way for users to easily recognize loyal computing products,
your initial volume will be displaced by carpet-bomb marketing and
dishonest sales tactics. We have seen this occur already with the x86
PC architecture. (And another note: where are the small netbooks now?)

> *funnily enough* the shakti group happens to be developing,
> first, processors that will go into smartphones, tablets, netbooks and
> so on, and the group doing the development has links to the India
> Government 1 BILLION dollar education and government procurement
> budget.
>
> intel, google and other companies inexplicably are veeery nice to
> them, i don't know whyyyyy ;)
>

Large procurement budgets tend to have that effect, but can also attract
corrupting influences: recall the "Office Open XML" incident, where
Microsoft responded to a mandate for ISO standard document format
support (i.e. OpenDocument, which had legitimately gone through the
standardization process via OASIS) by shoving their own format through
(by abusing ECMA) to produce a hilariously bad standard (rm(1) was a
valid consumer of OOXML documents in at least one revision), but now
OOXML also has an ISO standard number, which is all that really mattered.

>> Then the "DRM cartel" will simply make their *own* standard and attempt to
>> pass it off as "the industry standard". (Possible example: UEFI secure
>> boot) Your refusal to standardize anti-lock-out simply means that a "DRM
>> cartel" scheme can be pushed as "the" standard, instead of having to compete
>> with an open community standard that actively stands for the GNU notion of a
>> "loyal computer"
>>
>
> see above. overwhelm them by volume.

Counterexample: UEFI. "Volume" in this case being the entire PC
industry aligned behind the traditional PC BIOS. UEFI on x86 allows to
turn secure boot off, probably only because doing otherwise could have
been grounds for more anti-trust actions against Microsoft.


Again, we are veering off-course above: we both agree that opposition
to treacherous computing is an ethical imperative and seem to agree that
treacherous computing cannot be expected to successfully compete against
loyal computing in an honest market. You [lckl] are concerned that my
proposed means (a set of standards to make several key parts (including
most firmware) largely interchangeable, analogous to older PCs) to
promote loyal systems in the marketplace will backfire and contribute to
treacherous computing. Obviously, promoting DRM on general computing
hardware is contrary to my goals and your concerns are that my proposal
may inadvertently do so. I am trying to understand the causes of these
concerns.


-- Jacob

[kr...@berkeley.edu]

>>>>> On Sat, 28 Apr 2018 23:31:46 -0500, Jacob Bachmeyer <jcb6...@gmail.com> said:
| Also, some organization needs to be the "face" of the approach and
| protect the "open general-purpose RISC-V" logo to ensure that it is only
| used on systems that actually meet the purpose. I was hoping that the
| Libre RISC-V group might be interested in the idea, if the RISC-V
| Foundation does not itself take that role.

RISC-V is a trademark of the Foundation. Non-commercial use is
granted to non-members for systems that follow the RISC-V standards.

The RISC ISA that was originally designed at Berkeley is effectively
public domain, and derivatives can be developed and used freely. But
they cannot be called RISC-V, or use RISC-V in their name, except if
they follow Foundation guidelines. If "Libre RISC-V" is not following
the guidelines, then the project should change it's name.

The policy around the name was set up to avoid confusion,
fragmentation, and/or hijacking.

| I believe that HPEnterprise dropped out of of the RISC-V Foundation
| after their efforts to make UEFI *the* RISC-V firmware standard were
| rebuffed.

Interesting. Why do you believe this? What was your source?

Conspiracy theories abound on this list. You might believe this one,
but I happen to know it's false. Please don't spread untruths.

For the record, the Foundation is interested in having the largest
possible variety of software run on RISC-V, and not in restricting
uses of RISC-V.

One goal is to enable completely free and open hardware designs, with
no hidden software or firmware.

Another is to enable completely locked-down hardware designs.

These goals are not contradictory. Both are valuable for preserving
freedoms and security in different scenarios.

Krste

[Liviu Ionescu]

On 29 April 2018 at 11:01:09, kr...@berkeley.edu (kr...@berkeley.edu) wrote:

> For the record, the Foundation is interested in having the largest
> possible variety of software run on RISC-V, and not in restricting
> uses of RISC-V.

Sure. At declarative level things seem great.

The reality is that by mandating that all RISC-V devices to implement
in varying degrees the privileged specs (like the current documents
do, and the compliance suite will enforce, based on your recent
decisions), the Foundation favours Unix-based devices and prevents
other designs (like a better microcontroller profile) to be developed.

Sorry to say, but as long as you refuse to decouple the instruction
set from the privileged profile and you mandate certain semantics for
the CSRs, you **are** restricting the uses of RISC-V, and you are
negatively impacting the acceptance of RISC-V in some markets, which
happen to be not at all interrested in any Unix compatibility.


Regards,

Liviu


p.s. For those not aware of the latest developments, for reasons like
"there is a great demand for cores that can run either embedded RTOS
or Unix", the compliance tests will check in various degrees the
presence of the current M/S/U-modes and various CSRs, which is the
other way of saying that the privileged specs are mandatory.

[kr...@berkeley.edu]

This is incorrect. The proposed minimal profile only requires four
non-zero CSRs and ~16b of "privileged" state. The embedded profile
including new fast interrupts scheme (whatever is decided there) can
build on this. This is being done in a way that an implementation can
compatibly support the embedded profile and M/S/U, not to mandate the
latter.

Krste

[Liviu Ionescu]

On 29 April 2018 at 11:56:44, kr...@berkeley.edu (kr...@berkeley.edu) wrote:

> This is incorrect.

Really?

> The proposed minimal profile only requires
> four
> non-zero CSRs and ~16b of "privileged" state.

4 != 0
16b != 0

And the proposed minimal profile does not require only 4 CSRs, it
requires more (there were about 11 when I cheked). Four have various
active bits, the other can be wired to 0.

I don't know how others measure this, but as long as the minimal
profile will require even a single CSR and/or a single bit of status
from the privileged specs, it will not be standalone, but will depend
on the privileged specs.


Regards,

Liviu


p.s. The proposed microcontroller profile has 10 CSRs. Among them,
only the hartid is common with the privileged profiles. All other 9
have no equivalent in the privileged profile, and are designed to
minimise the context switch time and the time to enter/exit interrupt
critical sections (for example there is only one status register to be
saved/restored, not 4-6 as there are in the current privileged trap
handler implementation).

I was told that in order to be compliant, the microcontroller profile
should support the 11 minimum CSRs (that no application will ever use,
and most of them will be hardwired to zero), and, in addition, define
the actual used CSRs as custom CSRs.

I was also told that the cost to suport the useless CSRs is low, and I
should not bother with a bunch of wasted gates.

To me this is not a reasonable approach. :-(

It is a clear example of restricting the use of RISC-V.

[David PATTERSON]

Doesn't it seem obvious that to have an understandable software standard for a new platform it's not OK to allow anyone to make any changes they want and still call it RISC-V?

Dave

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAG7hfcLUJiCjCHHNq9Wf4EX%2Bf09sd6hVEMUgVGVRaTskU%2B4XYg%40mail.gmail.com.

[Luke Kenneth Casson Leighton]

On Sun, Apr 29, 2018 at 2:22 PM, David PATTERSON
<pat...@cs.berkeley.edu> wrote:
> Doesn't it seem obvious that to have an understandable software standard for
> a new platform it's not OK to allow anyone to make any changes they want and
> still call it RISC-V?

indeed it is. and (as i am a Certification Mark Holder i had to
research this... to the Nth degree....) it is also indeed reasonable
to have an "atomic arbitrator" (using Certification Mark Law) that
collates and curates all the "needs" of the various parties that wish
to use (and benefit from) RISC-V.

the question thus becomes whether the "system behind RISC-V" has been
set up to take into account the needs of the libre community (both
commercial and non-commercial) *in addition* to the "non-libre"
community, academic community and so on (bearing in mind that
Trademark Law requires "FRAND" terms)

in the wording of the priv-spec there is evidence which tends to
suggest that the words "libre" and "commercial" are
mutually-exclusively considered to be "incompatible". section 3.1.2
uses "non-commercial" whilst section 3.1.3 uses "Open-source project"
and SPECIFICALLY in the very next sentence is clearly EXCLUDED from
being "Commercial"! so it's right there - *in the specification* -
that there is a bias "Open equals non-commercial. FACT".

meaning: there is therefore quite a high probability that the RISC-V
Foundation is violating the "FRAND" terms of Trademark Law, here (and
consequently has lost the right to defend the Trademark).

also, given that there is a conflict of interest in the wording of
the RISC-V Member Agreement, *no Libre RISC-V party may join*.... even
if they're advisors to a team that has in excess of $45 million
government funding and that team has a goal of dropping a *billion*
RISC-V commodity-hardware processors onto the planet over the next 5+
years.

i'm still waiting if the "system known as the RISC-V Foundation" has
a behavioural / adaptive feedback mechanism that is capable of change
that will take this and *many other* oversights into account. so far
i have not seen any evidence that that is the case... because due to
conflict of interest i am *excluded from using the mechanism that
everyone else may freely use*. i would be delighted to be proven
wrong.

l.

[Jacob Bachmeyer]

kr...@berkeley.edu wrote:
>>>>>> On Sat, 28 Apr 2018 23:31:46 -0500, Jacob Bachmeyer <jcb6...@gmail.com> said:
>>>>>>
> | Also, some organization needs to be the "face" of the approach and
> | protect the "open general-purpose RISC-V" logo to ensure that it is only
> | used on systems that actually meet the purpose. I was hoping that the
> | Libre RISC-V group might be interested in the idea, if the RISC-V
> | Foundation does not itself take that role.
>
> RISC-V is a trademark of the Foundation. Non-commercial use is
> granted to non-members for systems that follow the RISC-V standards.
>
> The RISC ISA that was originally designed at Berkeley is effectively
> public domain, and derivatives can be developed and used freely. But
> they cannot be called RISC-V, or use RISC-V in their name, except if
> they follow Foundation guidelines. If "Libre RISC-V" is not following
> the guidelines, then the project should change it's name.
>

I envision a subset of RISC-V, specifically, RISC-V implementations that
could support local integrity verification (to deter/detect firmware
rootkits), but eschew any kind of lock-down. It is important that all
such systems would fully implement a RISC-V baseline (with standard
extensions) and pass RISC-V conformance tests. Fragmenting RISC-V is
absolutely *not* an acceptable outcome here. A RISC-V PC is intended to
be useful as a development environment for embedded RISC-V systems --
obviously, the two must be compatible for this to work. A fragmented
RISC-V fails on that criterion.

> The policy around the name was set up to avoid confusion,
> fragmentation, and/or hijacking.
>
> | I believe that HPEnterprise dropped out of of the RISC-V Foundation
> | after their efforts to make UEFI *the* RISC-V firmware standard were
> | rebuffed.
>
> Interesting. Why do you believe this? What was your source?
>

That was the impression that I got from the slides presented at the 3rd
RISC-V Workshop. Perhaps I am also somewhat oversensitive to such
possibilities after reading message-id
<CAEz=sokOVA0fcKHhp6oJ-BbYfXW...@mail.gmail.com>
<URL:https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAEz%3DsokOVA0fcKHhp6oJ-BbYfXWMKykvrq2nOiTetsdYwvWMmA%40mail.gmail.com>
and seeing the general direction that UEFI has taken.

> Conspiracy theories abound on this list. You might believe this one,
> but I happen to know it's false. Please don't spread untruths.
>

That was perhaps a more strongly worded statement than it should have
been. I trust that you know what you are talking about here and are
honest, and thus stand corrected.

> For the record, the Foundation is interested in having the largest
> possible variety of software run on RISC-V, and not in restricting
> uses of RISC-V.
>
> One goal is to enable completely free and open hardware designs, with
> no hidden software or firmware.
>
> Another is to enable completely locked-down hardware designs.
>
> These goals are not contradictory. Both are valuable for preserving
> freedoms and security in different scenarios.

Agreed. I want a means for users to easily recognize free and open
hardware designs, to ensure that they are not crowded out of the market
by dishonestly-marketed locked-down designs. Further, I am working on
proposals for "higher-level" standards, towards a goal of
interchangeable RISC-V processors in larger systems to promote the
development of a vibrant ecosystem around a future RISC-V PC system
architecture. (Mixed-vendor multiprocessing on multi-socket boards is
an explicit goal.)


-- Jacob

[Sean Halle]

On Sun, Apr 29, 2018 at 6:22 AM, David PATTERSON <pat...@cs.berkeley.edu> wrote:

Doesn't it seem obvious that to have an understandable software standard for a new platform it's not OK to allow anyone to make any changes they want and still call it RISC-V?

Indeed, we're entering a time now where RISC-V is starting to mature, with many different players adopting it.. and this may be the most vulnerable time of all for the success of RISC-V.  If conformance testing is not effective and the trademark not well defended, we could easily end up with a variety of divergent devices that are incompatible.  They all claim to be RISC-V but small variations mean a binary that runs on one will not run on the others.  That will either have to be corrected by aggressive legal action, or RISC-V may very well wither on the vine.  Can action be taken now to stave off this kind of divergence from taking root?  

For example, can the Foundation be given more teeth, and become more active in developing a clear, definitive, easier to use conformance system, and participate more in partnering with companies doing RISC-V chips, to help them maintain compliance?  Make them more pro-active.  Advertise them as the keepers of compliance.  Make the Foundation a well known one-stop shop for all things compliance?

It would be sad for there to be an achilles heel, and divergent implementations seems the most likely and credible achilles heel for RISC-V.

Dave

To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.

To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAG7hfcLUJiCjCHHNq9Wf4EX%2Bf09sd6hVEMUgVGVRaTskU%2B4XYg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+unsubscribe@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAHis7pn81R1GwP6CanVRWd2%2B3yABNMUNCR4Pfan24APkTeeOoA%40mail.gmail.com.

[Bruce Hoult]

On Tue, May 1, 2018 at 4:00 PM, Sean Halle <sean...@gmail.com> wrote:

On Sun, Apr 29, 2018 at 6:22 AM, David PATTERSON <pat...@cs.berkeley.edu> wrote:

Doesn't it seem obvious that to have an understandable software standard for a new platform it's not OK to allow anyone to make any changes they want and still call it RISC-V?

Indeed, we're entering a time now where RISC-V is starting to mature, with many different players adopting it.. and this may be the most vulnerable time of all for the success of RISC-V.  If conformance testing is not effective and the trademark not well defended, we could easily end up with a variety of divergent devices that are incompatible.  They all claim to be RISC-V but small variations mean a binary that runs on one will not run on the others.  That will either have to be corrected by aggressive legal action, or RISC-V may very well wither on the vine.  Can action be taken now to stave off this kind of divergence from taking root?  

For example, can the Foundation be given more teeth, and become more active in developing a clear, definitive, easier to use conformance system, and participate more in partnering with companies doing RISC-V chips, to help them maintain compliance?  Make them more pro-active.  Advertise them as the keepers of compliance.  Make the Foundation a well known one-stop shop for all things compliance?

It would be sad for there to be an achilles heel, and divergent implementations seems the most likely and credible achilles heel for RISC-V.

Yes. Everyone needs to keep in mind that correcting small imperfections is far less important than avoiding fragmentation. 

 

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAHis7pn81R1GwP6CanVRWd2%2B3yABNMUNCR4Pfan24APkTeeOoA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+unsubscribe@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAJ4GwDJodLe7UhYvn%2B0DHAHbMK6NtrBJysnZ1muXm_q9%2B2%2BsKw%40mail.gmail.com.

[Luke Kenneth Casson Leighton]

On Tue, May 1, 2018 at 5:00 AM, Sean Halle <sean...@gmail.com> wrote:
>
> On Sun, Apr 29, 2018 at 6:22 AM, David PATTERSON <pat...@cs.berkeley.edu>
> wrote:
>>
>> Doesn't it seem obvious that to have an understandable software standard
>> for a new platform it's not OK to allow anyone to make any changes they want
>> and still call it RISC-V?
>
>
> Indeed, we're entering a time now where RISC-V is starting to mature, with
> many different players adopting it.. and this may be the most vulnerable
> time of all for the success of RISC-V.

indeed. this is why i'm focussing on the conflict-resolution
proposal before it's too late.

> It would be sad for there to be an achilles heel, and divergent
> implementations seems the most likely and credible achilles heel for RISC-V.

divergent implementations such as those which occur after finding,
through nobody's fault, that there is a fundamental and fatal flaw in
the RISC-V ISA that absolutely, absolutely must be fixed, *after*
first stable release?

two incompatible *RISC-V FOUNDATION PUBLISHED* versions of the RISC-V
ISA *is* divergence, sean.

has anyone considered the consequences for the entire RISC-V
eco-system from the scenario where the RISC-V Foundation publishes in
5-30 years time an INCOMPATIBLE change to the RISC-V *BASE* ISA?

l.

p.s. there's ways to deal with non-conformant versions (that the
RISC-V Foundation is in danger of being unable to enforce, by failing
to respond as they are required to do under Trademark Law, but that's
a different matter).

[Liviu Ionescu]

On 1 May 2018 at 07:00:59, Sean Halle (sean...@gmail.com) wrote:

> ... If conformance testing is not effective and the trademark not

> well defended, we could easily end up with a variety of divergent
> devices that are incompatible. They all claim to be RISC-V but
> small variations mean a binary that runs on one will not run on
> the others.

In the microcontroller world there is no such thing as binary
compatibility between different devices. Even in the highly
standardised world of ARM Cortex-M, vendors are free to implement
their own memory map and peripherals.

I invite you to compile a binary for HiFive Unleashed U540 and try to
run it on the HiFive1 small board or Arty E31/E51 synthetic boards and
you'll see yourself the usefulness of such an approach. (You cannot
even run the same binary on very close devices, like HiFive1 and Arty
E31, simply because the flash address is different).


Regards,

Liviu

[Sean Halle]

Thanks for the focus on micro-controllers, Liviu.  The challenging part of RISC-V is it's reach, from micro-controllers to mobile, to desktop, to enterprise, and beyond.

For the mobile world, tablet world, desktop world, Enterprise IT world, and other areas where a standard platform is defined and a full service OS runs, distribution of binaries is the most common case.  If binary compatibility did not exist across devices, then RISC-V would be at a significant disadvantage in these worlds.

There have been some initial steps at defining a set of standard platforms, with the apparent goal of binary compatibility across devices that conform to a particular platform.  Now is when we're entering a phase in which this part of the RISC-V specification rises in importance.  Just conformance to a particular set of extensions won't be enough to ensure binary compatibility.  

Choosing the platform specifications comes down to understanding the use cases in the target segments of the market.  In order to achieve market acceptance, this kind of conformance is less about technical features and more about minimizing friction to adoption.  As such it becomes more of an art and potentially a political exercise, rather than a pure "what is the best technology" exercise.   It also makes the platform definition and accompanying conformance testing critical to market success.

I have difficulty seeing adoption of RISC-V in those worlds without a low friction platform definition and effective conformance testing to the platform that ensures binary compatibility.

If we want RISC-V to win in those markets, it may be market factors that determine the outcome (rather than technical factors).  And the key market factor may well be binary compatibility within a well defined platform.  Binary compatibility may well be a pre-requisite, before any other market factors enter the picture.

Sean

[Liviu Ionescu]

On 2 May 2018 at 01:13:09, Sean Halle (sean...@gmail.com) wrote:

> ... The challenging part of

> RISC-V is it's reach, from micro-controllers to mobile, to desktop, to
> enterprise, and beyond.

currently you can safely leave microcontrollers out of this list, the
current design was not done with microcontrollers in mind and it
shows.

> For the mobile world, tablet world, desktop world, Enterprise IT world, and
> other areas where a standard platform is defined and a full service OS
> runs, distribution of binaries is the most common case. If binary
> compatibility did not exist across devices, then RISC-V would be at a
> significant disadvantage in these worlds.

if you mean user space binary compatibility for unix-like
applications, yes, I generally agree, but I have difficulties to
understand how you will achieve this, considering the large number of
optional extensions.

will the compatible binaries be allowed to use M? A? F? D? C?

if you mean binary compatibility at system level, things are even more
unrealistic, even for the current privileged profile.

I remind you that at a certain moment while developing the current
specs, mtime & mtimcmp were moved from standard CSRs to custom
platform specific locations; big mistake, since this small detail
alone will prevent a M-mode binary to run on different RISC-V
privileged devices without an external configuration to tell the
actual location, which greatly complicates things.

> I have difficulty seeing adoption of RISC-V in those worlds without a low
> friction platform definition and effective conformance testing to the
> platform that ensures binary compatibility.

according to your requirements, matched with the current compliance
specs, a device that implements a minimal RV32I core that passes the
compliance test can implement an unrestricted number of weird custom
extensions and it remains perfectly fine, although the binaries that
use those extensions will obviously never run on any other device.

on the other hand, a multi-core/multi-hart device, that fully
implements RV64IMAFDC (the largest device supported by the proposed
microcontroller profile, described in
https://github.com/emb-riscv/specs-markdown/blob/develop/introduction.md#sub-profiles),
but decides to drop one of the 11 mandatory CSRs for the simple reason
that it will never be needed/used, this device cannot be labeled as
RISC-V. and, exactly the same device, implementing that CSR, possibly
by hardwiring it to zero, becomes compliant.

what can I say? great design!

> If we want RISC-V to win in those markets, it may be market factors that
> determine the outcome (rather than technical factors). And the key market
> factor may well be binary compatibility within a well defined platform.
> Binary compatibility may well be a pre-requisite, before any other market
> factors enter the picture.

if you don't mind people laughing at such a design, sure, you can
consider binary compatibility between microcontrollers and application
class devices.

as I said before, if these are the official plans to make RISC-V
compete in the ARM Cortex-M world, better forget about
microcontrollers and focus on Unix-like devices where you have better
chances.


regards,

Liviu

[Samuel Falvo II]

On Tue, May 1, 2018 at 4:27 PM, Liviu Ionescu <i...@livius.net> wrote:
> if you mean user space binary compatibility for unix-like
> applications, yes, I generally agree, but I have difficulties to
> understand how you will achieve this, considering the large number of
> optional extensions.
>
> will the compatible binaries be allowed to use M? A? F? D? C?

I'm not defending any particular decison; however, I believe this has
always been the intent, as I understand the history of the
specification. IIRC, the inspiration comes from PALcode in DEC Alpha
processors. The missing instructions cause illegal instruction traps,
which are caught and handled by the monitor software. The only time
missing instructions would ever be a concern was when writing M-mode
software (though, illegal instruction traps still happens there too;
if you're careful in trap handler design, it should be able to service
missing instructions in M-mode as well).

Indeed, given such an intent, I *think* any motherboard intended to
run an OS such as Linux was intended to have its own M-mode binary in
bootstrap ROM, and literally everything else would be handled in S and
U modes. The M-mode code is partly responsible for providing a
(virtual) standardized platform for S and U mode software to run
under.

--
Samuel A. Falvo II

[Jacob Bachmeyer]

Correct, which brings us back to a topic for this branch of the thread:
ensuring that on systems claimed to be general-purpose, that M-mode
binary will run any software the user wants and can itself be verified
to ensure that the monitor running has not been somehow replaced by malware.


-- Jacob

[Allen J. Baum]

At 9:33 PM -0500 5/1/18, Jacob Bachmeyer wrote:
>>
>
>Correct, which brings us back to a topic for this branch of the thread: ensuring that on systems claimed to be general-purpose, that M-mode binary will run any software the user wants and can itself be verified to ensure that the monitor running has not been somehow replaced by malware.
>
>-- Jacob
>

OK, I'll bite: what do you believe is a requirement to achieve this?

I think you are trying to ensure that the M-mode monitor won't restrict the software that can be run - but in a multi-uer system, we do need restriction to isolate users and their data from each other.
How does that interact with the "run any software" requirement?

What do believe the requirements are to validate the monitor?

I can't see any way to do that without hooking up a debugger, unless reading the boot (and debug) ROM is adequate - is it? once that code jumps out of ROM, I would think all bets are off, and if access is granted to read that, then other security isses start to pile up.


To be clear: I'm not saying you are wrong in any of this, but I'd like to know what you believe are the requirements and consequences of them.

--
**************************************************
* Allen Baum tel. (908)BIT-BAUM *
* 248-2286 *
**************************************************

[Liviu Ionescu]

On 2 May 2018 at 02:44:12, Samuel Falvo II (sam....@gmail.com) wrote:

> Indeed, given such an intent, I *think* any motherboard intended
> to
> run an OS such as Linux was intended to have its own M-mode binary
> in
> bootstrap ROM,

how do you cope with the prerequisite of binary compatibility
mentioned earlier? does it apply to the bootstrap ROM too?

> ... The M-mode code is partly responsible for providing

> a
> (virtual) standardized platform for S and U mode software to
> run
> under.

given the current single trap handler design, and the curent
implementation having to save/restore about 38 registers with each
call:

https://github.com/torvalds/linux/blob/master/arch/riscv/kernel/entry.S

... I'm convinced the speed of such a device is fair enough for a
student to demonstrate a home work.

otherwise, in the real world, all application class devices will
probably need to be RV64IMAFDC.


regards,

Liviu

[Samuel Falvo II]

On Tue, May 1, 2018 at 9:52 PM, Liviu Ionescu <i...@livius.net> wrote:
> how do you cope with the prerequisite of binary compatibility
> mentioned earlier? does it apply to the bootstrap ROM too?

Binary compatibility with what? I'm missing a benchmark to compare against.

I believe the intent was that the M-mode software was necessarily
hardware specific; it cannot be turtles all the way down. The author
likely knows which RISC-V part is in use, and the capabilities of the
motherboard or SoC. So, the purpose of the M-mode binary is to
provide software adaptation to the more *idealized* platform,
documented as a reference, perhaps as an implementation "profile".

> otherwise, in the real world, all application class devices will
> probably need to be RV64IMAFDC.

The market is headed that way already, and the RISC-V market isn't
anywhere near mature yet. Moreover, when it's out, I'm sure the V
extension will be next on that list. I'm not sure this is a relevant
concern to the issue I was specifically responding to, which is the
role M-mode code was intended to fulfill. The point I was trying to
make was M-mode was intended to provide a software "polyfill" to
bridge between the idealized non-privileged runtime environment and
the reality of the parts used.

Whether or not software emulation of missing instructions qualifies as
"real world" is to be determined by the hardware engineer building it.
Of course anybody would prefer a processor with everything in
hardware, and the market would take care of that on its own. But,
there's more that goes into an embedded design than just brute
hardware capabilities. Features cost gates, gates cost energy. Maybe
running my code on a software-emulated RISC-V environment is a toy to
you; but, if it meets its requirements and earns me a living, it
empirically and almost definitionally fails to be a toy at that point.

[Liviu Ionescu]

On 2 May 2018 at 08:26:14, Samuel Falvo II (sam....@gmail.com) wrote:

> Binary compatibility with what? I'm missing a benchmark to
> compare against.

well, the claim was that binary compatibility is the main factor for
the RISC-V design to succeed:

> If we want RISC-V to win in those markets, it may be market factors
> that determine the outcome (rather than technical factors).
> And the key market factor may well be binary compatibility within
> a well defined platform. Binary compatibility may well be a pre-requisite,
> before any other market factors enter the picture.

I've heard this argument from the very first moment when I asked for a
RISC-V microcontroller profile ("fragmentation should be avoided by
all means").

my claim is that binary compatibility between a microcontroller device
and an application class device is a nonsense.

those with limited knowldge on microcontrollers have difficulties to
understand this, so I invite them to first analyse how reasonable is
to expect absolute 100% M-mode binary compatibility between different
application class devices (like the bootstrap rom, like using custom
extensions, etc), before trying to enforce it to completely unrelated
devices.


regards,

Liviu

[Samuel Falvo II]

On Tue, May 1, 2018 at 10:53 PM, Liviu Ionescu <i...@livius.net> wrote:
> On 2 May 2018 at 08:26:14, Samuel Falvo II (sam....@gmail.com) wrote:
>> If we want RISC-V to win in those markets, it may be market factors
>> that determine the outcome (rather than technical factors).
>> And the key market factor may well be binary compatibility within
>> a well defined platform. Binary compatibility may well be a pre-requisite,
>> before any other market factors enter the picture.

Just to be clear, I did not write this paragraph.

[Liviu Ionescu]

On 2 May 2018 at 08:26:14, Samuel Falvo II (sam....@gmail.com) wrote:

> Features cost gates, gates cost energy.

If I remeber right, energy consumption is the integral of power over time.

Instead of using a few extra specialised gates for a short time, you
suggest that using a larger bunch of general purpose gates for a lot
longer time is more economical.

I don't say it cannot be so, but I would not count on it, from my
limited knowledge of the technology, it might be very well the other
way around.

I understand there are cases when the number of gates is limited (like
FPGAs), but otherwise I would not put a low transistor count before
the headaches of the software guys, at least for microcontrollers.

Actually this is a non-problem; in the industry, when a device is
selected for a project, if the required featured are not available,
the device is simply ignored, and another one is considered; no
serious developer will consider emulating the missing features.


Regards,

Liviu

[Cesar Eduardo Barros]

Em 02-05-2018 01:52, Liviu Ionescu escreveu:
> On 2 May 2018 at 02:44:12, Samuel Falvo II (sam....@gmail.com) wrote:
>> ... The M-mode code is partly responsible for providing
>> a
>> (virtual) standardized platform for S and U mode software to
>> run
>> under.
>
> given the current single trap handler design, and the curent
> implementation having to save/restore about 38 registers with each
> call:
>
> https://github.com/torvalds/linux/blob/master/arch/riscv/kernel/entry.S
>
> ... I'm convinced the speed of such a device is fair enough for a
> student to demonstrate a home work.

That's the Linux kernel, which has to save every register in the pt_regs
struct so they're all available for ptrace.

M-mode probably won't have the same concern, and would instead only
switch the stack and save the caller-saved registers (letting the
compiler spill the rest where necessary). With the appropriate compiler
flags, the set of caller-saved registers could even be reduced. And
that's if a high-level language is being used instead of pure assembly.

So, for a M-mode trap handler, the set of registers which have to be
saved while doing instruction emulation could be as few as around four
(doing it all in pure assembly, and using a fixed per-hart save area so
the stack doesn't need to be switched).

--
Cesar Eduardo Barros
ces...@cesarb.eti.br

[Bruce Hoult]

On Wed, May 2, 2018 at 11:19 PM, Liviu Ionescu <i...@livius.net> wrote:

On 2 May 2018 at 08:26:14, Samuel Falvo II (sam....@gmail.com) wrote:

> Features cost gates, gates cost energy.

If I remeber right, energy consumption is the integral of power over time.

Sure, or simply sum if looking at equal discrete time periods.

 

Instead of using a few extra specialised gates for a short time, you
suggest that using a larger bunch of general purpose gates for a lot
longer time is more economical.

I don't say it cannot be so, but I would not count on it, from my
limited knowledge of the technology, it might be very well the other
way around.

Suppose some instruction takes 1 clock cycle if implemented in hardware and 100 cycles to emulate. Supposing also that providing it in hardware adds 1% power consumption all the time whether it is used or not. If that instruction occurs less than once in every 10,000 instructions on average then emulating it will lower total power consumption.

Good candidates would be something that is used during program initialisation or for long term strategy planning that executes only a few times a second or less. Floating point often falls into this category ... it can be convenient to use FP to calculate some control parameters, but then for the actual continuously executed code fixed point is sufficient.

[Liviu Ionescu]

On 2 May 2018 at 17:50:34, Bruce Hoult (br...@hoult.org) wrote:

> Supposing also that providing it in hardware adds 1% power consumption
> all the time whether it is used or not. If that instruction occurs
> less than once in every 10,000 instructions on average then emulating
> it will lower total power consumption.

good point.

just curious: can the clock of various core subsystems be turned
on/off automatically, based on the predictions from the pipeline?

I guess that having no clock on various flip/flops in the subsystem
will further lower the power consumption, down to the residual limit,
which is usually very low.


from my experience with low power applications, advanced devices have
lots of clock enable bits, generally for various peripherals, or even
peripheral subsystems, and it is the responsibility of the application
to turn them on when needed, and turn them off when done.

perhaps something similar can be done automatically, for example while
floating point instructions are not used, keep the FPU clock off.


thank you,

Liviu

[Samuel Falvo II]

On Wed, May 2, 2018 at 7:50 AM, Bruce Hoult <br...@hoult.org> wrote:
> Good candidates would be something that is used during program
> initialisation or for long term strategy planning that executes only a few
> times a second or less. Floating point often falls into this category ... it
> can be convenient to use FP to calculate some control parameters, but then
> for the actual continuously executed code fixed point is

[Samuel Falvo II]

On Wed, May 2, 2018 at 7:50 AM, Bruce Hoult <br...@hoult.org> wrote:

> Good candidates would be something that is used during program
> initialisation or for long term strategy planning that executes only a few
> times a second or less. Floating point often falls into this category ... it
> can be convenient to use FP to calculate some control parameters, but then
> for the actual continuously executed code fixed point is sufficient.

I only mention these edge cases because I personally know people who
are currently using or designing in stack-architecture processors
(e.g., GA144 parts from GreenArrays) in embedded devices because of
how little power they draw. In RISC-V terms, these devices would be
RV18I (yes, 18-bit; long story, don't ask). They offer only basic
integer arithmetic, limited multiple precision support, and support
for single-bit shifts only. These are devices that have to run months
on end without failure from a single CR2016 coin cell. One
application uses this chip in an ocean bouy, powered by a couple of
thermocouples.

I hope that it demonstrates my point that there will always be
applications for minimal systems. Dismissing them with a No True
Scotsman fallacy is not productive.

[Bruce Hoult]

I'm not sure why that was a reply to me.

Certainly there are still things being made (or even designed) using 40 year old designs such as 6502, z80, 8085, 8051, and of course PIC. Not every application needs 32 bit processors. However the size/power/cost difference of 32 bits vs 8 bits is getting smaller all the time in absolute terms as well as relative to whatever else you want on the chip. Code density also tends to be very bad on those 70s designs, especially if you want to compile from C rather than hand write assembler.

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+unsubscribe@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAEz%3DsokO6enmQAiFmRhrfG8k20BW42mHdNu%3DuX_5xTGu1%3DQDKA%40mail.gmail.com.

[Samuel Falvo II]

On Wed, May 2, 2018 at 9:04 AM, Bruce Hoult <br...@hoult.org> wrote:
> I'm not sure why that was a reply to me.

I was appending to the log that is this discussion. It wasn't
intended to reply specifically to you. Sorry.

[Cesar Eduardo Barros]

Em 02-05-2018 12:16, Liviu Ionescu escreveu:
> On 2 May 2018 at 17:50:34, Bruce Hoult (br...@hoult.org) wrote:
>
>> Supposing also that providing it in hardware adds 1% power consumption
>> all the time whether it is used or not. If that instruction occurs
>> less than once in every 10,000 instructions on average then emulating
>> it will lower total power consumption.
>
> good point.
>
> just curious: can the clock of various core subsystems be turned
> on/off automatically, based on the predictions from the pipeline?

Wouldn't that cause unpredictable latencies, which are bad for embedded
systems?

> from my experience with low power applications, advanced devices have
> lots of clock enable bits, generally for various peripherals, or even
> peripheral subsystems, and it is the responsibility of the application
> to turn them on when needed, and turn them off when done.

This is better, since by enabling and disabling explicitly the latencies
are more predictable.

[Allen Baum]

(Samuel pointed out that I did not do reply-to-all. Again.)

A couple of data points:

 yes, it is common to gate off clocks to unused HW, if the pipeline knows that HW won't be used.

E.g. if there are no multiply instructions running down the pipe, then the multiplier isn't clocked

 This saves dynamic power, though not static leakage (which is not insignificant at the low voltages that power-sensitive devices run at)

 Implementations can even shut off power completely - so  code that doesn't use FP will have no power cost.

That could be entirely in HW (e.g. no FP for the past 1M cycles, shut down FP).

 The downside is that may take a while to turn itoff and  back on - state saving if nothing else (though you could power down the datapath but leave FPRs powered up). Risc-V has cleverly designed it so that if power is off, a trap is taken and state can be reloaded before execution begins.

There are obviously applications that need to draw so little power that any RISC-V implementation is too power hungry.

I don't think that's a market that we need to chase - as was mentioned, an 8b core may be adequate for those. 

The point that the power difference is converging is an interesting one. If the core is a smaller percentage of the SOC (so peripherals and memory draw the most power), then that feels correct. Note also as the absolute power goes down, the internal resistance of the battery starts to become more significant than core power as well.

Different applications have different priorities (cost, cost/performance, power, perfornance/power, performance) and that will set design choices.

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+unsubscribe@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CAG7hfcL5%3Df2S3ZokrPc0JS634UjAp26-iOJ3bgHug-pKRR_9rQ%40mail.gmail.com.

[Jacob Bachmeyer]

Allen J. Baum wrote:
> At 9:33 PM -0500 5/1/18, Jacob Bachmeyer wrote:
>
>> Correct, which brings us back to a topic for this branch of the thread: ensuring that on systems claimed to be general-purpose, that M-mode binary will run any software the user wants and can itself be verified to ensure that the monitor running has not been somehow replaced by malware.
>>

> OK, I'll bite: what do you believe is a requirement to achieve this?
>
> I think you are trying to ensure that the M-mode monitor won't restrict the software that can be run - but in a multi-uer system, we do need restriction to isolate users and their data from each other.
> How does that interact with the "run any software" requirement?
>

Physical control of the machine is assumed to be exclusive to the
rightful owner, with a few exceptions to the assumption that prevent
certain attacks and account for burglary/theft. I would permit monitors
that restrict what they will load, but the monitor itself can be
replaced at will, using a dedicated hardware interface, and is required
to be separate from the early init module required to start the
machine. This also allows the owner to ensure that any malware that may
be present in the system can be purged and overwritten with "known-good"
firmware.

For a multi-user system, the user isolation is provided by the
supervisor (or possibly a hypervisor or both) rather than the monitor;
the monitor sees only the machine owner as its user.

> What do believe the requirements are to validate the monitor?
>

I go with a hardware port (called "RVDIAG" in previous messages) that,
during boot, if active, dumps a digest of the loaded monitor image
before control is transferred to it. The port has two modes: full,
where an external debugger has full access to the system (especially the
early init firmware), and output-only, which simply dumps the digests of
each firmware component as the system starts. (Each component dumps the
digest of the next stage before transferring control; the root would be
required to be in mask ROM and readable using the diagnostic port.)
Full mode is an IEEE1355-like interface, while output-only mode is a
send-only UART (a UAT?) with some additional signals that allow a
simpler receiver, taking advantage of the other output drivers that full
mode requires. For some installations, full mode may be generally used,
since it would also provide a system console interface at very high
speed. (IEEE1355, Data/Strobe, using LVDS signaling)

> I can't see any way to do that without hooking up a debugger, unless reading the boot (and debug) ROM is adequate - is it? once that code jumps out of ROM, I would think all bets are off, and if access is granted to read that, then other security isses start to pile up.
>

I call it a "diagnostic pad", but it is essentially a debugger that has
(1) full read access to all storage in the main system, (2) almost full
write access (excepting only certain non-executable EEPROM that stores a
low-level log), (3) the use of a dedicated hardware port for its connection.

The security concerns are mostly resolved by disabling the diagnostic
port if no diagnostic pad is connected at reset. Enabling the
diagnostic port forces all volatile memory to be erased, preventing
cold-boot attacks using this interface.

The diagnostic port could also be available for use by system software
once the machine is started, either if the debugging functionality is
disabled, or using protocol elements to distinguish between
"debug/inspect" and "console". This allows any functioning machine to
be used as a diagnostic pad (in a pinch) with the correct software.

> To be clear: I'm not saying you are wrong in any of this, but I'd like to know what you believe are the requirements and consequences of them.

The rough model that I have been working with: (Note that this is for
PC-like systems and similarly open servers and other equipment designed
to be "loyal" in the GNU sense
(<URL:https://www.gnu.org/philosophy/loyal-computers.html>); objections
related to set-top boxes or other DRM gadgets not being able to use this
model are simply irrelevant.)

Basic Requirements:

(1) The overall scheme must involve no secrets not belonging to (and
introduced by) the machine owner (hereafter called simply "user", since
this party is assumed to control physical access and is the only "user"
from the firmware's perspective). Secrets leak. Users can replace
their own secrets. Users cannot replace a vendor's secrets.
(2) The user can verify every step of the firmware init process and can
prove to himself that the machine was started with a known set of
firmware images, (possibly including a supervisor image, depending on
the application) provided that the boot process was actually observed as
it occurred. (The firmware is assumed to be split into a tiny root
element, DRAM init, monitor, initial boot loader, etc.) This ensures
that firmware rootkits cannot be hidden.
(3) Software running on the machine should *not* be able to determine
what images were used to boot the system. (There is no point, since
malicious firmware carrying a rootkit could tamper with any such report;
enabling this gives only a false sense of security.) (This also means
that all digests dumped after the first one not recognized are suspect,
since a malicious firmware component could tamper with subsequent
images.) Only the diagnostic port is required to have access to read
the firmware.
(4) All system firmware can be read back (unconditionally) and
overwritten (unless in mask ROM) using the diagnostic port with 100%
certainty. (Peripherals not on the service network may have their own
unrelated firmware that is excluded from this rule, or may have their
own diagnostic ports.) This also provides a guaranteed unbricking
interface. If the main processor can potentially write to a firmware
image, the diagnostic port must be able to overwrite that firmware image.
(5) The system will attempt to boot with whatever the user loads as
firmware. Obviously, such an attempt cannot be guaranteed success,
since the user-provided image may have bugs or be written for other
hardware, but there are no restrictions that would prevent the attempt.
(This is unrelated to an image that may simply report failure if it
detects incompatible hardware. The hardware will run the image, but the
image may do nothing and report failure if it detects that it cannot
start "this" hardware.)
(6) For some hardware, early init may be particularly sensitive and
misconfiguration here may result in actual physical damage. A log of
early init modules used must be kept. (This can function both as
"warranty void if seal broken" and an audit trail for past firmware
images seen. This log is the only memory the diagnostic pad cannot
erase and overwrite at will.) Alternately, "early init" may also be
placed in mask ROM, but the firmware digest log is still required to
store digests of other firmware modules used to provide an audit trail
that ensures past intrusions will be eventually detected.
(7) If the system is started without a diagnostic pad connected, or the
diagnostic port is explicitly locked and the diagnostic pad
disconnected, the diagnostic port cannot be re-enabled without a hard
reset. When enabling the diagnostic port (but optionally not if the
port was active at the time of the reset), all volatile memory in the
system is erased. (This prevents "0wn3d-by-an-iPod" DMA attacks or
related "quasi-warm-boot" attacks using the diagnostic interface.)

Requirement (1) is absolute. Only systems meeting requirement (1) have
any chance of providing lasting security. ("Any system where a device
and the secrets within that device belong to different parties has a
fundamental security flaw.")

Requirement (2) is absolute. A system not meeting requirement (2)
cannot be trusted to be free of malicious software.

Requirement (3) is both a goal itself and a consequence of requirement
(1). Users can effectively bypass this requirement if they choose, by
attaching some trusted device that stores the digests emitted on the
diagnostic port during boot, but then the user must trust both that
device *and* the system to correctly relay the device's report, which,
in the case of an intrusion, cannot be relied upon. The user's device
could sign its report and include a timestamp or nonce to prevent
replay, but this does not scale due to requirement (1). This cannot
prove anything to a party that does not trust the user: the user could
attach such a device instead to a "special" port that simply feeds the
device what the third party wants to see.

Requirement (4) is partially (the ability to read back the firmware) a
consequence of requirement (2) and partially (the ability to replace the
firmware images) a goal itself. A system not meeting requirement (4)
cannot be guaranteed to have been cleaned after an intrusion.

Requirement (4) can be loosened slightly to permit hardware
write-protect on firmware memory, provided that said write-protect takes
the form of a physical switch or jumper that can be set by the user. If
implemented, the machine may refuse to start normally unless the
write-protect is set. Such write protect must be enforced by the
firmware memory itself. Additionally, non-writable firmware storage is
permitted, provided that the non-writable firmware memory is socketed
and can be replaced by the user with a commodity writable part at
reasonable (i.e. trivial in the developed world) expense. Firmware
storage, aside from the root init (which must be in mask ROM inside the
processor) and (possibly) early init (if and only if early init is in
mask ROM), must be external to the processor module if the device form
factor permits, unless the storage is implemented using a technology
that has unlimited write endurance.

Requirement (5) is both a goal itself and partially a consequence of
requirement (1).

Requirement (6) is needed to ensure that past intrusions will be
detected, even if an intruder "undoes" their handiwork, and serves to
deter firmware rootkits by ensuring eventual detection.

Requirement (7) is needed to prevent the diagnostic port itself from
becoming a security risk.

Requirement (7) might be loosenable a bit, to permit the port to be
locked with an optional volatile unlock password; if given, a diagnostic
pad can be reconnected and supply that password to unlock the port; if
not given, the port can only be unlocked by a hard reset (which clears
all volatile memory before unlocking the port). Upon hard reset, the
unlock password is erased and the port locked with no password unless
active. A diagnostic port locked with a password will honor a
lock-with-no-password command and erase the unlock password, leaving a
hard reset (and memory clear) as the only way to reactivate the port.

I have a concept for some consequences of these requirements and an
outline for an implementation, but I would rather see a fresh
perspective than reiterate those here.


-- Jacob

[Palmer Dabbelt]

On Wed, 02 May 2018 15:12:07 PDT (-0700), ces...@cesarb.eti.br wrote:
> Em 02-05-2018 12:16, Liviu Ionescu escreveu:
>> On 2 May 2018 at 17:50:34, Bruce Hoult (br...@hoult.org) wrote:
>>
>>> Supposing also that providing it in hardware adds 1% power consumption
>>> all the time whether it is used or not. If that instruction occurs
>>> less than once in every 10,000 instructions on average then emulating
>>> it will lower total power consumption.
>>
>> good point.
>>
>> just curious: can the clock of various core subsystems be turned
>> on/off automatically, based on the predictions from the pipeline?
>
> Wouldn't that cause unpredictable latencies, which are bad for embedded
> systems?

There's multiple schemes for turning off subsets of an SOC in order to save
power. One of those is knows as "clock gating", which is a common technique
for avoiding the energy overhead associated with clocking registers (and the
associated logic driven by those registers) that itself doesn't change the
behavior of the design in any way.

The simplest description of this I could find via a quick search is this

http://semiengineering.com/kc/knowledge_center/Clock-Gating/121

but since clock gating has been a standard technique for reducing the power
consumption for a long time now, there should be a thorough description of it
in any VLSI course (and therefor also in the books for these courses).

As is the case for the vast majority of circuit-level optimizations that are
only possible for particular RTL patterns, there's a bit of an art to doing
this in practice but the fundamentals can be easily understood.

[Allen Baum]

Whew - a lot to digest. A nice selection of requirements and rationales. I'm sure I can find something to quibble with, but nothing jumps out.

A couple of things attracted my attention:

1. I would expect root init to be in on-die ROM will be common, for what it is worth

2. In a system with many application cores, it may be a separate core that does a lot of the init. That can get pretty hairy in a big system - configuring clocks, power supplies, networks, DRAM, etc. Not very forgiving - bugs can be pretty fatal.

3. clearing volatile storage, especially at early boot, is non trivial

That's all for now.

[Alex Elsayed]

On Wed, May 2, 2018, 15:58 Jacob Bachmeyer wrote:

(3)  Software running on the machine should *not* be able to determine
what images were used to boot the system.  (There is no point, since
malicious firmware carrying a rootkit could tamper with any such report;
enabling this gives only a false sense of security.)  (This also means
that all digests dumped after the first one not recognized are suspect,
since a malicious firmware component could tamper with subsequent
images.)  Only the diagnostic port is required to have access to read
the firmware.

This requires the firmware never have a wild read bug; this seems unrealistically rigorous for firmware judging by current prevailing quality.

(4)  All system firmware can be read back (unconditionally) and
overwritten (unless in mask ROM) using the diagnostic port with 100%
certainty.  (Peripherals not on the service network may have their own
unrelated firmware that is excluded from this rule, or may have their
own diagnostic ports.)  This also provides a guaranteed unbricking
interface.  If the main processor can potentially write to a firmware
image, the diagnostic port must be able to overwrite that firmware image.

This requirement may not be actionable - or if actionable, may be weaker than expected. See https://threadreaderapp.com/thread/976066416267939840.html for a case of such a mechanism being bypassed, analyzed by Matthew Green.

(7)  If the system is started without a diagnostic pad connected, or the
diagnostic port is explicitly locked and the diagnostic pad
disconnected, the diagnostic port cannot be re-enabled without a hard
reset.  When enabling the diagnostic port (but optionally not if the
port was active at the time of the reset), all volatile memory in the
system is erased.  (This prevents "0wn3d-by-an-iPod" DMA attacks or
related "quasi-warm-boot" attacks using the diagnostic interface.)

My laptop has 32G. Some servers have over half a terabyte. This may be very problematic to do each boot. In addition, avoiding that using the "but optionally" renders this toothless - replacing an existing (idle) pad and _then_ rebooting is simple enough.

[Jacob Bachmeyer]

Allen Baum wrote:
> Whew - a lot to digest. A nice selection of requirements and
> rationales. I'm sure I can find something to quibble with, but nothing
> jumps out.
> A couple of things attracted my attention:
> 1. I would expect root init to be in on-die ROM will be common, for
> what it is worth

I have previously proposed that root init would be required to be in
on-die mask ROM, and would be required to be one of a small number of
approved, open, images. This model also helps to limit the possibility
of scope-creep for root init; the earlier proposals called it "init0"
and limited it to (1) RVDIAG endpoint implementation, (2) loading
"init1" from an SPI flash ROM or other device, and (3) digest
calculation and logging. Even rewriting the firmware storage is driven
from the diagnostic pad; "init0" only knows how to read.

I believe that root init is effectively required to be on-die and in
mask ROM for technical (unless the memory bus is 100% hardware; since
root init loads later firmware modules) and security (changing root init
could subvert the diagnostic port and bring the whole structure crashing
down) reasons.

> 2. In a system with many application cores, it may be a separate core
> that does a lot of the init. That can get pretty hairy in a big system
> - configuring clocks, power supplies, networks, DRAM, etc. Not very
> forgiving - bugs can be pretty fatal.

The earlier proposals envisioned an on-die RV32E (or RV32I; "init0"
would be written for RV32E) service processor with internal SRAM (SRAM
possibly physically shared with the main processor's cache array, if so,
activating the main processor halts the service processor) that would
handle configuring a DRAM controller. This is also why the digests of
firmware used must be recorded (requirement 6): implementations that
lack hardware protection against a bad init sequence can use this as
"warranty void if seal broken", while implementations that *are*
protected in hardware against bad configurations can tout that as a
marketing point: "our warranty remains valid even if custom init
modules are used".

More complex boards could have a "board service processor" as the first
device on the service network. (IEEE1355 link hardware can start itself
and hardware IEEE1355 routers are simple. They should be: IEEE1355 is
derived from the Transputer bus, and booting Transputers relied on a
special remote DMA over that bus!) This board-level processor can then
distribute firmware images to the main processor modules over the
service network from a shared firmware storage element.

As for power supplies, I expect either each socket to require fixed
voltages, to require processor modules be able to tolerate the highest
voltage permitted for their socket (but are not required to operate
under such conditions; over-voltage shutdown is acceptable as long
enough circuits remain functional to identify the required voltage and
reset the module after adjusting the rail), or require voltage selection
to be hardwired per-socket. (Another part of the "big picture" is a set
of standard processor sockets for various system interconnects (SCI,
PCI, PCIe, HyperTransport, Wishbone, some kind of packetized Wishbone
running on a DisplayPort PHY layer, etc.; whatever is actually used) and
memory interfaces such that any combination of processor and socket that
physically fit are electrically and logically compatible if both carry
the logo.)

> 3. clearing volatile storage, especially at early boot, is non trivial

Yes. This is a problem I am still thinking about.

> That's all for now.

Thanks; I look forward to more when you have had time to think it over.
(And to comments from others!)


-- Jacob

[Samuel Falvo II]

On Wed, May 2, 2018 at 7:18 PM, Jacob Bachmeyer <jcb6...@gmail.com> wrote:
> More complex boards could have a "board service processor" as the first
> device on the service network. (IEEE1355 link hardware can start itself and
> hardware IEEE1355 routers are simple. They should be: IEEE1355 is derived

Relatively. Perhaps.

My attempt to implement IEEE1355 for myself failed pretty
spectacularly. Contrary to documented claims, I find RS-232 to be
much simpler to implement and consumes less hardware.

That said, if you happen to have any pointers for implementing
IEEE1355, I'm still much interested in doing so for my own projects.
If you have any recommended reading material on this, please let me
know. As this is off-topic, feel free to mail me directly off-list.
Thanks!!

[Jacob Bachmeyer]

Alex Elsayed wrote:
> On Wed, May 2, 2018, 15:58 Jacob Bachmeyer wrote:
>
> (3) Software running on the machine should *not* be able to
> determine
> what images were used to boot the system. (There is no point, since
> malicious firmware carrying a rootkit could tamper with any such
> report;
> enabling this gives only a false sense of security.) (This also
> means
> that all digests dumped after the first one not recognized are
> suspect,
> since a malicious firmware component could tamper with subsequent
> images.) Only the diagnostic port is required to have access to read
> the firmware.
>
>
> This requires the firmware never have a wild read bug; this seems
> unrealistically rigorous for firmware judging by current prevailing
> quality.

It is not that firmware is actively hidden from the software; only that
there is no interface to query how the system was booted from inside the
system. Further, most of the firmware in question is *gone* after the
OS boots: only the monitor remains, and the service processor
envisioned for most of the early init has probably been shut down.

This is more like the "coreboot" model than the "UEFI" model. It is
more like coreboot in another way: the overarching purpose of the
entire proposal is to ensure that a 100% Free firmware/software stack
can be installed on systems following this model. (And the requirements
allow such systems to get a "carrot": a special logo that allows users
to easily recognize them in the marketplace.)

> (4) All system firmware can be read back (unconditionally) and
> overwritten (unless in mask ROM) using the diagnostic port with 100%
> certainty. (Peripherals not on the service network may have their
> own
> unrelated firmware that is excluded from this rule, or may have their
> own diagnostic ports.) This also provides a guaranteed unbricking
> interface. If the main processor can potentially write to a firmware
> image, the diagnostic port must be able to overwrite that firmware
> image.
>
>
> This requirement may not be actionable - or if actionable, may be
> weaker than expected.
> See https://threadreaderapp.com/thread/976066416267939840.html for a
> case of such a mechanism being bypassed, analyzed by Matthew Green.

It works just fine if read-back is implemented in hardware, or by a
firmware component (root init) that is in mask ROM and therefore may as
well *be* hardware. Ledger's problem is that they tried to secure an
*updatable* app by having the secure processor ask nicely for the
current app image. The proposed root init is simple enough to be openly
developed and frozen into mask ROM.

The "guaranteed unbrick" is envisioned to work by the diagnostic pad
either directly operating the SPI flash ROM interface using remote DMA
or passing a "firmware writer" to the service processor over the
diagnostic port. A second (or third) hard reset after first opening the
port ensures that only the root init in mask ROM has run at the point
that this process begins.

> (7) If the system is started without a diagnostic pad connected,
> or the
> diagnostic port is explicitly locked and the diagnostic pad
> disconnected, the diagnostic port cannot be re-enabled without a hard
> reset. When enabling the diagnostic port (but optionally not if the
> port was active at the time of the reset), all volatile memory in the
> system is erased. (This prevents "0wn3d-by-an-iPod" DMA attacks or
> related "quasi-warm-boot" attacks using the diagnostic interface.)
>
>
> My laptop has 32G. Some servers have over half a terabyte. This may be
> very problematic to do each boot.

Not each boot, only if the low-level diagnostic port is to be
activated. If no pad is connected, the port is locked and the boot
continues *without* a requirement to clear memory. If the port is to
operate in output-only mode, the digests are dumped as the boot proceeds
*without* a requirement to clear memory. The only time memory must be
cleared is when (1) the system was previously started *without* a
diagnostic pad connected, (2) a diagnostic pad is currently connected,
(3) a hard reset occurs, and (4) the diagnostic port is to become active
in "full" mode. Under these circumstances volatile memory must be
erased before proceeding. (Another option could be to designate certain
regions of memory (perhaps the first 1GiB?) as "secure volatile",
meaning that any information stored in that memory is guaranteed to be
erased before a diagnostic pad can access the system, unless a
diagnostic pad was already connected at the time the information was
placed there.)

> In addition, avoiding that using the "but optionally" renders this
> toothless - replacing an existing (idle) pad and _then_ rebooting is
> simple enough.

If the machine is holding secrets in volatile memory, and an idle
diagnostic pad was left connected with the port unlocked, the machine
owner is an idiot. That is akin to parking your car in front of a high
school with the windows down and the keys in the ignition, then
wondering why it was stolen by joyriding teenagers. (Sites using the
diagnostic port as a console network would lock the port before or
shortly after boot. A locked port remains (or becomes) accessible to
software running on the machine.)

The "but optionally" is intended to permit debugging an OS crash on a
development box -- the system has crashed, so the remote DMA capability
is needed, but erasing memory before letting the pad (perhaps actually
another computer running GDB) access it would be less than helpful.
This is optional because some systems might not be able to reliably
preserve memory across a hard reset (perhaps DRAM loses power or refresh
until the controllers are re-initialized) even though it is very useful
for debugging kernel panics.

The diagnostic port is also intended to be an internal connector (a pin
header) on PC or server form factors, rather than readily accessible.


-- Jacob