a « correct by construction » realistic digital circuit · stmicroelectronics...

STMicroelectronics PDE_FORCOMENT_PRE_09_007V01.00

"Correct by Construction" Realistic Circuit, M. Benveniste 1

Recent Innovations and Applications in B’2oo9, November 3rd, 2009, TU Eindhoven

A « Correct by Construction »Realistic Digital Circuit

Marc BENVENISTEFormal Methods

Digital Secure Access Division

2PDE_FORCOMENT_PRE_09_007V01.00 "Correct by Construction" Realistic Circuit, M. Benveniste RIAB’09

Digital Secure Access (DSA) Division http://www.st.com/stonline/domains/applications/security/index.htm

Pay TVIT & Security

Gov & IDBanking

Transport

SIMUSIM

NFC Solutions

MobileTelecom

TAM 2008 ~ 3 Bu

SecureConditional

AccessTAM 2008 ~ 150 Mu

SecureSmartcardsTAM 2008 ~ 800 Mu

Smartcard Circuits

High Range SecurityMid Range Security




Chip Security is NOT (only) Design Correctness...

* BSI-PP-0035 version 1.0 Security IC Platform Protection Profile , by Eurosmart, 2007/06/15

*


Chip Security (only) BUILDS on Design Correctness

• Accurate & complete documentation• Exhaustive verification & validation

• ... the very least to start working on security

*

* http://www.hsconsortium.co.uk/workplacesafety.html




Quoting www.scdsource.com*

/Correct-by-construction design flow/

’s Bryan Dickman said:

We hope to see a correct-by-construction design flowthat may also reduce the overall verification burden

We could get there by having designers use the tools from design onwards in the flow to systematically explore and formally prove their code

At the moment, we’re using formal rather retrospectively* http://www.scdsource.com/article.php?id=341 Mixing Formal and Dynamic Verification, Part1 & Part 2, by Bill Murray, 2009/05/29(emphasizing is mine)


Correct by Construction Chip Functionality:An advanced R&D feasibility study report

• ST23 Memory Protection Unit at a Glance

• Traditional Design Flow

• Experimental Design Flow

• Main Construction Steps

• Traditional versus Experimental

• Limitations & Ways Forward












MPU: Complete Programmable Access Control

• Memory Protection Unit: All accesses monitored

Various SIZES

MEMORIES

RAM

ROM

NVM

Key:

Optional Modules

Kernel Modules

Controlled Resources

Contact Interface

CRYPTO MODULES

Various ALGORITHMS

MPU

µ-Processor CORE(CPU, Logical Functions &

Dedicated Firmware)

I/O MODULES

Various PROTOCOLS




MPU - Overview

• Segment: addressable window in memory, defined by– Start / End addresses– A clearance level– Access rights (Read, Write, eXecute)– Active status (mapped, not mapped)

• Clearance level: privilege level of a program– A value in [Supervisor .. Public] (actually [0 .. 3])– Each segment is given a clearance level– Read & write access to peripheral registers are globally denied/granted for

each clearance level– Program clearance change control is enabled/disabled for each clearance

level (call gates)

• Access control principles: code (eXecute) & data (Read/Write) controls– A program can enforce clearance change control based on current and

previous program clearance levels– All needed data for a given program must be located in its own clearance (or

Public data) segments












Design & RTL Coding in HDL

Synthesis

Scan Chains Insertion (DFT)

Layout

Clock Tree & Routing

Model Checking(Equivalence)


FunctionalSimulation

Preliminary StaticTiming Analysis

Post LayoutTiming Analysis

Back-AnnotatedSimulations

Netlists + Constraints

Netlists + Constraints

Netlists + Layout

Netlists + Delays


A complex flow...


Source HDL Classical Development Flow

ImplementationSpecification

FunctionalSpecification

Gate LevelRepresentation

VerificationSpecification

InterfaceSpecificationData Sheet

VHDL"hand made"

Sim

ulat

ions

RTLRepresentation

AutotestingBinaries

Compiling

