Ghosts of GUID's past. This post, like, many of my recent ones, walks backward in time. Recent events usually stir these memories. If you're not such a fan old these mutterings, I'd pass on this mid-month posting.
To begin, I couldn't help but remember
https://trustedcomputinggroup.org/wp-content/uploads/Platform-Reset-Attack-Mitigation-Specification.pdf during the F-Secure talk at Blue Hat https://www.microsoft.com/en-us/msrc/bluehat-conference recently.
That MEMORY_ONLY_RESET_CONTROL_GUID was GuidGen.exe'd https://blogs.msdn.microsoft.com/syedab/2010/05/09/generate-guid-using-guidgen-exe/ from my erstwhile cubicle in DuPont, WA http://vzimmer.blogspot.com/2018/07/the-march-of-time.html. I guess that I can now say 'buried' (thanks Fish for the latest pic) former campus.
This, along with other buried piles of GUIDs in the EDK code, the UEFI specification, and the PI specification http://uefi.org/specifications emanated from that dank DuPont corner cubicle. I've seen prezo's like this Bluehat one commencing in 2007 with Heasman's UEFI Black Hat talk through a decade of folks searching for GUID's in binaries and mentioning them in prezos and papers.
At the beginning of the hardware track a researcher came up to me and asked "Are you Vincent Zimmer? You're famous, man." I replied, "Er, 'famous', or 'infamous', given the queued up talks." He replied, "Nah, famous." That was nice.
It looks like today is makes one milestone of 20 years if you use source artifacts as a sign post. You'll notice the code below matches chapter 7 of http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_7.pdf pretty closely, too (i.e., replace 'IBI' with 'EFI'). The code author is the same Ken Reneris mentioned in the Beyond BIOS https://www.amazon.com/Beyond-BIOS-Developing-Extensible-Interface/dp/1501514784 acknowledgement, too.
Although there's no explicit mention of IBI in the UEFI specification, it still lingers in
#define EFI_SYSTEM_TABLE_SIGNATURE 0x5453595320494249
or
'IBI SYST'.
Moving on from Bluehat and IBI, I am surprised by the feedback around Linus T's behavior https://www.zdnet.com/article/linus-torvalds-and-linux-code-of-conduct-myths/.
I recall one event (maybe the 2015 OSTS mentioned in http://vzimmer.blogspot.com/2015/05/ocp-csw-and-new-specifications.html) when I was introduced to Linus as a 'UEFI guy, so tell him what you don't like.' Linus said 'That UEFI runtime is really screwed up.' I replied 'I agree, especially services like SetVirtualAddress that are not idempotent, so they break things like kexec where the latter kernel cannot re-invoke the service.' He looked at me and said 'Hmmm, but I like the UEFI Shell for debugging.' I responded 'It's OK, I guess.' At this point the Linux die-hard who had initiated the interaction was fuming and shouted 'But Linus, what about ACPI?' Linus then looked at us both and said 'But wasn't ACPI screwed up before EFI and UEFI?' Good times.
My philosophy on getting strident feedback from open source leaders, whether Linus, Minnich, or the spectrum in-between on the net, is to not take it person 'how' the message is delivered, but 'why.' I use the analogy of the bazooka. Don't cavil about the calibre of weapon, but try to figure out why it's aimed at me. Often it's because the party delivering the message is passionate about a legitimate concern, and my job entails trying to understand and make progress against 'fixing' the concern, if possible.
Final thoughts are on grabbing the free Friday sessions as CppCon in Bellevue. I was impressed with the wisdom behind
As recently as a day ago I had to remind someone that adding new behavior to a 20 year API without changing software visible version indicia, such as version field or GUID of the API, was a doomed path. They replied 'but everyone builds with the latest code.' To which I responded 'that makes sense within one company, but the point of standardized API's is interoperability, and for the latter you cannot dictate the provenance or age of the caller.'
Speaking of Bellevue and the Pacific Northwest, I'll leave with a couple of shots from http://www.issaquahchamber.com/salmondays. Namely a 'before'
To begin, I couldn't help but remember
https://trustedcomputinggroup.org/wp-content/uploads/Platform-Reset-Attack-Mitigation-Specification.pdf during the F-Secure talk at Blue Hat https://www.microsoft.com/en-us/msrc/bluehat-conference recently.
That MEMORY_ONLY_RESET_CONTROL_GUID was GuidGen.exe'd https://blogs.msdn.microsoft.com/syedab/2010/05/09/generate-guid-using-guidgen-exe/ from my erstwhile cubicle in DuPont, WA http://vzimmer.blogspot.com/2018/07/the-march-of-time.html. I guess that I can now say 'buried' (thanks Fish for the latest pic) former campus.
At the beginning of the hardware track a researcher came up to me and asked "Are you Vincent Zimmer? You're famous, man." I replied, "Er, 'famous', or 'infamous', given the queued up talks." He replied, "Nah, famous." That was nice.
Speaking of ghosts of technology past and true rock stars, people have been remarking this year that UEFI is a '20 year old technology.' I was curious about the precision of those statements, so I looked into an early Intel Boot Initiative (IBI) https://www.afterdawn.com/glossary/term.cfm/intel_boot_initiative tree. IBI was the original name of EFI. I found the following.
/*++
Copyright (c) 1998 Intel Corporation
Module Name:
ibiapi.h
Abstract:
Global IBI runtime & boot service interfaces
Author:
Ken Reneris Oct-14-1998
Revision History
--*/
//
// IBI Memory
//
typedef
IBI_STATUS
(IBIAPI *IBI_ALLOCATE_PAGES) (
IN IBI_ALLOCATE_TYPE Type,
IN IBI_MEMORY_TYPE MemoryType,
IN UINTN NoPages,
OUT IBI_PHYSICAL_ADDRESS *Memory
);
typedef
IBI_STATUS
(IBIAPI *IBI_FREE_PAGES) (
IN IBI_PHYSICAL_ADDRESS Memory,
IN UINTN NoPages
);
typedef
IBI_STATUS
(IBIAPI *IBI_GET_MEMORY_MAP) (
IN OUT UINTN *MemoryMapSize,
IN OUT IBI_MEMORY_DESCRIPTOR *MemoryMap,
OUT UINTN *MapKey
);
typedef
IBI_STATUS
(IBIAPI *IBI_ALLOCATE_POOL) (
IN IBI_MEMORY_TYPE PoolType,
IN UINTN Size,
OUT VOID **Buffer
);
typedef
IBI_STATUS
(IBIAPI *IBI_FREE_POOL) (
IN VOID *Buffer
);
//
// IBI Events
//
typedef enum {
EVT_NORMAL,
EVT_TIMER,
EVT_MAX_TYPE
} IBI_EVENT_TYPE;
typedef
VOID
(IBIAPI *IBI_EVENT_NOTIFY) (
IN IBI_EVENT Event,
IN VOID *Context
);
typedef
IBI_STATUS
(IBIAPI *IBI_CREATE_EVENT) (
IN IBI_EVENT_TYPE Type,
IN IBI_TPL Tpl,
IN IBI_EVENT_NOTIFY NotifyFunction,
IN VOID *NotifyContext,
OUT IBI_EVENT *Event
);
typedef enum {
TimerCancel,
TimerPeriodic,
TimerRelative
} IBI_TIMER_DELAY;
typedef
IBI_STATUS
(IBIAPI *IBI_SET_TIMER) (
IN IBI_EVENT Event,
IN IBI_TIMER_DELAY Type,
IN UINT64 TriggerTime
);
typedef
IBI_STATUS
(IBIAPI *IBI_SIGNAL_EVENT) (
IN IBI_EVENT Event
);
typedef
IBI_STATUS
(IBIAPI *IBI_CLOSE_EVENT) (
IN IBI_EVENT Event
);
//
// Task priority level
//
#define TPL_NORMAL 4
#define TPL_CALLBACK 8
#define TPL_NOTIFY 16
#define TPL_HIGH_LEVEL 31
typedef
IBI_TPL
(IBIAPI *IBI_RAISE_TPL) (
IN IBI_TPL NewTpl
);
typedef
VOID
(IBIAPI *IBI_RESTORE_TPL) (
IN IBI_TPL NewTpl
);
//
// IBI platform varibles
//
#define IBI_GLOBAL_VARIABLE \
{ 0x8BE4DF61, 0x93CA, 0x11d2, 0xAA, 0x0D, 0x00, 0xE0, 0x98, 0x03, 0x2B, 0x8C }
// Variable attributes
#define IBI_VARIABLE_NON_VOLATILE 0x00000001
#define IBI_VARIABLE_BOOTSERVICE_ACCESS 0x00000002
#define IBI_VARIABLE_RUNTIME_ACCESS 0x00000004
typedef
IBI_STATUS
(IBIAPI *IBI_GET_VARIABLE) (
IN CHAR16 *VariableName,
IN IBI_GUID *VendorGuid,
OUT UINT32 *Attributes OPTIONAL,
IN OUT UINTN *DataSize,
OUT VOID *Data
);
typedef
IBI_STATUS
(IBIAPI *IBI_GET_NEXT_VARIABLE_NAME) (
IN OUT UINTN *VariableNameSize,
IN OUT CHAR16 *VariableName,
IN OUT IBI_GUID *VendorGuid
);
typedef
IBI_STATUS
(IBIAPI *IBI_SET_VARIABLE) (
IN CHAR16 *VariableName,
IN IBI_GUID *VendorGuid,
IN UINT32 Attributes,
IN UINTN DataSize,
IN VOID *Data
);
...
It looks like today is makes one milestone of 20 years if you use source artifacts as a sign post. You'll notice the code below matches chapter 7 of http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_7.pdf pretty closely, too (i.e., replace 'IBI' with 'EFI'). The code author is the same Ken Reneris mentioned in the Beyond BIOS https://www.amazon.com/Beyond-BIOS-Developing-Extensible-Interface/dp/1501514784 acknowledgement, too.
Although there's no explicit mention of IBI in the UEFI specification, it still lingers in
#define EFI_SYSTEM_TABLE_SIGNATURE 0x5453595320494249
or
'IBI SYST'.
Moving on from Bluehat and IBI, I am surprised by the feedback around Linus T's behavior https://www.zdnet.com/article/linus-torvalds-and-linux-code-of-conduct-myths/.
I recall one event (maybe the 2015 OSTS mentioned in http://vzimmer.blogspot.com/2015/05/ocp-csw-and-new-specifications.html) when I was introduced to Linus as a 'UEFI guy, so tell him what you don't like.' Linus said 'That UEFI runtime is really screwed up.' I replied 'I agree, especially services like SetVirtualAddress that are not idempotent, so they break things like kexec where the latter kernel cannot re-invoke the service.' He looked at me and said 'Hmmm, but I like the UEFI Shell for debugging.' I responded 'It's OK, I guess.' At this point the Linux die-hard who had initiated the interaction was fuming and shouted 'But Linus, what about ACPI?' Linus then looked at us both and said 'But wasn't ACPI screwed up before EFI and UEFI?' Good times.
My philosophy on getting strident feedback from open source leaders, whether Linus, Minnich, or the spectrum in-between on the net, is to not take it person 'how' the message is delivered, but 'why.' I use the analogy of the bazooka. Don't cavil about the calibre of weapon, but try to figure out why it's aimed at me. Often it's because the party delivering the message is passionate about a legitimate concern, and my job entails trying to understand and make progress against 'fixing' the concern, if possible.
Final thoughts are on grabbing the free Friday sessions as CppCon in Bellevue. I was impressed with the wisdom behind
Speaking of Bellevue and the Pacific Northwest, I'll leave with a couple of shots from http://www.issaquahchamber.com/salmondays. Namely a 'before'
and 'after'
of the salmon.
© 2018, Vincent Zimmer. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License
No comments:
Post a Comment