We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

TrustZone is not enough

00:00

Formal Metadata

Title
TrustZone is not enough
Subtitle
Hijacking debug components for embedded security
Title of Series
Number of Parts
167
Author
License
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
This talk deals with embedded systems security and ARM processors architecture. Most of us know that we can perform security with the ARM TrustZone framework. I will show that most ARM processors include debug components (aka CoreSight components) that can be used to create efficient security mechanisms.
Keywords
7
Thumbnail
30:34
12
Thumbnail
55:26
43
61
Thumbnail
1:05:55
78
Thumbnail
1:01:42
83
92
Thumbnail
33:27
110
Thumbnail
31:25
141
Thumbnail
31:11
147
Thumbnail
31:30
InformationPascal's trianglePhysical systemInformation securityMultiplication signGoodness of fitChemical equationComponent-based software engineeringImage resolutionSoftwareArmSpywareCoprocessorComputer animationLecture/Conference
Presentation of a groupLink (knot theory)Pascal's triangleStudent's t-testField programmable gate arrayReverse engineeringSoftwareIntegrated development environmentClifford algebraRhombusPhysical systemRepresentation (politics)Slide ruleView (database)Information securityInformation retrievalBitLink (knot theory)Student's t-testComputer architectureComponent-based software engineeringCoprocessorMassArmMereologyLecture/ConferenceComputer animation
Reverse engineeringComputer virusForm (programming)Formal verificationToken ringIntegrated development environmentSoftwareLecture/Conference
Pascal's triangleOpen sourceReverse engineeringMultiplication signProcess (computing)Slide rulePhysical systemJSONXML
FirmwareArmPhysical systemBuildingInformation securityVideo game consoleHorizonComponent-based software engineeringCASE <Informatik>Personal digital assistantComputer hardwareInformation securitySoftware frameworkSoftware
State of matterFluid staticsMathematical analysisCASE <Informatik>Software frameworkInformation securityNintendo Co. Ltd.Physical systemPresentation of a groupResultantLevel (video gaming)Projective planeComponent-based software engineeringRight angleContext awarenessMikroarchitekturMereologyLecture/Conference
Information securitySoftwareBefehlsprozessorSystem on a chipField programmable gate arrayPeripheralSource codeInformationAerodynamicsVideo trackingDataflowProcess (computing)Heat transferPhysical systemLink (knot theory)Medical imagingExecution unitLogicProcess (computing)MereologyRectangleSystem on a chipDynamical systemComponent-based software engineeringMulti-core processorFunction (mathematics)DataflowInformationInternet service providerCoprocessorProgram flowchart
DataflowAerodynamicsVideo trackingInformationProcess (computing)Heat transferInformationCodeProcess (computing)Heat transferDataflowInstance (computer science)TrailMetadataBlock (periodic table)Lecture/ConferenceXML
Category of beingBitState of matterLevel (video gaming)InformationBlock (periodic table)MereologyGraph coloringInformation privacyMixed realityFlow separationLecture/Conference
Data bufferRead-only memoryAddress spaceControl flowCompilation albumCodePhysical systemComputer fileBuffer solutionCodeOperator (mathematics)outputInformationGraph coloringCompilation albumComputer fileResultantSubject indexingRootPasswordInstance (computer science)Functional (mathematics)Variable (mathematics)Address spaceLine (geometry)Bus (computing)Slide ruleMereologyRule of inferenceAssembly languageKey (cryptography)Letterpress printingSummierbarkeitCore dumpComputer animation
InformationINTEGRALOperating systemPhysical systemService (economics)RankingLecture/Conference
RAIDLevel (video gaming)ImplementationIntrusion detection systemTrailMikroarchitekturDynamical systemInformationLevel (video gaming)Android (robot)DataflowJava appletCartesian coordinate systemComputer hardwareInstance (computer science)Charge carrierProcess (computing)Traffic reportingXML
Core dumpExecution unitLevel (video gaming)TrailDataflowInformationDynamical systemMultiplicationSource codeProcess (computing)Arithmetic logic unitComputer fileFigurate numberSet (mathematics)WebsiteCellular automatonGroup actionCodierung <Programmierung>Normal (geometry)LogicCoprocessorExecution unitCodeRight angleComputer animationLecture/ConferenceProgram flowchart
CoprocessorAerodynamicsCore dumpBefehlsprozessorFood energyInformation securitySoftwareTheory of everythingPhysical systemTelecommunicationOverhead (computing)Limit (category theory)Mathematical analysisSoftware frameworkBinary fileMeasurementChemical polarityLevel (video gaming)Transformation (genetics)ArmFrequencyInterface (computing)Video game consoleSoftware testingComputer programLogicProcess (computing)Stack (abstract data type)Memory managementEnterprise architectureComponent-based software engineeringRead-only memorySlide ruleCodeMeasurementComputer programmingTransformation (genetics)CASE <Informatik>Different (Kate Ryan album)MereologyRevision controlCartesian coordinate systemQuicksortData structureInformationBitInstance (computer science)Operator (mathematics)Process (computing)Black boxRun time (program lifecycle phase)Dynamical systemInformation securityAuthorizationWordTerm (mathematics)Game controllerDensity functional theoryGroup actionFigurate numberSystem on a chipMultiplication signPairwise comparisonDiagramMaxima and minimaLink (knot theory)Enterprise architectureOverhead (computing)NumberCore dumpCoprocessorBefehlsprozessorField programmable gate arrayPhysical systemTelecommunicationNormal (geometry)DataflowRadical (chemistry)SoftwareArmTrailLevel (video gaming)Bus (computing)Table (information)Moment (mathematics)Computer hardwareLine (geometry)
Web pageArmTheoremPredictionInternational Date LineComponent-based software engineeringSource codeBlock (periodic table)Physical systemMenu (computing)System on a chipCore dumpDemoscenePhysical systemWeb pageComponent-based software engineeringBefehlsprozessorCASE <Informatik>Presentation of a groupSemiconductor memoryAxiom of choiceRectangleMultiplication signSet (mathematics)Different (Kate Ryan album)Rule of inferenceParameter (computer programming)Line (geometry)BlogInformationInformation securityTracing (software)Process (computing)MereologyMassLengthView (database)Time zoneMixed realityArmField programmable gate arraySystem on a chipBuffer solutionCoprocessorXML
Semiconductor memoryRule of inferenceFunction (mathematics)Tracing (software)Lecture/Conference
Computer programEmailSheaf (mathematics)Core dumpCodeDigital filterDevice driverWeb pageBranch (computer science)Context awarenessCycle (graph theory)Source codeAddress spaceCodierung <Programmierung>SynchronizationDataflowGraph (mathematics)Mathematical analysisFluid staticsArmSimultaneous localization and mappingRead-only memoryData recoveryStrategy gameTable (information)LogicCoprocessorHexagonMemory managementStack (abstract data type)Enterprise architectureProcess (computing)Physical systemComponent-based software engineeringTelecommunicationOverhead (computing)SoftwareReduction of orderBefehlsprozessorDijkstra's algorithmFast Fourier transformAdvanced Encryption StandardRun time (program lifecycle phase)Modul <Software>Parallel portConfiguration spaceAverageBenchmarkRule of inferenceResultantLine (geometry)Mathematical analysisTracing (software)CodeCoprocessorSemiconductor memoryField programmable gate arrayTheory of relativityCASE <Informatik>Strategy gameLoop (music)WordAddress spaceInformationGame controllerOverhead (computing)TelecommunicationBranch (computer science)Physical systemMultiplication signTrigonometric functionsMereologyComponent-based software engineeringIterationComputer programmingSheaf (mathematics)Exception handlingPointer (computer programming)Instance (computer science)TransmitterReal-time operating systemSpeicheradresseAssembly languageBroadcasting (networking)In-System-ProgrammierungPort scannerPatch (Unix)Fluid staticsInsertion lossFunction (mathematics)Term (mathematics)Casting (performing arts)Film editingFront and back endsView (database)Internet forumDomain nameFreewareDistanceGreen's functionArmGraph (mathematics)AdditionStapeldateiMessage passingPhase transitionType theoryXML
Strategy gameOverhead (computing)Fast Fourier transformNumberRead-only memoryInformation securityArmCoprocessorComponent-based software engineeringAreaAuthorizationLogic gateBefehlsprozessorPower (physics)FrequencyPairwise comparisonTelecommunicationClefHexagonCodeGraph (mathematics)Compass (drafting)Line (geometry)InformationPairwise comparisonPhysical systemMultiplication signActive contour modelCellular automatonCASE <Informatik>Table (information)FrustrationNumberAreaOverhead (computing)Latent heatTheory of relativityField programmable gate arrayBefehlsprozessorGame controllerCoprocessorLecture/ConferenceComputer animation
Run time (program lifecycle phase)InformationOverhead (computing)TelecommunicationInformation securityPerspective (visual)Core dumpExtension (kinesiology)BefehlsprozessorMultiplicationComponent-based software engineeringIntelScanning tunneling microscopeMultiplication signInformationRun time (program lifecycle phase)BitComponent-based software engineeringCartesian coordinate systemInformation securitySoftwarePerspective (visual)Multi-core processorComputer animationXMLLecture/Conference
Intrusion detection systemPascal's triangleInformationLatent heatSpacetimeDataflowMicrocontrollerTrailCASE <Informatik>Multiplication signXMLLecture/Conference
System programmingHypermediaMultiplication signBitPascal's triangleCoefficient of determinationRoundness (object)Lecture/Conference
Transcript: English(auto-generated)
So, the next talk will be about embedded system security and Pascal, the speaker, will explain
how you can hijack debug components for embedded security in ARM processors. Pascal is not only an abandoned software security engineer, but also a researcher in his spare time, so please give a very, very warm, welcoming good morning applause
to Pascal. Okay, thanks for the introduction. So, as it was said, I'm an engineer by day in a French company, so I work as an embedded system security engineer, but this talk is mainly about
mass Python activity, which is a researcher, whatever you call it. This is because this talk I worked with a PhD student called Muhammad Adulgharab, and he was a third-year PhD student in the French lab, so this talk will be mainly a representation on this work about the embedded system security,
and especially the debug components available in ARM processor. Don't worry about the link, at the end there will be also the link with all the slides, the documentations, and everything. Before the Congress, I didn't know about what kind of background did you need for my talk,
so I put there some links, I mean some references of some talks, where you will have all the vocabulary needed to understand at least some parts of my talk. So yeah, about the computer architecture and the embedded system security, I hope you had attended the talk
by Alistair about the formal verification of software, and also the talk by Keegan about trusted execution environments, so VTE, search, and in this talk I will also talk about FPGA stuff, and about FPGAs, so there was a talk on day two about FPGA reverse engineering, and if you don't
know about FPGAs, I hope that you have some time to go to the FPGA assembly, because these guys are doing a great job about FPGA open source tools. So yeah, when you see this slide,
I mean the first question is that why I put Trozone is not enough. Just a quick reminder about what is Trozone. Trozone is about separating a system between a non-secure world in red, and the secure world in green, so when we want to use the Trozone framework,
we have lots of hardware components, lots of software components, allowing us to let's say to run separately a secure OS and a non-secure OS. In our case, what we wanted to do is to use
the debug components, you can see it on the left side of the picture, to see if we can make some security with it. Furthermore, we wanted to use something else than Trozone, because if you
attended the talk about the security in the Nintendo Switch, you can see that the Trozone framework can be let's say bypassed under specific cases. Furthermore, this talk is something quite complementary, because we will do something at a low level, I mean at a low level,
at the processor architecture level, so I will talk in a later part of my talk about what we can do between Trozone and the approach developed in this work. So basically the presentation will be a quick introduction. I will talk about some works aiming to use debug components to make
some security. Then I will talk about Armex, which is the name of the system we developed to use the debug components in Harper Store, and finally some results and the conclusion. So yeah, in the
context of our project, we were working with system-on-ships. So system-on-ships are this kind of device where we have in the green part a processor, so it can be a single core, a dual core, or even a quad-core processor. And another interesting part which is in yellow in the image
here is the programmable logic, which is also called an FPGA in this case, and in this kind of system-on-ship, you have the output processor, the FPGA, and some links between those two units.
And so you can see here in the little red rectangle, one of the two processors. So yeah, this picture is an image of a system-on-ship called ZYNC, provided by Xyninx, which is also an FPGA provider. And this kind of ship, we usually have two Cortex-9 processors and some FPGA logic to work with.
So yeah, so what we want to do with the debug components is to work about dynamic information flow tracking. So basically, what is information flow? Information flow is the transfer of information
from an information container C1 to C2 in the given process P. So in other words, if we take this simple code over there, if you have four variables, for instance A, B, W, and X, the idea is
that okay, if you have some metadata in A, the metadata will be transmitted to W. In other words, what kind of information will we transmit into the code? Well, basically, the information I'm
talking in the first block is okay, this data is private, this data is public, and we should not mix data which are public and private together. So basically, we can say that the information can be a binary information which is public or private, but of course, we will be able to have
several levels of information. In the following parts, this information will be called taint or even tags, and to be, let's say, to be a bit more simple, we will use some colors to say okay, my tag is red or green, just to say if it's private or public data. So yeah,
so as I said, if the tag contained in A is red, the data contained in W will be red as well, and the same thing for B and X. If we take a quick example over there, so if we look
at a buffer overflow, so in the upper side of the slide, you have the assembly code, and on the lower part, the green column will be the color of the tags, and on the right side of these
columns, you have the status of the different registers. So this code is basically okay when my input is red at the beginning, so basically we just use the taint input into the index variable, so basically the register 2 which contains the IDX variable will be red as well, and then
when we want to access a buffer IDX, which is the second line in the C code at the beginning, basically the information there will be red as well, and of course the result of the
operation which is X will be red as well. So basically that means that if there is a tainted input at the beginning, we must be able to transmit this information until the return address of this code, just to say okay if this tainted input is private, the return address at the end of
of the code should be should be private as well. What can we do with that? There is a simple code over there, so this is a simple code saying okay if you are a normal user in your code, you would just have to open
the welcome file, otherwise if you're a root user you must open the password file, so this is basically to say okay if we want to open the welcome file, this is a public information you can do whatever you want with it,
otherwise if it's a root user maybe the password will contain for instance a cryptographic key, and we should not go to the printf function at the end of this code, so basically the idea behind that is to check that the fs variable containing the data of the
file is private or public, so there are mainly three steps for that. First of all the compilation will give us the assembly code, then we should modify, well we must modify the system calls to send the tags, so the tags will be as I said before the
private or public information about my fs variable, and I will talk a bit about that later but maybe in future works the idea is to make or at least compile an operating system
integrated with integrated support service for the IFT, so there were already some works about dynamic information flow tracking, so basically we should do this kind of information flow tracking in two manners, so the first one at the application level, so basically working
at the java on android level, some works also propose some solutions at the os level, for instance kblair, but what we wanted to do here is to work at a lower level,
so this is not at the application of the os level but just at the hardware level or at least at the processor architecture level, so if you want to have some information about the os level implementation of information flow tracking you can go to blair-ideas.ro
where you have some implementations of an android port and the java port of intrusion detection systems, so yeah in the rest of my talk I will just go through the existing works and just see what we can do about that.
When we talk about dynamic information flow tracking at the low level there are mainly few approaches, the first one is the one in the left side of the slide, so basically
the idea is to say okay in the upper side of this figure we have the normal processor pipeline, so basically decode stage and register file and arith 20 and logic unit and the basic idea is to say okay when we want to process with tags or taints we just
duplicate the processor pipeline, so basically with the gray pipeline under the normal one just to process data and it implies two things, first of all we must have the source code of the processor itself just to duplicate the processor pipeline and to make the let's say the DFT
pipeline, so this is quite convenient because we must have the source code of the processor which is not really easy sometimes
and otherwise let's say the main advantage of this approach is that okay we can do nearly anything we want because we have access to all codes so we can pull all wires we need from the processor just to get the information we need. On the second approach so this is the right
side of the picture there is something a bit more different so instead of having a single processor aiming to do the normal application flow plus the information flow tracking we should separate the normal execution and the information flow tracking so this is the second approach
and this approach is not satisfying as well because you will have one core running the normal application that's okay but the sub-core number two in the figure over there will be just able to make DFT controls so basically it's a bit of shame just to use
the processor just to make some DFT controls so let's say the best compromise we can do is to make a dedicated coprocessor just to make the information flow tracking processing so basically the most interesting part of this topic is to have a main core processor aiming to
just to make the normal application and the dedicated coprocessor just to make the IFT controls and you will have some communications between those two cores. So yeah basically if we want to make a quick comparison between different works so if you want to run the dynamic
information for control in pure software I will talk about that just in the in the slide after but this is really really I mean really painful in terms of time already because you will see that the time to do information for tracking in pure software is
really unacceptable and regarding the hardware assisted approach the best advantage in all cases is that we have a lower overhead in terms of silicon era that means that on this slide the the overhead between the main core and the main core plus the coprocessor is not
is not so important and we will see that in the case of my talk we will see that the dedicated the IFT coprocessor is also is also let's say is also easier to to to get some
different security policies so yeah as I said in in the pure software solution so the first line of this table the the basic idea is that is to use instrumentation so if you're there on day two instrumentation is basically the transformation of a program into its own measurement tool so
basically that means that we will put some sensors in all parts of my code just to just to monitor this activity and gather for some information from it so basically if we want to measure the impact of instrumentation on the execution time of an application you can see in
diagram over there the normal application level which is normalized to one and when we want to use instrumentation with it the minimal overhead we will have is about 75 percent so basically it will let's say the time with instrumentation will be most of the time it
will be twice higher than the normal execution time so this is completely unacceptable because it will just run slower your your application so basically yeah as I said the main uh the main
concern about my talk is about reducing the overhead of suffering termination I will talk also a bit about the security of the DFT coprocessor because we can't we can't include a DFT coprocessor without taking care of its security and this is uh accounting to my to my
knowledge this is the first work about DFT in a harm-based system and chips on the on the talk about the security of the nintendo switch the speaker said that black bus texting is that except that it isn't in our case we have we have only a black box because we can't modify the structure of the processor we must
make our job without let's say decapping the person and so on so basically this is another schematic of our architecture so on the left side we've in light green you have
the arm processor so basically in this case this is a simplified version with only one core and on the right side you have the structure of the of the coprocessor we implemented in the fpga so basically you can notice for instance uh for for the moment sorry two things the first
is that you have some links between the fpga and the cpu these links are already pre already existing uh in in the system and chip and you can see another thing is that uh regarding the memory you have separate memory for the uh for the processor and for the fpga
and we will see later that we can use trust zone in vehicle set just to add the layer of security just to be sure that we want we want let's say mix the memory between the cpu and and the fpga so basically we want to work with um uh we have armpus so we must use uh arm data sheets
we must read arm data sheets and first of all don't be afraid by the length of arm data sheets because in my case i used to work with the arm v7 technical manual which is already 2 000 pages the arm v8 manual is about 6 000 pages anyway um and of all of course
what is also difficult is that the information is split between different documents anyway when we want to use the debug components in the case of harm we just have this register over there which
is called dbg blah blah blah so we can see that in this register we can say that okay writing the key value uh 0 c5 a blah blah to this will lock the debug register and if you write any other value it will just unlock those debug registers so that was basically the first step
to um to uh to enable the debug components was just to uh to write a random value to this register to this register just to unlock my my debug components so uh here is again the let's say a schematic of the overall system at ship
so as you can see you you have let's say the trooper and on the top part you have what are called the cross-site components so these are the famous uh debug components i will talk about in the second part of my talk so here is a simplified view of the debug components we have
in uh in zinc socs so basically uh on the left on the left side we have the two processors so the cpu 0 and cpu 1 and all the cross-site components are ptm so the one which is the in the red rectangle and also the ect which is the embedded cross trigger and the
itm which is the instrumentation trace microcell and basically when we want to let's say extract some data from this cross-site components the basic the basic path will be okay we will use the ptm and we will follow the red line go through the funnel and at this
step we'll have two choices to store the information taken from from debug components the first one is the embedded trace buffer which is a small memory embedded in the processor unfortunately this memory is really low because it's really small sorry because it's only about
four kilobytes as far as i remember but the other possibility is just to export some data to trace packet output and this is what we will use just to export some data to the uh to the processor to the corpuscle sorry implementing in the nvfpga so basically what ptm is able to do
the first thing that ptm can do is to trace uh whatever you can whatever you want in your memory for instance you can trace all your code so basically all the blue all the blue sections but you can also um you you can also let's say trace a specific region of the code so basically
that means that you can say okay i just want to trace the code in my section one on say or section two or section n then the ptm is also able to make some branch broadcasting that is something that was not presented during the scanner so we already submitted a patch
that was accepted to uh to uh to manage a branch broadcasting uh into the ptm and we can do some time style time stamping and other things just to be able to to store the information in the traces so basically what the traces what the trace
looks like so here is the most simple code we could had is just a for loop doing nothing so basically the assembly code over there and the trace will look like this so uh in the in the first let's say in the first uh five bytes we'll have uh some some kind of start packets
which is called the async packet just to say okay this is the beginning of the trace uh in the green part we will have uh the address which correspond to the to the beginning of the loop and in the orange part we will have the branch address packet so you can see that you have
10 iterations of this branch address packet because we have 10 iterations of the for loop so this is just to show what is the general structure of of a trace yeah so in other words this is just a control forgot just to say what we could have about
this so of course if we have another loop at the end of this control forgot it will just make the trace a bit longer just to add the information about the about the second loop and so on once we have all these traces the next step is to say okay i have my tags but now
how do i uh let's say define the rules between uh between an institution in nova just to transmit my tags and this is where we will use static analysis for this so basically in this example if we have the instruction okay just do uh help register one plus register two
and put the result in register zero so for this we will use uh static analysis which allows us to say okay the tag uh the tag associated with register zero will be the tag of register one or the tag of uh or register two and a static analysis will be done before running my code just
to say okay i have all the rules needed for all the lines of my code so now that you have the traces we know how to transmit uh the tags all over my code the final step will be just to make the static analysis in via in vlvm back end and the final step will be about instrumentation
so as i said before we can uh we can recover all the memory addresses we need through instrumentation otherwise we can also uh in the in the second possibility we can also only uh let's say get the register relative memory addresses for instrumentation
in the first case on this simple code we we can basically just just say okay we instrument all the code but the main uh the main drawback of this solution is that okay we it will completely uh it will completely access the the time of the exception otherwise what we can do
is that okay uh we've uh with the restore section over there we can get uh data from the trace so basically we will use the program counter address from the trace and then for the stack pointer we will use the static analysis to get information from the stack pointer and finally we can use only one instrumented instruction at the end
so if i go back to this uh to this system yeah the communication overhead will be uh the main uh let's say the main drawback uh as i said before because okay uh if we have over there the processor and the fpga are running
in in uh in different parts the main let's say problem will be how we can transmit data in real time or at most at least in uh in in the isp we can between the processor and the fpga
so yeah uh the ptm uh so this is the let's say the time of red when we enable across our components or not so basically in blue we have uh the the time of red let's say the basic time of red when the traces are disabled and we can see that when when we enable traces uh the time of red is nearly uh is nearly negligible
yeah regarding time instrumentation we can see that regarding the strategy two which is uh you are using the cosine components using the static analysis and the instrumentation we can lower the instrumentation overhead from 53 percent up down to five percent so this is basically
okay we still have some uh overhead due to instrumentation but it's really low compared to the related rocks where all the code was uh instrumented and this is an overview that
show us that in the graylands you have some uh some overheads of related rocks with full instrumentation and we can see that in our approach with the green uh the green lines over there that the overhead the time already with with our code is much much smaller sorry
so yeah so basically uh how we can use uh how chosen is this so this is just an overview of our system and we can say okay we can use frozen just to separate the cpu from the from the fpga capacitor so if we make a comparison between with related rocks
we can see that compared to the first works we are able to make some information for control with a hard compressor which is which was not the case with uh with the two first trucks uh in this table so it means that okay you can use a basic compass just to make the information
for tracking instead of having a specific processor and of course uh yet the area of it which is another important topic is much much slower compared to the extending worse so it's time for the conclusion so yeah as i presented in this talk we are able to use the
component just to obtain runtime information about my application this is a non-intrusive tracing because we still have a negligible performance of red and we also improve the software security just because we were able to make some security on the corpus so the future perspective about
that is to mainly to work with a multi-core processor and to see if we can use the same approach for intel and maybe st micro controls to see if we can also do information flow tracking in this case so that was basically for my toast thanks for listening thank you very much for this
talk unfortunately we don't have time for q and a so um please if you leave the room
take your trash with you and make the angels happy i was a bit long yeah huh i was a bit long my dog and another round of applause for pascal