CompilingSynthesis

Test Plan &Programs

Ver

ifica

tion

Cam

paig

n












New Proved Source HDL Development Flow

FunctionalSpecification

Gate LevelRepresentation

VerificationSpecification

Property LevelModel

Adding Details

ArchitectureLevel Details

InterfaceSpecificationData Sheet

ImplementationLevel Details

Real Interface GeneratedVHDL

Sim

ulat

ions

B4SYN

RTLRepresentation

AutotestingBinaries

Compiling

Test Plan &Programs

Parameter Values(Constants)

Ver

ifica

tion

Cam

paig

n

CompilingSynthesis

Abstraction

ProofObligations

Event B

(System Modeling)












Initial (Simple) Models

a0

d0

t0

v0

c0

R0

r0

a

...

t

...

......

... ...

......

c d

RESET/POR

m0=0

m0=1

m0=2

RESET/POR

PHI

ACCESS

RESET/POR

RESET/POR

PSI




Final (Complex) Models

Addr

In

Ctrl

Clk

Viol

Out

Reset/BadPower

Segment Rights 0Segment Rights 1Segment Rights 2Segment Rights 3Segment Rights 4Segment Rights 5Segment Rights 6Segment Rights 7Segment Rights 8Segment Rights 9

Segment End Address 0Segment End Address 1

Segment End Address 2Segment End Address 3Segment End Address 4

Segment End Address 5Segment End Address 6

Segment End Address 7Segment End Address 8Segment End Address 9

Segment Start Address 0Segment Start Address 1

Segment Start Address 2Segment Start Address 3Segment Start Address 4

Segment Start Address 5Segment Start Address 6

Segment Start Address 7Segment Start Address 8Segment Start Address 9

Unmapped W ProtReg

OverX R X CGate Underflow

Lock Overflow

LockRd2Rd3

Rd1 Rd0

Cg2Cg3

Cg1 Cg0

Current Previous


What’s an Event B System ?

• An observation contract over a state space• State space:

– the set of all valuations of a given set of typed variables• Observation contract:

– if the system reaches a point where the invariant holds, then all observable transitions of the system are kept within this invariant subspace

• Invariant:– logical condition statement about the system variables

• Observable transition:– labeled guarded event fired infinitely often when open




What’s an Event B Refinement ?

• A change of observation space preserving bound contracts• State Space usually expands as the represented system

becomes more precisely defined• Observable transitions can be split or joined according to

description needs:– stretching observation or folding behaviors, for instance

• If “allow” refines “access”, then:– “allow” occurs at most as often as “access”

(guard strengthening)– “allow” preserves the expanded invariant

(everlasting contract) – “allow” doesn’t do something “access” would not do

(no contradiction)


Refining State & Behavior in sync... (1/6)

r0

a c d

...

t

...

......

... ...

......

R0

ALLOW DENYRESET/POR

ACCESSRESET/POR





r0

a c d

...

t

...

......

... ...

......

R0

ACCESS

ALLOW DENY

RESET/POR

RESET/POR

RESET/POR READ



tR

rr1

a c

... ...

... ...

r0

a c d

...

t

...

......

... ...

......

R0

RR1

Let’s take a closer look at this event...

ACCESS

ALLOW DENY

RESET/POR

RESET/POR

RESET/POR READ





tR

rr1

a c

... ...

... ...

r0

a c d

...

t

...

......

... ...

......

R0

RR1

ACCESS

ALLOW DENY

RESET/POR

RESET/POR

RESET/POR READ

REFINEMENTmpu02

...EVENTS

...

; readref allow

=SELECT

m0 = 2& t0 = TyR& a0 |-> c0 : rr1THEN

m0 := 0|| v0 := FALSEEND



tR

rr1

a c

... ...

... ...

r0

a c d

...

t

...

......

... ...

......

R0

RR1Ds

ACCESS

ALLOW DENY

RESET/POR

RESET/POR

RESET/POR READ





rr1

a c

... ...

... ...

r0

a c d

...

t

...

......

... ...

