After working with UEFI over the last 18 episodes of the MinnowBoard Chronicles, Iโve decided to install Linux on my MinnowBoard. It is turning out to be harder than I thought.
The news is out! Intel today announced its Intel Xeon Processor Scalable Family, codenamed Purley or Skylake-EP.
ASSET of course has supported this silicon since its earliest beginnings, with the SourcePoint and ScanWorks Embedded Diagnostics products.
Read the full press release here: ASSET releases new benchtop and remote debugging applications for Intel Xeon Processor Scalable Family.
In two previous articles, I looked at the JTAG access port from a security perspective, and considered what exposure the choice of BMC operating system might have on a platform supporting At-Scale Debug. Now, letโs consider the root of all trust, the silicon itself, and see what options exist for locking it down.
Given that they are network-accessible, BMCs present an attack surface. Which operating systems are hardened enough to be secure against malicious actors?
Security through obscurity is not a meaningful means to mitigate malevolent attacks. With the greater forensics capabilities offered by At-Scale Debug (ASD), how are platforms protected?
In my last article, I used Last Branch Record (LBR) Trace to manually capture UEFI program flow source and destination addresses. This week, I look at the associated instruction opcodes and mnemonics and try to figure out what is going on.
My curiosity got the better of me this week. I decided to play detective, and see what I can learn from LBR trace data if I pretend I donโt have access to the source code.
This week, I decided to do a thorough analysis of how Last Branch Record (LBR) trace works, to see how useful it is in tracing back what might be the root cause of system failures.