Formally verifying exceptions in low-level code with Separation - - PowerPoint PPT Presentation

▶
formally verifying exceptions in low level code with
SMART_READER_LITE
LIVE PREVIEW

Formally verifying exceptions in low-level code with Separation - - PowerPoint PPT Presentation

Jul 21, 2023 264 likes •420 views

Formally verifying exceptions in low-level code with Separation Logic Marco Paviotti and Jesper Bengtson IT University of Copenhagen 22nd October Nordic Workshop on Programming Theory (NWPT) Reykjavik, Iceland 1 Verification of low-level

slide-1
SLIDE 1

Formally verifying exceptions in low-level code with Separation Logic

Marco Paviotti and Jesper Bengtson IT University of Copenhagen

22nd October Nordic Workshop on Programming Theory (NWPT) Reykjavik, Iceland

1

slide-2
SLIDE 2

Verification of low-level code

  • Hand-crafted code often found in security-critical places (e.g.

kernels)

  • Mechanically verifying low-level, unstructured code is crucial
  • Categorical models have successfully inspired separation logic
  • higher-order and shared memory concurrency (iCAP, Svendsen and Birkedal)
  • for verification of low-level code (Jensen, Kennedy and Benton)
  • Kernels make heavy use of exceptions/interrupts
  • There is no nice logic/model accounting for these behaviours
slide-3
SLIDE 3

Interrupts

When an interrupt fires the CPU:

Save Restore IRET

  • looks up the address of the

handler in the IDT table

  • Stores the return address on the

top of the stack

  • Jumps to the handler

It is the handler responsibility to restore the state and return from the interrupt

IDT Register Typical Handler Structure

IDT table

3

slide-4
SLIDE 4

Motivating Example

mov ESI, info; mov EDI, [ESI]; mov [EDI], 0; add EDI, 4; mov [ESI], EDI.

Unmapped Store

[ESI] EDI= EDI

4

slide-5
SLIDE 5

mov ESI, info; mov EDI, [ESI]; mov [EDI], 0; add EDI, 4; mov [ESI], EDI.

Unmapped Store

[ESI] EDI=

Motivating Example

!!

5

slide-6
SLIDE 6

Our contributions

  • Semantics and instruction rules for exceptions
  • We prove their use by verifying the memory allocator

example

6

We rely on an existing Coq formalisation of the assembly x86[1,2]

1Andrew Kennedy, Nick Benton, Jonas Braband Jensen, and Pierre-Evariste Dagand. Coq: the world’s best macro assembler? In PPDP 2013.

  • 2J. B. Jensen, N. Benton, and A. J. Kennedy. High-level separation logic for low-level code. POPL 2013
slide-7
SLIDE 7

Goals and Related work

  • First step towards asynchronous interrupts and

thus Verification of Device Drivers and Schedulers (Concurrency)

  • Our end is similar to Feng et al.’s[1], but
  • here we don’t rely on abstractions
  • Want: a nice model
  • 1X. Feng, Z. Shao,Y. Guo, Y. Dong. Certifying Low-Level Programs with Hardware Interrupts and Preemptive Threads

7

slide-8
SLIDE 8

Coq and assembly

  • Code is data
  • Unstructured assembly code
  • Memory :
  • Using notation can write assembly code in Coq

list 32 bool * list 32 bool

slide-9
SLIDE 9

Higher-Order Separation Logic for low-level code[1]

` (safe ⌦ EIP 7! j ? Q) ! (safe ⌦ EIP 7! i ? P) ↵ i..j 7! c

Precondition Post-Condition Code

Meaning

  • 1J. B. Jensen, N. Benton, and A. J. Kennedy. High-level separation logic for low-level code. POPL 2013

9

when ‘c’ is a code block

{P} c {Q}

“If the code is safe to run from then it is safe to run from the state ”

Q P

N × (Σ → Prop) → Prop

slide-10
SLIDE 10

Loop example

` (safe ⌦ EIP 7! i) ↵ i 7! JMP i It is safe to sit in a tight loop forever:

It suffices to show that if the loop is safe for k-1 steps (“later”) then it is safe for k steps (“now”)

Proof.

The “later” modality is due to [Nakano, 2000]

Löb Induction

10

` . safe ⌦ EIP 7! i ↵ i 7! JMP i

safe ⌦ EIP 7! i ↵ i 7! JMP i

safe ⌦ EIP 7! i ↵ i 7! JMP i `

.S ` S ` S

slide-11
SLIDE 11

Rule format

i..j 7! mov[r1], r2

safe ⌦ (EIP 7! j? safe ⌦ (EIP 7! i?

ptr

r1

v1

r2

v2

)

ptr

r1

v2

r2

v2

)

{ { } }

11

slide-12
SLIDE 12

Exceptions: mov as jumps

i..j 7! mov[r1], r2

safe ⌦ (EIP 7! i? )

ptr

ESP

j

r2

v2

)

{ { } }

Unmapped location

safe ⌦ (EIP 7! fail?

  • The IDT is present in the memory,
  • The record to the GPE links to the fail address

Invariant

ptr

ESP

? ptr

r1

!!

12

.

slide-13
SLIDE 13

mov ESI, info; mov EDI, [ESI]; mov [EDI], 0; add EDI, 4; mov [ESI], EDI.

Invariant

Unmapped

Store

?

fail

IDT GP Exception

ESI? ?

Memory allocator

Q2 Q1

safe ⌦ EIP 7! fail ? INTL 7! 1 ? ESP 7! s 4 ? 9ret.s 4..s 7! ret

safe ⌦ EIP 7! j ? INTL 7! 0 ? ESP 7! s ? s 4..s 7! sv ? 9p.EDI 7! p + 49unk.p..(p + 4) 7! unk

P

safe ⌦ EIP 7! i ? EDI 7! ? ESP 7! s ? s 4..s 7! sv

slide-14
SLIDE 14

Correctness of the Allocator

` ((safe ⌦ Q1 ^ safe ⌦ Q2) ! safe ⌦ P) ↵ i..j 7! c ⌦ R Theorem

Exception occurs Success IDT Precondition

14

Coq code

slide-15
SLIDE 15

Conclusions

  • We extended Jensen et al.’s formalisation to cover

programs with exceptions

  • The logic is robust: we didn’t need a new model/logic
  • I didn’t have time for showing: a lot of Coq code
  • Are interrupts effects or threads?
  • Concurrency as a primitive (CSL/Shared memory)

What do we do next?

Tianks!