......

rw1

a c d

... ... ...

... ... ...

rx1

a c

... ...

... ...

rb1

a c

... ...

... ...

re1

a c

... ...

... ...

R0

RR1 RW1 RX1 RB1 RE1

ACCESS

ALLOW DENY

RESET/POR

RESET/POR

RESET/POR READ WRITE FETCH IACK IRET DENYNONE



tR tW tX tB tE tN

rr1

a c

... ...

... ...

r0

a c d

...

t

...

......

... ...

......

rw1

a c d

... ... ...

... ... ...

rx1

a c

... ...

... ...

rb1

a c

... ...

... ...

re1

a c

... ...

... ...

R0

RR1 RW1 RX1 RB1 RE1

Ds Ds Ds Ds Ds

As Cs

ACCESS

ALLOW DENY

RESET/POR

RESET/POR





SYSTEMmpu00

...EVENTS

...

; access =SELECTm0 = 2

THENm0 := 0

END

Let’s RefineREFINES mpu00...; allow ref access =

SELECTm0 = 2

& a0 |-> c0 |-> d0 |-> t0 : r0THENm0, v0 := 0, FALSE

|| c0 :: CLs|| r0 :: ADs * CLs * BYs <-> TYsEND

; deny ref access =SELECTm0 = 2

& a0 |-> c0 |-> d0 |-> t0 /: r0THENm0, v0 := 0, TRUE

END

⊑


SYSTEMmpu00

...EVENTS

...


THENm0 := 0

END

“allow” Refines “access”REFINES mpu00...; allow ref access =

SELECTm0 = 2





END

⊑⇐




REFINES mpu00...; allow ref access =

SELECTm0 = 2





END

SYSTEMmpu00

...EVENTS

...


THENm0 := 0

END

“deny” Refines “access”

⊑⇐


SYSTEMmpu00

...EVENTS

...


THENm0 := 0

END

Refinement is not enough...REFINES mpu00...; allow ref access =

SELECTm0 = 2





END

m0 = 2 & not( a0 |-> c0 |-> d0 |-> t0: r0 ) &m0 = 2 &a0 |-> c0 |-> d0 |-> t0: r0 &

"`Check refinement exclusivity - companion model'“=>

bfalse

⊑




SYSTEMmpu

...EVENTS

...


THENm0 := 0

END

...exclusive refinement is still not enough...REFINES mpu...; allow ref access =

SELECTm0 = 2





ENDm0 = 2 &not( m0 = 2 & not( a0|-> c0|-> d0|-> t0: r0 ) ) &

"`Check refinement liveness - companion model'"=>

a0 |-> c0 |-> d0 |-> t0: r0

⊑⇐⇒


SYSTEMmpu00

...EVENTS

...


THENm0 := 0

END

...now we can be confident it’s all there...REFINES mpu00...; allow ref access =

SELECTm0 = 2





END

⊑⇔




Refine by “squeezing” events

ACCESS

ALLOW DENY

RESET/POR

RESET/POR

TRUE


Refinement, Liveness et Exclusivity:

Localized properties, stepwise provable, hence simplified


The Refinement Plan (1/3)

Registers access policy (mem. vs. reg.) Supervisor clearance introduced

Registers_16

Deny cases split by access type Clearances stack introduced (interrupts)

Split Deny5

By-passing checks automata Interrupts & reset management

Exceptions4

Rights matrix split for each access typeAllow cases split by access type

Split Access3

Abstract complete access policyComplete Policy2

Host execution modelHost_11

Main PurposeStepN°

Implementation

PolicySpecification





Segments as address ranges (start & end)Mapped segment bit introduced

Segments_212

MPU register access policyTheir symbolic addresses introduced

Registers_213

Denied access cases grouped by alarmAlarms_211

Identification of denied accessesAlarm bits introduced

Alarms_110

Segments as sets of addressesConstructive set expressions defined

Segments_19Code access policy, Call gates introducedCode8

Data access policy Public clearance introduced

Data7

Main PurposeStepN°

