[Music]
hello again everyone hope you had a
lovely break
um i know i spent my break investigating
all sorts of new like
open things that people are posting
about in in the chat so i hope you had
fun too
um okay so next up we have irving chipto
arsona um telling us about becoming a
tyrant
implementing secure boot in embeddable
devices
irving is an embedded systems engineer
he enjoys conjuring complex incantations
in an arcane language then casting it
into a spell and inserting it into a
piece of silicone with a magic wand
bringing life into the previously dead
hardware
in short writing c programs and
programming it with a jtag debugger
normally an endorsed person he can
occasionally be found chasing solar
calories down the stewart highway in the
australian outback
so irving's talk is pre-recorded
which means that irving will be in the
chat
during
the talk however
irving has asked that we saved the big
questions for the post chat q a um so
that they'll be in the recording um and
are available for anyone watching the
talk later so um irving will be in the
chat for any clarifications or
discussions but yet please also put any
any
any good questions in the questions tab
um
irving do you have a few words
um
yes um thank you for attending my first
ever lca talk and i'd like to thank you
people from linux research victoria that
has
encouraged me to submit and give me some
feedback that's all please enjoy my talk
hi everyone thank you for attending my
talk about becoming a tight run
implementing security booth in embedded
devices
i'm murfing and i want to talk about
secure booth because i've seen some
resources on how you might want how you
could implement security on the internet
but not much on why you might want to
have it
now this tool cover embedded devices not
big servers with ufi boot
there are some circumstances that are
different than embedded such as you
putting your code into the device that
will end up in somebody else with
physical access
the slides for this talk is available on
my website so if you see anything
interesting that i will show you later
you can just just grab the slots and
click the urls to go through them
now before we start there are some legal
bits to go through so all opinions in
this presentation are my own and not
from my employer or any other associates
all references are to publicly available
information and neither i nor my
employer takes any legal or commercial
responsibility that might arise from
anything in this presentation basically
i am not a lawyer so you should consult
with yours
now for those who are not familiar with
what secure boot is it's basically just
a chain of truss mechanism where one
something that's currently executing on
a cpu tries to verify the integrity of
the next thing it's supposed to execute
before actually executing it so for
example if you have a cpu that just
comes out of from bring power up and
it's actually getting its internal boot
rom
it will try to verify the integrity of
say the u-boot program that
that's it's supposed to run next before
actually jumping into it and executing
the u-boot binary
this this mechanism can be done
using either hashes like shj256 or
public keys like rsa or ecc
and this can provide some protection
against tampering
including from the physical side and not
just from
say the network
now
the factor obviously when we talk about
anything security the first thing we'd
ask is what's your thread model
because
this mechanism is basically just a tool
and whoever controls the keys or hashes
controls the entire process
now
the scenario that you often encounter is
that someone is locking you out from
your own hardware such as if you buy a
laptop or a phone that has everything
locked and you can't modify all the
software in it
but
but on the other hand since it's also a
tool it could be you that is locking
other people out from the devices that
you own
and that's why the question for skill
booth is always who should hold the keys
because
when
when you don't know your adversary you
need to figure out them first and so you
know how to use
this tool
correctly and it's important to
determine who has control and who has
not you should not have control
now
security booth is mainly useful for
preventing access or modification on the
lower level of the bootstack
but it's not necessarily the best tool
against net attacks from the network
because if you're somebody is attacking
a system from the network by the time
they get enough access to the timer with
the level bits they usually gain root
access anyway
and everything is already open to them
but let's start with hypothetical
scenarios so alice computers
makes laptops and software that runs on
it
and they want to control the software
that the users can run
so they lock their laptops with security
so
in this case ls computers is locking you
out from your stuff this is again
something that you might encounter in
real life
but consider a different scenario where
pop has a steel mill that's full of
custom control devices
and bob does not want more malware in
his control devices
so
bob being a technically savvy person
implement secure boots to lock his
devices inside his steel mill
and as a result bob is now the one
that's locking everybody else out from
his stuff
now let's look at the third scenario
dave owns a hydroelectric dam similarly
full of control devices and just like
bob he does not want malware in his
control devices
but
unlike bob dave is not tech savvy so he
asks carol to help him either
probably using a business contract or
something along something else
now carol can add secure boot into
dave's devices and holds the key for him
and the end result is
carol is the one that's locking
everybody else out of dave's stuff so
his stuff can run properly as expected
now you might notice that this scenario
seems to have something in common
which is that
these systems needs to be trustworthy
so
that's why you might want to use secure
boot to timber proof them and we talk
when you talk about timbre proofing and
transporting systems
the first scenario that might come to
your head is obviously anything that
requires finance info things financial
transactions such as atms where if your
software in an atm is
not is getting tampered they can be used
for skimming a customer's credit card or
worse could be subject to an attack like
jackpotting
where
you they can be told to just dispense
the contents
now if you're an atm manufacturer the
last thing you probably want is to see
one of your product being dragged on
stage by some bloke at black hat and
being controlled remotely to dispense
cast on its own
and secure boot will probably help with
this could help with this scenario
another similar device here are the f
terminals that you see on retail shops
and supermarkets
they can they can be reprogrammed to
scheme and steal card info or worse
you could play video games on them
such
and that's what that that picture is
pointing is showing is that somebody
managed to hack one of those systems and
put a little racing game on them
another
possible machine is of course the pokeys
or slot machines that
probably should work as expected
and of course your mobile phones that
has all your personal and financial data
and
another different category is of course
automotive control units and or
industrial controls devices that
controls heavy and powerful things cars
cranes industrial equipment steam
turbines
tampering with these can actually cause
injury death and legal liabilities in
real life
now you might think that if you own a
device you should be able to modify them
and i agree with you like if i oh if i
buy like a little router like this and i
want to be able to put in open wrt on
them to make them run the way exactly
why i want to
but
when it comes to this kind of heavy
machinery
you your tempering could actually hurt
yourself with your modifications like
this thing's not going to harm you the
worst it can do is just um spew out some
magic smoke but
if your car if you're tampering with
well let's let's if you're modifying
your cars
and then you somehow made it so the
volume button actually
presses the accelerator somehow then
you're not gonna have a very pleasant
experience when you want to
listen to loud music on the highway
but
this thing this thing can get worse
because while you can hurt yourself
you can also be heard from somebody
else's modifications
like if
imagine if you have how would you feel
if there are several oncoming car in the
opposite lane over over there that runs
modified ecu code and you don't know how
whether one of them is just going to
start swearing left and right because
the auto drive controls were tampered
with
so in this sense
you yes i think being able to modify
your devices is very good
but i'm not so sure when it comes to
opening up possibilities of injuries to
yourself or somebody else
and then you might ask what about fixing
bugs in those ecu's
which is extremely it's a valid concern
considering that there's things like
toyota acceleration case just if you
remember a couple years back there is a
lawsuit that allegedly says
that toyota engine control units could
cause acceleration on their own
but
again the flip side is
while manufacturers might have buggy
code they still have better test setups
than the end user for that code which
for a vehicle might involve
an entire engine with gas fuel and
everything running while being
instrumented
so
while you might be able to fix your own
code
sorry you might be able to fix the code
in those engines
there's no way for you to check for any
regression
so and i don't think even if they opened
up all of their setting there's not very
many people that will
procure an engine just to test the
validity of their modifications
so again the same same problem where you
i'm not so sure that
allowing
these
things to be edited is a very good idea
now at this point you might wonder hold
on this sounds like justifications for
vendor log in
which certainly can be done by using the
same timber proofing mechanism to lock
out competitors such as generic spare
parts third-party consumables or end
users trying to repair the thing that
they bought and owned themselves
the way i think about it is this is a
complex issue because both sides do have
a
reasonable
argument
on one side a third-party products might
be faulty or they might not be up to
spec or contain something dangerous as a
result of those
differences
and it's actually much safer if you went
with the first party product that has
been tested to work well with everything
else
that you have
but on the other side lack of
competition is very bad for customers
because once you're locked in
in something then you're at the merchant
whoever's locking you in
and so the question is at what point
does tamper proofing becomes lock-in
i'd say i don't know
it on one side things like safety
critical ecu's in the car you probably
don't want a third-party
things for that unless you're actually
rebuilding your engine from scratch or
something like that but um something
like a plastic clip like this for
hanging your coat you probably 3d print
it yourself
and
everything else in this
in between well i guess
the answer is as always it depends
on the scenario
that said while we talk about login
another use case for secure boot is to
help lock in secret inside the device
and help protecting them
what kind of secrets well you could have
for example user data in your phones you
might have authentication data for f
wash machines and setup boxes to top the
mothership you might try to protect
decryption keys inside the digital
camera protectors at your local movie
theater
or maybe you might want to protect the
software itself that's running inside
your device that you've spent a lot of
time and money on creating that secret
sauce and you don't want any competitor
to just jump uh stamp out mass
clones and mass while not putting in the
rnd effort
and what kind of protection that
security can provide
mainly
it is one of the few things that can
help against physical attacks
and to prevent reading out secrets from
the hardware
so
for example
if we compare with a microcontroller
like this
um come on focus
so microcontrollers like this tend to
have a readout protection by default so
if you program the internal flash in
this device
and you blew off the jtag fixtures you
can't
then you'll find it very hard to try and
extract the
data from inside it on the other hand
a embedded export like this has the cpu
and the memory and flash one of these
two chips
they're separate from the cpu they are
connected by traces on the pcb and they
can be
they can be sniffed
that's it
security's not very good for network
attacks for the reasons i've explained
earlier and when you're trying to defend
against net attacks from the network
it's basically an embedded linux device
it's no different from your servers that
are exposed to the internet
now you now you wonder why would you
need security for this because
we have a full disencryption well
this kind of full blob for file system
or full list encryption is usually not
enough for embedded devices
because you need the secure location to
store these decryption keys for these
secrets
and unlike desktop computers where you
can have a human coming in and typing in
the decryption password it usually you
usually expect your device to start up
by itself without a user entering a
password every time
and you also need to restrict the key
this key access only to legitimate
programs
so if that sounds this problem sounds
familiar to you you might be you might
have heard about trusted platform
modules or tpms
which are basically a dedicated security
chip that can keep a lot of secrets has
lots of timbre protection instead of
chips
and you can ask it to do crypto
operations like
signing
encrypting blob and so on and so forth
they're cheap they are
standardized so there's multiple vendors
for them and they come with the rich
software apis with things like open ssl
engines and whatnot
though that said they are secure but not
very fast so if you're thinking
of hooking up your ng next web server to
this as a back-end and thinking oh i'm
gonna my web server private keys are
gonna be super secure well your yes it's
gonna be secure but it's not gonna be
very fast
right
if you want to use a tpm
be aware that you should enable
parameter encryption which will encrypt
in communication or at least some
communication within the cv or tpm
otherwise you can an attacker could just
sniff it by a logic analyzer
and if you think attaching logic another
seems like a lot of trouble well
no it's not necessarily
for example i got here a logic analyzer
and this little
okay come on camera focus
logic analyzer and this little clip
right here
so for example if i got this random port
there
and you've got the
tpm chip somewhere that's on the same
path as that
that chip for example you can just use
this clip to
clip right there and now you can sniff
everything that goes
throughout that chip
there we go
oops yeah um they're not super strong
but
if you just leave them on the table and
not show them to a camera to the rest of
the world they work perfectly well
and also
a tip vm needs to be initialized by
something trustworthy they're not going
to start by themselves and
then start interrogating on what the
main cpu is using uh
executing
so for example let's take this scenario
we have uh that
we have encryption with a sectional tp
key storage and tpm or something else
and
there's a pro and secure but it's
enabled
so now we have a program right
right
there
that is
it has been verified so it's not
tempered
it will get the key from the key storage
and use it to decrypt the secret and
then it might
read the secret and use it to do things
and with the keyboard
an attacker can't really tamper with
anything here
in this sequence and i mean
this is all happening inside the main
cpu
but
if you don't use secure boot an attacker
could tamper with that program that's
asking the key from the key storage
and then he'll just decrypt the key into
the secret and instead of using it for
normal purposes he'll just upload it all
to the cloud and to the rest of the
whole world which is
usually not what you want
now while you've seen the advantages
you might want to consider some
disadvantages of secure boot as well
first of all
it needs a lot more development
resources
it need you need more engineering time
you need multiple hardware kit because
you might burn some of them and you
might need to deal with nds and export
controls all of these tech resources
that you could put towards
creating features or getting to market
earlier
you also has a rig 2 of bricking devices
because whenever you have
secure boot operational
you need to tell it to make a decision
what happens if you got verification
failure
should it stop working but keep all the
secret safe
or should it try to continue working
maybe in a degraded state even if it's
possibly compromised
this is probably another thing that is
application specific
where if you have an airforce machine
you probably wanted to die straight away
taking it secret with him
whereas
something that controls some machinery
you probably want to get into some sort
of safe mode
of some sort
another problem is that it makes it hard
to use gpl v3 software because one of
the requirements is that the end user as
in the
user that actually is in possession of
that device must be able to modify the
gplv code in the in the device not every
code in reverse just the gpl v3 ones
but even then it seems completely
contradictory to security because
you the idea is you want to lock
everything
prevent this kind of modification rather
in the first place
this does makes it harder but it's not
make doesn't make it impossible to
create
products that are
uh containing gprv3 software while still
complying with its licenses
now while i said it secured with is
helpful against physical attack it's not
foolproof
it does absolutely nothing against logic
analyzers like this
you might still attack the the cpu might
still be attacked by power analysis
the chips in this kind of linux devices
they might be disaltered and that might
open new attack factors
so
if you really are concerned against
physical attacks you might consider
covering everything in
a boxy potting compound or adding timber
detection circuitry
so that if the shell of the device is
open
you just wipe everything all the secrets
are gone
and lastly
things have security bugs and they can
be in software or in the hardware or in
the boot roms or in the
even in the tpm chip
and
these bugs can be impossible to patch
especially if they're in hardware so you
might have put all this effort into
securing and locking down your device
and then one cve later
your
your adversary could have
found a way in
now after waking the pros and cons you
might decide that yes you would like to
become a tyrant and to implement the qr
boot on your devices
well
i have some tips for you
first when you're looking at the
hardware stage
secure boot is always fender specific on
the very first stage because the boot
drums are all different on different
chips so start with the fender
instructions and
then modify it after you've gotten
something up and working
i'd recommend you getting multiple
hardware kits because you'll need to
burn the e-fuses on at least one of them
and you might want to test a different
sign build so
you might get
two devices like this
with one that's not modified and one
that has the
e-fuses burn and will verify
code and you might want to test how the
code behavior is different on both of
them
and you might also prick some of these
devices if you're programming them in
correctly so be prepared to lose some
and hopefully you'd lose none
jtag exists please remember that to make
sure the jtag fuses are also blown off
and
while you're dealing with hardware you
might also as well look at
if there's any hardware support that
mechanism for encrypting secrets
soms might have these mechanisms
otherwise you might consider adding a
cpm into your product
the second stage where you got start
dealing with boot loaders on amsterdam
this is usually you boot and you might
involve the fa or opt which are the
uh trustzone ultrasound stuff
if you're using ubud i recommend using
fit image it's very convenient because
it verifies the kernel device three and
in it driver fast together in one go
and it's not
a hardware or vendor specific so
you can reuse the effort you you you
have used on one hardware sorry on one
device on another device if they're
using different chips
that said you might want to disable the
environment input import and console
because they can be used to override the
boot scripts which
then can be used to timer with your
process
now
once you got to the initial fast and
really fast this is where you start
dealing with the encrypt dm verity or
integrity which is for encrypting or
verifying
file systems well not sell file stuff
they're blocked devices that sits under
the file stems
you might mix and match them depending
on how your device memory is what memory
kind of memory is present on your
devices be aware that dm verity implies
that you have a read-only partition
and once we go through that stage once
in it start then you're back in familiar
territory on how to secure linux systems
now
when you're
at build time
as in the os build time there's lots of
signing that could have been done then
and so if you're doing
uh build time signing keep the keys
secure on your field machines you might
want to use separate depth separate sets
of development and production keys to
keep the secure boot process always on
even on r d devices they'll get a lot
more stress test that way
and you
that also means that you don't have to
implement such a thing as disabling
secure boot which can be
can become a weakness
and if your device sorry if your som has
a real-time co-processor like a single
cortex m4 that's used for real-time
operations don't forget that those
processors could also access main memory
to some extent
so
if you make sure that the binaries that
are running in this course are
covered in your security process
now when you're implementing your
firmware update mechanism you really
should use signed images to provide
anyone inserting random code like you've
gone through all this effort to
secure your blue chain and surely you
don't leave the front or wide open
and
while you
well with signed side images make sure
that the public key is secured by
your security process so you got an
entire
chain of verification all the way from
the hardware to your firmware updates
if you encrypt those images you'd also
need somewhere secure inside the device
to store the keys that will be used to
decrypt them
when it comes to time to mass
manufacture your device be aware that
locking the software or some interfaces
could limit your flexibility when it's
design comes to designing your
manufacturing process for example if you
need jtag to check the test the
connections between some chips on your
board be aware that you need to
test this before locking the software
and the jtag interface because you can't
do it otherwise and you might on the
other hand you might find that it's
slightly safer to
generate private keys inside the device
after you lock the device
so with that in mind
it's
much
i would highly recommend designing your
mass manufacturing process early
roughly around the time when the
security process is also designed
uh one thing that makes it easier is if
you have
a
a trusted environment in your factory
whether it's your trustees you got some
trusted staff network or just a
dedicated dedicated section because that
reduces the number of threat factors
that you have to deal with
lastly if you happen to use a
soms like this system on modules
now you
you might get some extra flexibility
because this thing allows you to use a
separate programming hardware and
versus the real hardware so you might do
your mass manufacturing and programming
sorry mass programming on
these soms in one go and then test the
real hardware separately and then just
combine the two later in the late in
in a different step
and lastly with gplv3
restrictions
there's two approaches that i'm aware of
there could be more one is to ban
gpl v3 in your device and only use all
tpl php2
but of course you're missing out on the
latest and greatest features and
security fixes on things like bash or
utils star gb server and
tracing mechanisms
you might get away with using
alternatives with pc box or c shell or
maybe
just by ensuring that nothing really
uses them
so that they can't do much harm
otherwise alternatively you might allow
updating the gplv3 codes for people that
want it so you might provide an option
for disabling secure boot and turn the
device into some sort of dev kit mode
that self erases the secret keys and
whatnot
now if you want to dig deeper then i can
i have a few things that i can recommend
to you which hopefully saves you some
digging around in google and whatnot i'm
just gonna gloss over them quickly
because you then you can check them out
for yourself from
once you've got the slides
so if you want if you happen to do
secure boot on nxp imx6 or 7 platform
there's this stock that i will tightly
recommend you to watch
and of course the
the official application notes are very
useful
uh if you're dealing with verified with
yubit in addition to the official
documentation in the kids repositories
these two presentations could help you
understand how it works and how to
implement it
if you're thinking of including gplv3 in
embedded i would highly recommend this
presentation because it covers exactly
this topic and even covers
some
automotive use cases
now if you're curious about the atm or
fps attacks that i showed you earlier
you can check out these videos and
possibly even more in the black hat
defcon conference past talks
if you want to find out more about tpms
there's a tpm tutorial from google
called tpmjs
no it's not a dpm implementation in
javascript
there's also a book which happens to be
free actually
that you can read about
and the tpm2 software community has a
lot of useful links
as well
and lastly if you want some real world
examples of the security incidents
you
there's an excellent talk on from ars
technica about
bypassing a security security in the
laptop that has a tpm enabled
there's the book about stuxnet
that is a highly recommended read and
there's
also
uh the expert witness
reports in the toyota acceleration case
if you are
interested in an analysis of the
software that runs
in this kind of industrial automotive
environment
and if you're interested in some
renovated cves there is one that affects
the boot drone in nxp imax chips there's
another one that affects the infinion
chips such as their tpms and security
smart cards and there's also a software
one that's affecting security in you
boot
and that is the end of the talk thank
you very much for watching and hopefully
i have given you enough resources so
that you too
could become a tyrant thank you very
much
irving that was beautifully put together
um as is your laurels which you have
earned
thank you um
so we have a few questions uh the top
question at the moment is
are there any raspberry pi class and
price devices that support secure boot
and tpm
okay good question um
you
i'd say instead of looking at the
devices look into the chips that are
used in those devices the ones that i
knew do support it and are relatively
well documented are from the
using nxp's imx67 or eight
um in for tpms you can actually buy
little tpm modules that just plugs into
a raspberry pi i mean it's not soldered
in but if you want to play around that
works perfectly well
great
um next question
where do you get the clips that
intercept the chip pins for the logic
analyzer
oh
that one comes from i believe uh
element14 or you can or rs components
dgk probably have them as well
they're made by pomona electronics p.o
papa oscar mike oscar
november
alpha pomona
ah
you're much better at remembering that
um
that alphabet quickly than i am
um
so the next question is can these
techniques apply to vms
um
short long story short i don't know
because i'm not an expert on vms in
theory if you have a chain that goes
beyond your hypervisor and it keeps
verifying things using hashes or skis
then it will be possible i'm not aware
of which
implementations exist at the moment for
that that said um if you were thinking
of
if you're thinking about embedded
contacts and thinking about putting vms
in your embedded devices i would have
asked why would you want to do that
that sounds like a very interesting use
case please share it
for the post chat talk discussion
post talk chat discussion
get my words in the right order
um
the next question we have we have a good
bit of time for quite a few questions so
we're going all right
how do we balance the need for security
with the need for openness always the
question
oh it's it's always the question and i'm
afraid my best guess is it depends
um
so secure put at at the end of the day
it's basically just a tool that could
restrict access
and
regarding where when and where the tool
should be used is
a different question on how to you you
want to use the tool
so i
i i i've read that a
separate can of worms that has existed
all the way since what the richard
stallman protested the use of passwords
you see a login using passwords
yeah i think i think that one is a
question you have to ask every time you
do anything one
and if there was a nice solution we
wouldn't still be wondering
but it is a good question to be
constantly asking
okay next up
can you summarize the issue with gpl um
three versus gpl two in a couple of
sentences please
uh okay so i guess
for
gps the new thing about tpl v3 is it has
a clause that basically correct me if
i'm wrong and again i'm not your lawyer
it basically requires that if you give
somebody a device that contains code
that's licensed gplv3
the
person who has that device must be able
to replace that tpl v3 code
with their unmodified versions only the
gplv3 not necessarily the rest of the
device and
that's
that's why usually if you lock gpl v3
code using secure boot then the end user
can't replace it
uh
the top that i link the presentation
that i link just explain it in a much
better way than i can so i highly
recommend you check it out since this is
a there's a very very subtle nuances
that i didn't even realize until i
started reading that as well
what's your take on the new pluton chip
edition by ms for intel amd arm chip
cpus to do tpm within the cpu
so many tlas sorry about that
uh let's see
just pasting that okay so
intel amd
cpm within the cpu um
i think
from what i've read the from what little
i've read so far it gives the
ability to store secrets and it can
basically does the tpm stuff that's tpm
standard cpu that sounds like something
the imx chips has been able to do for a
long time now so it's
less about
what the chips are capable of how it
ends up being used
so it could be used for
good i guess it could be used for
not very good purposes it could be used
to again it could be used to lock you
out from the cpu that you have but
it could be used for you to lock
everybody else from the cpu that you
have as well i think
next question
uh with a separate tpm when you enable
encrypted commands between the tpm and
the cpu how is the logic analyzer
prevented from seeing the keys that
encrypt the rest of the communications
okay
how does so basically you're asking how
the parameter encryption works um i
i'd recommend you check the manual
because i wasn't the one implementing
that so
so sorry i can't give more details
there's always
reference documentation for that yeah
but i'm if
but if my best guess if you're if you're
willing to listen is that it's probably
the similar to tv hellmann exchange
where you can
generate something split them in half
and exchange them and then you got the
secret that somebody sniffing in the
middle won't
won't be able to guess
but that's that's a guess please check
what the actual thing does
okay
um the last question we've got right now
um although we've got time for another
couple if anyone wants to post one
before irving done answering this one
is does using hashes hinder updating
does using oh for for boot for secure
boot
yes it does so
that's the
i believe there's
some complication with using uh tpm pcr
hashes if you want to update bios or
something like that which i'm not an
expert in but yes it could uh
complicate updating firmware
that's why
i think using
public case to file that you can
validate them the
you can validate the next component
using hashes
and then you just just verify that the
hash matches the signatures
okay
well um that's all the questions we have
um so
thank you irving
for such a
fascinating and well put together talk
um you've done
exceedingly well for your first lca tech
oh wait any questions just come in hang
on hang on
uh with the increasing interest in risk
v cpu architecture do you think a tpm
module that is part of the cpu design
would be useful
uh yes because it
i think uh the capabilities of a tpm
will be very useful if it's integrated
inside the cpu because you just don't
need to worry about that sleeping
uh significant communication between the
two whether that gets used for
locking you out or you locking somebody
else out is another question
yes
that's that's how it is with most things
in life
yeah of course
all right okay now we will really will
wrap it up um
so yes thank you so much irving
thank you for everybody listening
see ya