Implementation

PolicySpecification



Expression simplifications for VHDL Prop. not translated, types drive translator

Translate18

Physical interface for meaning (access type)All input cases covered, sampling on “tick”

Host_217

Effective write of MPU registers Constant write access functions

Registers_416

MPU registers effective read, Output definedConstant read access functionsSymbolic addresses are bytes now

Registers_315

Segments granularityImplementation optimization

Segments_314

Main PurposeStepN°

Implementation

PolicySpecification




Event & Variables Build up Graph

0

10

20

30

40

50

60

70

Host_1

Comple

te Policy

Split A

ccess

Excep

tions

Split D

eny

Regist

ers_1

DataCod

e

Segmen

ts_1

Alarms_

1

Alarms_

2

Segmen

ts_2

Regist

ers_2

Segmen

ts_3

Regist

ers_3

Regist

ers_4

Host_2

Translat

e

Refinement steps

Num

ber o

f

Impacted Events Events Variables Constants

*

* Steve Wright in“Quite Big Model Presentation”Rodin Workshop, 2009/07/17


Proof Obligations Build up Graph

0

5 0

1 0 0

1 5 0

2 0 0

2 5 0

3 0 0

3 5 0

4 0 0

H os t_ 1

C om p le te Po lic

y

S p l it A c ce ss

E x cep tion s

S p l it D e n y

R eg is te rs_ 1 D a taC o de

S eg m en ts_ 1

A la rms _ 1

A la rms _ 2

S eg m e n ts_ 2

R eg i s te rs_ 2

S eg m en ts_ 3

R eg i s te rs_ 3

R eg i s te rs_ 4H o s t_ 2

T ran s l a te

R e f in e m e n t S te p s

Num

ber o

f Pro

ved

Obl

igat

ions

& In

tera

ctiv

e Pr

over

Com

man

ds

0 %

1 0 %

2 0 %

3 0 %

4 0 %

5 0 %

6 0 %

7 0 %

8 0 %

9 0 %

1 0 0 %

Perc

enta

ge o

f Aut

omat

ic P

roof

A u to U s e r % A u to C o m m a n d s




Proof Obligation Breakdown Graph (1/2)

85 3 4 2 0 7 5 6 2 1 8 2 6 5 0 2 7 1 8 2 8 4 5 6 0 5 5 6 9 3 7 4 4 1

0 % 1 0 % 2 0 % 3 0 % 4 0 % 5 0 % 6 0 % 7 0 % 8 0 % 9 0 % 1 0 0 %

P O s

C o n tr i b u tio n s b y R e fin e m e n t S te p

H o s t_ 1 C o m p le te P o lic y S p li t A c c e s s E x c e p t io n s S p l it D e n y R e g is te rs _ 1 D a taC o d e S e g m e n ts _ 1 A la rm s _ 1 A la rm s _ 2 S e g m e n ts _ 2 R e g is te rs _ 2 S e g m e n t s _ 3R e g is t e rs _ 3 R e g is te rs _ 4 H o s t_ 2 Tra n s la te


Proof Obligation Breakdown Graph (2/2)

3 5 31 1 0 9 1 4 1

0 % 1 0 % 2 0 % 3 0 % 4 0 % 5 0 % 6 0 % 7 0 % 8 0 % 9 0 % 1 0 0 %

P O s

C o n tr ib u t io n b y M o d e ls

R e fin e m e n t m a in c o lu m n E xc lu s iv ity c o m p a n io n L ive n e s s c o m p a n io n




Observations on resulting implementation

• Built static structure is quite complex~60 constants, ~50 variablesJust imagine if verification had to start at this (RTL) level !What would you verify ?

• A lot of individual cases 56 events

• Although very simple cases~12 lines each

• Built with proved exhaustive assurance of:– Correctness: no contradiction regarding all specified behaviors– Determinism: no overlapping specified behaviors– Completeness preservation: no development holes












Trying a rough comparison

~1 600 obligations~ 600 with ~4000 cmds

-Proofnumber of items

~5 KgatesSizeequivalent nand gates

~30 patterns Ok(better debug signals)

~30 patterns OkSimulationRTL & gate level

4 loosely linked(only 1 generated module)

~15 tightly linkedStructuremodule number

~7 500 B~3 500 VHDL

~3 600 VHDLVolumecommented source lines

~145(~200 translator)

~145Effortperson.days

Experimental FlowClassical FlowCriteria












Benefits, Drawbacks & Future work

• Benefits– Zero bug macros become feasible– Highly parameterized coding is encouraged– Focus can safely turn onto security concerns

• Drawbacks– No composition mechanism to assemble units– Not yet ready for industry (both method & tool)

• Future work– Extend to other case studies– Propose language support enhancements


Please Read Carefully:

Information in this document is provided solely in connection with ST products. STMicroelectronics NV and its subsidiaries ("ST") reserve the right to make changes, corrections, modifications or improvements, to this document, and the products and services described herein at any time, without notice. All ST products are sold pursuant to ST’s terms and conditions of sale. Purchasers are solely responsible for the choice, selection and use of the ST products and services described herein, and ST assumes no liability whatsoever relating to the choice, selection or use of the ST products and services described herein. No license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted under this document. If any part of this document refers to any third party products or services it shall not be deemed a license grant by ST for the use of such third party products or services, or any intellectual property contained therein or considered as a warranty covering the use in any manner whatsoever of such third party products or services or any intellectual property contained therein.UNLESS OTHERWISE SET FORTH IN ST’S TERMS AND CONDITIONS OF SALE ST DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY WITH RESPECT TO THE USE AND/OR SALE OF ST PRODUCTS INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE (AND THEIR EQUIVALENTS UNDER THE LAWS OF ANY JURISDICTION), OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. UNLESS EXPRESSLY APPROVED IN WRITING BY AN AUTHORIZED ST REPRESENTATIVE, ST PRODUCTS ARE NOT RECOMMENDED, AUTHORIZED OR WARRANTED FOR USE IN MILITARY, AIR CRAFT, SPACE, LIFE SAVING, OR LIFE SUSTAINING APPLICATIONS, NOR IN PRODUCTS OR SYSTEMS WHERE FAILURE OR MALFUNCTION MAY RESULT IN PERSONAL INJURY, DEATH, OR SEVERE PROPERTY OR ENVIRONMENTAL DAMAGE. ST PRODUCTS WHICH ARE NOT SPECIFIED AS "AUTOMOTIVE GRADE" MAY ONLY BE USED IN AUTOMOTIVE APPLICATIONS AT USER’S OWN RISK. Resale of ST products with provisions different from the statements and/or technical features set forth in this document shall immediately void any warranty granted by ST for the ST product or service described herein and shall not create or extend in any manner whatsoever, any liability of ST.

ST and the ST logo are trademarks or registered trademarks of ST in various countries. Information in this document supersedes and replaces all information previously supplied. The ST logo is a registered trademark of STMicroelectronics. All other names are the property of their respective owners.

© 2009 STMicroelectronics - All rights reserved

STMicroelectronics group of companies Australia - Belgium - Brazil - Canada - China - Czech Republic - Finland - France - Germany - Hong Kong - India - Israel - Italy - Japan - Malaysia - Malta - Morocco - Singapore - Spain - Sweden - Switzerland - United Kingdom - United States of America

www.st.com

B Models :B4SYN Translator:Screenplay, Direction & Realization :Support Design :Administration :Production :

Credits & AcknowledgementThe FORmal CO-developMENT Project

L. Mussat, ClearsyT. Lecomte & A. Requet, Clearsy

M. Benveniste, STMicroelectronicsD. Chomaud, STMicroelectronics

R. Petri, STMicroelectronics, J.P. Pitzalis, Clearsy4th et 5th Conventions PACA Regional Council - STMicroelectronics - Clearsy




Thank You !

Any Question?

a « correct by construction » realistic digital circuit · stmicroelectronics...

Documents