Tue Oct 19 05:18:59 2021
EVENTS
 FREE
SOFTWARE
INSTITUTE

POLITICS
JOBS
MEMBERS'
CORNER

MAILING
LIST

NYLXS Mailing Lists and Archives
NYLXS Members have a lot to say and share but we don't keep many secrets. Join the Hangout Mailing List and say your peice.

DATE 2014-11-01

HANGOUT

2021-10-19 | 2021-09-19 | 2021-08-19 | 2021-07-19 | 2021-06-19 | 2021-05-19 | 2021-04-19 | 2021-03-19 | 2021-02-19 | 2021-01-19 | 2020-12-19 | 2020-11-19 | 2020-10-19 | 2020-09-19 | 2020-08-19 | 2020-07-19 | 2020-06-19 | 2020-05-19 | 2020-04-19 | 2020-03-19 | 2020-02-19 | 2020-01-19 | 2019-12-19 | 2019-11-19 | 2019-10-19 | 2019-09-19 | 2019-08-19 | 2019-07-19 | 2019-06-19 | 2019-05-19 | 2019-04-19 | 2019-03-19 | 2019-02-19 | 2019-01-19 | 2018-12-19 | 2018-11-19 | 2018-10-19 | 2018-09-19 | 2018-08-19 | 2018-07-19 | 2018-06-19 | 2018-05-19 | 2018-04-19 | 2018-03-19 | 2018-02-19 | 2018-01-19 | 2017-12-19 | 2017-11-19 | 2017-10-19 | 2017-09-19 | 2017-08-19 | 2017-07-19 | 2017-06-19 | 2017-05-19 | 2017-04-19 | 2017-03-19 | 2017-02-19 | 2017-01-19 | 2016-12-19 | 2016-11-19 | 2016-10-19 | 2016-09-19 | 2016-08-19 | 2016-07-19 | 2016-06-19 | 2016-05-19 | 2016-04-19 | 2016-03-19 | 2016-02-19 | 2016-01-19 | 2015-12-19 | 2015-11-19 | 2015-10-19 | 2015-09-19 | 2015-08-19 | 2015-07-19 | 2015-06-19 | 2015-05-19 | 2015-04-19 | 2015-03-19 | 2015-02-19 | 2015-01-19 | 2014-12-19 | 2014-11-19 | 2014-10-19 | 2014-09-19 | 2014-08-19 | 2014-07-19 | 2014-06-19 | 2014-05-19 | 2014-04-19 | 2014-03-19 | 2014-02-19 | 2014-01-19 | 2013-12-19 | 2013-11-19 | 2013-10-19 | 2013-09-19 | 2013-08-19 | 2013-07-19 | 2013-06-19 | 2013-05-19 | 2013-04-19 | 2013-03-19 | 2013-02-19 | 2013-01-19 | 2012-12-19 | 2012-11-19 | 2012-10-19 | 2012-09-19 | 2012-08-19 | 2012-07-19 | 2012-06-19 | 2012-05-19 | 2012-04-19 | 2012-03-19 | 2012-02-19 | 2012-01-19 | 2011-12-19 | 2011-11-19 | 2011-10-19 | 2011-09-19 | 2011-08-19 | 2011-07-19 | 2011-06-19 | 2011-05-19 | 2011-04-19 | 2011-03-19 | 2011-02-19 | 2011-01-19 | 2010-12-19 | 2010-11-19 | 2010-10-19 | 2010-09-19 | 2010-08-19 | 2010-07-19 | 2010-06-19 | 2010-05-19 | 2010-04-19 | 2010-03-19 | 2010-02-19 | 2010-01-19 | 2009-12-19 | 2009-11-19 | 2009-10-19 | 2009-09-19 | 2009-08-19 | 2009-07-19 | 2009-06-19 | 2009-05-19 | 2009-04-19 | 2009-03-19 | 2009-02-19 | 2009-01-19 | 2008-12-19 | 2008-11-19 | 2008-10-19 | 2008-09-19 | 2008-08-19 | 2008-07-19 | 2008-06-19 | 2008-05-19 | 2008-04-19 | 2008-03-19 | 2008-02-19 | 2008-01-19 | 2007-12-19 | 2007-11-19 | 2007-10-19 | 2007-09-19 | 2007-08-19 | 2007-07-19 | 2007-06-19 | 2007-05-19 | 2007-04-19 | 2007-03-19 | 2007-02-19 | 2007-01-19 | 2006-12-19 | 2006-11-19 | 2006-10-19 | 2006-09-19 | 2006-08-19 | 2006-07-19 | 2006-06-19 | 2006-05-19 | 2006-04-19 | 2006-03-19 | 2006-02-19 | 2006-01-19 | 2005-12-19 | 2005-11-19 | 2005-10-19 | 2005-09-19 | 2005-08-19 | 2005-07-19 | 2005-06-19 | 2005-05-19 | 2005-04-19 | 2005-03-19 | 2005-02-19 | 2005-01-19 | 2004-12-19 | 2004-11-19 | 2004-10-19 | 2004-09-19 | 2004-08-19 | 2004-07-19 | 2004-06-19 | 2004-05-19 | 2004-04-19 | 2004-03-19 | 2004-02-19 | 2004-01-19 | 2003-12-19 | 2003-11-19 | 2003-10-19 | 2003-09-19 | 2003-08-19 | 2003-07-19 | 2003-06-19 | 2003-05-19 | 2003-04-19 | 2003-03-19 | 2003-02-19 | 2003-01-19 | 2002-12-19 | 2002-11-19 | 2002-10-19 | 2002-09-19 | 2002-08-19 | 2002-07-19 | 2002-06-19 | 2002-05-19 | 2002-04-19 | 2002-03-19 | 2002-02-19 | 2002-01-19 | 2001-12-19 | 2001-11-19 | 2001-10-19 | 2001-09-19 | 2001-08-19 | 2001-07-19 | 2001-06-19 | 2001-05-19 | 2001-04-19 | 2001-03-19 | 2001-02-19 | 2001-01-19 | 2000-12-19 | 2000-11-19 | 2000-10-19 | 2000-09-19 | 2000-08-19 | 2000-07-19 | 2000-06-19 | 2000-05-19 | 2000-04-19 | 2000-03-19 | 2000-02-19 | 2000-01-19 | 1999-12-19

Key: Value:

Key: Value:

MESSAGE
DATE 2014-11-17
FROM mrbrklyn@panix.com
SUBJECT Subject: [NYLXS - HANGOUT] UEFI report
From owner-hangout-outgoing-at-mrbrklyn.com Mon Nov 17 08:45:38 2014
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix)
id DEA84161130; Mon, 17 Nov 2014 08:45:37 -0500 (EST)
Delivered-To: hangout-outgoing-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix, from userid 28)
id C25C0161157; Mon, 17 Nov 2014 08:45:37 -0500 (EST)
Delivered-To: hangout-at-nylxs.com
Received: by mrbrklyn.com (Postfix, from userid 1000)
id CEFCC161143; Mon, 17 Nov 2014 08:45:36 -0500 (EST)
Date: Mon, 17 Nov 2014 08:45:36 -0500
From: mrbrklyn-at-panix.com
To: Maneesh Kongara , hangout-at-nylxs.com
Subject: [NYLXS - HANGOUT] UEFI report
Message-ID: <20141117134536.GB17827-at-www.mrbrklyn.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="k1lZvvs/B4yU6o8G"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: owner-hangout-at-mrbrklyn.com
Precedence: bulk
Reply-To: hangout-at-mrbrklyn.com


--k1lZvvs/B4yU6o8G
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

This is what I have so far for the UEFI presentation on Tuesday. Let me
know what you think. I wouldn't mind recording this presentation.

Ruben

--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013


--k1lZvvs/B4yU6o8G
Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment; filename="uefi.txt"
Content-Transfer-Encoding: 8bit

IBM/PC/Intel Based computers, like all other computing systems, need to
boot when they are powered on. The computer's various parts and in and
out devices need to be defined in order to allow access to resources.
In order to facilitate booting, PC based systems have a variety of ROM
like storage systems to read the program that begins the booting process.

When a computer starts, it has no knowledge of itself. It is a blank
slate. All the information that the system needs to know about itself,
in order to process user programs and to do useful tasks, requires
an increasingly complex task of making resources available and known.
In order to do this, systems are hard wired to look for the starting
instructions at fixed locations on the system. These locations
are specific for different hardware types. For example on Intel x86
processors, memory location FFFF:0000 is always the first instruction that
the CPU is begin executing with. Other systems have different locations,
and even different addressing schemes.

Intel x86 based system include ROM based firmware called a BIOS.
The BIOS (Basic Input/Ouptput System), has exacting specifications.
Although they can vary, for a specific x86 type of architecture, they can
only vary within the confines of the specification. A BIOS relies on the
x86 architecture’s 16-bit real mode which is a long was of saying that
it works in the environment of a 16 bit CPU of the x86 type. Since all
the intel chips have been backwardly compatible to this standard, up
until now, BIOS, and CMOS software that accesses the BIOS has been at
the core of system start ups for intel based hardware for a generation.

Over time, there has been increasing demands on hardware booting.
Even early in the history of the PC, there was a need to use PCs as thin
clients and for network booting. This required that network cards, and
networking protocols to be active prior to the booting and
implementation of the operating system. There was the creation of the
BOOTP and TFTP (trivial FTP) and a slowly a whole alphabet soup of
acronyms have been introduced into the ligo of booting system.

In addition to this, more than one operating system are now installed on
system, and hard drive capacities have grown further that the 16 BIOS
addressing scheme can read. Hard Drives have had master boot records,
but over time, booting information has moved off the master boot record
and onto various partitions. Additionally, modern Free Software and
proprietary systems can run on a variety of hardware outside of the
world of the x86 architecture.

Bios and CMOS can now also be flashed, to be updated and allow for more
flexible configurations. Tablets, micro-tables(phones), and new laptop
designs with touch screen are standard input devices have become
population. All this has put pressure to redesign the booting system
for commodity hardware.

"In the end, the BIOS is still here and still does what it has been doing
for the last 25 years: making sure your operating system can boot. It
was never designed for today’s massive diversity of hardware. It’s
still stuck with 16-bit interfaces and software interrupts, interrupt
routing and maximum precision timers, limited ROM execution space (1
MB) and image size, a limited number of initializeable devices (which
is critical in the server space), proprietary extensions, and missing
modularity—just to name a few issues." 1

This has been a blessing and a curse. Efforts to remove the BIOS
functionality have always been targeted to take away the flexibility of
run anything, clean and simple interface. IBM's MicroChannel
architecture is but one an example. Intel finally took the bull by the
horns with the introduction of the Itanium’s IA64 architecture (along
with HP) in 2003. This was a PC like server architecture that needed
around some of the BIOS limitations. The created the EFI standards
(adding more acronyms to the soup), and handed off its future to the
industrial consortium called Unified Extensible Firmware Interface Forum
which is an acronym for AMD, Insyde Software, American Megatrends, Inc..
Intel, Apple Inc, Lenovo, Dell, Microsoft, Hewlett Packard,
Phoenix Technologies and IBM. There is a SINGLE non-profit engineering
or standards group represented on UEFI forum. The result is some very
useful specifications a washed in some game changing lock down mechanism
designed to do what IBM could never accomplish with microchannel.

UEFI, in fct, is nearly an operating system sitting between your
firmware and your operating system. "It not only offers driver support,
interfaces, and services, but it also has a shell that allows users to
execute applications on a command line interface." 1

The generalized process of UEFI booting is as follows:

1- UEFI Firmware: Performs CPU and Chipset initialization and loads
drivers

2- UEFI Boot Manager - Loads device drivers and the boot application

3- Loads the OS boot manager selected by the user

4- Loads the OS

5- Runs the OS Kernel

EFI (the Intel Child of UEFI) has tables and offers run level services
to the operatings. This is similar to the runtime services that
unix-like operating systems have had for decades. Boot Services include
file services, text and graphic user consoles, and the run services can
offer access to Non-volatile random-access memory (NVRAM), date and
time, etc. EFI drivers have specific communication protocols that all
components can use. The EFI device driver environment s a virtual
drive, like what Java uses, called the EBC, which provides a CPU
independent development target for UEFI module development.

Overall Boot Time line

Part 1:
Power On
Secure Boot
Pre EFI Initialization (PEI)
PIE Core
CPU Init
Chipset Init
Board Iniit
EFI Driver Dispatcher
Architecture Protocols
Driver Execution Environment
Device, Bus and Service Driver
Utilization of the EFI Driver Dispatcher

Boot Device Selection
Boot Manager

Transition System Load
OS Absent Application
UEFI Shell
Transient OS Boot Loader
Final OS Boot Loader

Run Time
OS environment
applications

The complete specification for UEFI is now 2098 pages of text available from
the UEFI forum, and as such, is far more detailed than the limits of
this paper. It's complete current source is at
http://www.uefi.org/sites/default/files/resources/2_4_Errata_B.pdf .
The transformation from CMOS/BIOS is significant and deserves some
understanding and attention.

UEFI is an embrace and extend technology for the system bios. It does
not eliminate fundamental firmware, but masks some of the complexity
for developers and computer users. It also provides for a locked down
mechanism for purchased systems such that their operating systems can not
be removed or altered. It therefor provides a key objective of
operating system vendors and computer system manufactures such that
previously has been denied them by the open standards of BIOS and CMOS.

Upon powering up the system, BIOS bases systems have a very specific
agenda of items that they must perform in order to be compliant with the
specifications. With a BIOS the x86 CPU resets and loads a PC at the top
of the one megabyte real mode address space which is where the BIOS
program is resident. Then a jump instruction is set to move the PC to
an earlier location where the BIOS is run. The system can be reset from
a cold boot or a warm boot. Flags determine which process to follow.
On a cold boot, the bios runs a "post". On a warm boot it does not.

Post identifies the systems parts and the CPU, RAM, interrupt and DMA
controllers and other parts of the chipset, video display card, keyboard,
hard disk drive, optical disc drive and other basic hardware. After
posting, optional ROMs are searched for which extend functionality.
These ROMs exist in upper memory, and the BOIS scans memory from
0x0C0000 to 0x0F0000 on the 2 KiB boundary. ROMs have a memory boundary
of 0x55 0xAA followed by a byte that describes the number of 512 byte
blocks that the expansion ROM sits at in real memory. A checksum is of
the 512 byte block that is calculated and if valid, the execute jumps to
the optional ROM which now controls the system. ROMS normally return
back to the BIOS which scans for the next ROM until the entire sector of
memory is scanned.

Finished with all this, the BIOS now calls INT 19h. INT 19H is a software
interrupt that puts address 0019H onto the address bus and starts executing
code found there. 0019H is normally a jump instruction. Usually this loads
data from Head 0, Track 0 of Sector 1 of a disk. This would be the Master
Boot Record (MBR). Information received by the Post determines which disks
are attempted to locate a bootstrap loader, installing it into memory
location 0x0000:0x7C00. The bloatstrap loader reads in the partition
table and the operating system. 2

The bios is a dumb device that does not process instructions from the
boot sector. This is left to the bootstrap program. What is most
important to understand is that the entire BIOS specification is very
specific with exact definitions of interrupts, memory mappings, from
interrupt definitions, hard drive specification and a plethora of exact
locations and limitations in order to get from power of to OS running.
Much of this detail was created because the x86 specification was
designed for the purpose of emulating the specific IMB/PC XT product and
architecture. The new UEFI specification buries much of this
specification and leaves the implementation specifics to individual
firmware companies. Under the hood, one motherboard under UEFI might
use an entirely unique set of addressing schemes and interrupts then
another, as long as BOTH end up showing an interface that complies with
the UEFI specification.

"While BIOS is fundamentally a solid piece of firmware, UEFI is a
programmable software interface that sits on top a computer’s hardware
and firmware (and indeed UEFI can and does sit on top of BIOS). Rather
than all of the boot code being stored in the motherboard’s BIOS, UEFI
sits in the/EFI/ directory in some non-volatile memory; either in NAND
on the motherboard, on your hard drive, or on a network share (more on
that later)." 3

Bootloaders have been constrained to fit in 446 bits of the master boot
record and run in 32k of system memory. These are called first stage
boot loaders and the partition tables are in a default 64 byte partition
table with four primary partitions, in its most generic form.
Boatloaders most often load secondary boot loaders that are more
flexible, such and GRUB. These loaders allow for multiple operating
system installation or to load operating systems in different states.
They read partition tables and load systems accordingly.

UEFI takes a different approach. As one tech blogger wrote, "Now let’s
look at how booting works on a UEFI system. Even if you don’t grasp the
details of this post, grasp this: it is completely different. Completely
and utterly different from how BIOS booting works. You cannot apply any
of your understanding of BIOS booting to native UEFI booting. You cannot
make a little tweak to a system designed for the world of BIOS booting
and apply it to native UEFI booting. You need to understand that it is a
completely different world." 4 I think this is overstated. Eventually
every computer system has to do exactly what a BIOS based system does.
It has to reach into the architecture of a computer, identify some
subset of its working parts, and bootstrap a fully functional operating
system into its memory while running the operating systems viable
instruction set. UEFI is an attempt to hide much of this hardware
complexity and substitute it with software complexity that looks
simpler. There are inherent problems with this approach, the first
being is the scale of the introduced complexity. Let's review some of
this introduced complexity.

One of the first changes to the booting process involved the change from
the MBR standard to what is no known as GPART or GPT standard. There
was an essential problem to the original BIOS specification that was
simply outgrown over time, namely the limitation of the size of
partitions that could be read from hard drives. The Master Boot Record,
is that special sector at the very beginning of a fixed disk that
describes the partition table of the disk and contains the primary boot
loader. The MBR is limited to 32 bits and with a sector size set at 512
bytes, hard drive addressing is limited to a shade over 2 terabytes in
size. In order address partitions greater than 2 terabytes, another
scheme was needed. That scheme came the way of the GUID Patition Table,
(GPT).

This is the layout for a modern Master Boot Record:
________________________________________________________________________
ADDRESS Description Size in Bytes
Hex Dec
________________________________________________________________________
+000h +0 Bootstrap code area (part 1) 218
+0DAh +218 0000h Disk timestamp[4][b]
(optional, MS-DOS 7.1-8.0
(Windows 95B/98/98SE/ME),
alternatively can serve as OEM
loader signature with NEWLDR) 2
+0DCh +220 original physical drive (80h-FFh) 1
+0DDh +221 seconds (0-59) 1
+0DEh +222 minutes (0-59) 1
+0DFh +223 hours (0-23) 1
+0E0h +224 Bootstrap code area (part 2, code
entry at +000h) 216 (or 222)
+1B8h +440 32-bit disk signature
Disk signature (optional, UEFI,
Windows NT/2000/Vista/7 and other
OSes) 4
+1BCh +444 0000h
(5A5Ah if copy-protected) 2
+1BEh +446 Partition entry #1
Partition table
(for primary partitions) 16
+1CEh +462 Partition entry #2 16
+1DEh +478 Partition entry #3 16
+1EEh +494 Partition entry #4 16
+1FEh +510 55h Boot signature[a] 2
+1FFh +511 AAh
________________________________________________________________________
Total size: 218 + 6 + 216 + 6 + 4×16 + 2 512 (from WIKIPEDIA)

GUID Partition Tables, which are now a key component of the UEFI
specification, feature divisions of memory through the modern LBA
placement and memory scheme. Previously, hard drive locations were
identified by the (Cylinder, Head, Sector) tuples, which identified a
location through the raw location of the hard drive. As drives changes
and new media emerged, CHS was replaced by LBA (Logical Block
Addressing).5 The protective MBR would be in LBA0. The GPT header is
in LBA1 which has a pointer to the Partition Table or a Partition Entry
Array. 6 The Partition Array, by UEFI standards must have a minimum
16,384 bytes which allows for addressing space to 18 Exabyte with up to
128 partitions.

The UEFI standard includes a native executable tongue called the EFI Byte
Code (EBC if you are keeping track). This is a 'virtual' machine in which
the firmware can be written to and for which implementation will happen
on any hardware architecture, regardless of the CPU. In C programming,
it requires the use of efi and efilib headers and a complex linkage to
cross compile to the efi binary code. A GNU-EFI package exists and
a sample program for a native EFI firmware binary is demonstrated by
Roderick W. Smith at http://www.rodsbooks.com/efi-programming/hello.html.
His sample program includes as follows:

#include
#include

EFI_STATUS
EFIAPI
efi_main (EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable) {
InitializeLib(ImageHandle, SystemTable);
Print(L"Hello, world!\n");

return EFI_SUCCESS;
}

Notice how main is replaces with efi_main

The compilation would require a cross platform compile to EFI native
binary and a complex makefile is provided by Mr Smith as follow:
________________________________________________________________________
ARCH = $(shell uname -m | sed s,i[3456789]86,ia32,)

OBJS = main.o
TARGET = hello.efi

EFIINC = /usr/include/efi
EFIINCS = -I$(EFIINC) -I$(EFIINC)/$(ARCH) -I$(EFIINC)/protocol
LIB = /usr/lib64
EFILIB = /usr/lib64/gnuefi
EFI_CRT_OBJS = $(EFILIB)/crt0-efi-$(ARCH).o
EFI_LDS = $(EFILIB)/elf_$(ARCH)_efi.lds

CFLAGS = $(EFIINCS) -fno-stack-protector -fpic \
-fshort-wchar -mno-red-zone -Wall
ifeq ($(ARCH),x86_64)
CFLAGS += -DEFI_FUNCTION_WRAPPER
endif

LDFLAGS = -nostdlib -znocombreloc -T $(EFI_LDS) -shared \
-Bsymbolic -L $(EFILIB) -L $(LIB) $(EFI_CRT_OBJS)

all: $(TARGET)

hello.so: $(OBJS)
ld $(LDFLAGS) $(OBJS) -o $-at- -lefi -lgnuefi

%.efi: %.so
objcopy -j .text -j .sdata -j .data -j .dynamic \
-j .dynsym -j .rel -j .rela -j .reloc \
--target=efi-app-$(ARCH) $^ $-at-



Note that Makefiles are tab sensitive so you will need to assure the
format of this file accordingly.7

The UEFI standard includes the possible use of a shell. With the use of
this shell, you can run arbitrary code. This is the Preboot environment
of UEFI. In fact, Smith makes clear that this preboot environment can
be useful for application development in several areas, reinforcing the
idea that UEFI is very much operating system like in it's specification.

Wolfgang-Rosenbergsr, from Intel, has extensively documented a UEFI
Shell and the EFI OpenShell available from http:www.tianocore.org.
Among the items that the UEFI shell allows for is the execution of preboot
programs, setup, operating system installation, testing of hardware and
software, disk utilities, driver diagnostics, configuration
modifications, moving files around and between the hard disk, floppy disk,
CD-ROM, USB flash devices, and so on, to load a preboot EFI driver in the
system (has an .efi suffix) such as network stacks, tcpip drivers,
to, update old drivers in flash memory, load new drivers for plugin
cards, and more.8 This shell has two versions, Shell.efi and
Shell_full.efi. Shell.efi fits on most current flash memories.

efi binary files start with the symbol efi_main that has two parameters,
EFI_HANDLE ImageHandle and EFI_SYSTEM_TABLE *SystemTable. The
system table is a C-style structure with the following entries:

typedef struct _EFI_SYSTEM_TABLE {
EFI_TABLE_HEADER Hdr;

CHAR16 *FirmwareVendor;
UINT32 FirmwareRevision;

EFI_HANDLE ConsoleInHandle;
SIMPLE_INPUT_INTERFACE *ConIn;

EFI_HANDLE ConsoleOutHandle;
SIMPLE_TEXT_OUTPUT_INTERFACE *ConOut;

EFI_HANDLE StandardErrorHandle;
SIMPLE_TEXT_OUTPUT_INTERFACE *StdErr;

EFI_RUNTIME_SERVICES *RuntimeServices;
EFI_BOOT_SERVICES *BootServices;

UINTN NumberOfTableEntries;
EFI_CONFIGURATION_TABLE *ConfigurationTable;

} EFI_SYSTEM_TABLE;

These listed handles, likewise have application interfaces that directly
tie to firmware defined modules. For example, one can call
ConOut->OutputString() to print to the console. Firmware is required to
make available a set of binary compatible libraries for extensive
program building. EFI_RUNTIME_SERVICES accesses a firmware services
which are available in the preboot environment and when the Operating
System takes control of the system. These services include system clock
functions, NVRAM variables, and system reset operations. This is unlike
EFI_BOOT_SERVIES which are only available during the preboot phase. 7

In order to accommodate all this complex preboot operating system, UEFI
specifies that boot medium must have an EFI partition which contains
binaries, and bootloader. This is something that must astute
observers have seen on flash drives for a number of years. In order to
allow them to function at bootable devices, they have EFI partitions on
their front. These small partitions must be either FAT12, FAT16 or
FAT32. All UEFI compliant systems must be able to read all of these FAT
variations.

"The file system supported by the Extensible Firmware Interface is based
on the FAT file system. EFI defines a specific version of FAT that is
explicitly documented and testable. Conformance to the EFI specification
and its associate reference documents is the only definition of FAT that
needs to be implemented to support EFI. To differentiate the EFI file
system from pure FAT, a new partition file system type has been
defined." 4

As such a EFI partition is a partition defined as such type in a gpart
record and which has a valid EFI approved version of the FAT file system
installed within it.

UEFI specifies a UEFI Boot Manager. Since the purpose of all this is
to boot an operating system, something the BIOS Specification seems to
do so matter of factly, UEFI includes a boot manager with specifications
WITHIN its environment, rather than leaving it to the operating system.
Just as BIOS reads extensions that it expects to find at predefined
locations, the UEFI Boot Manager is defined as follows:

“The UEFI boot manager is a firmware
policy engine that can be configured by
modifying architecturally defined global NVRAM
variables. The boot manager will attempt to load
UEFI drivers and UEFI applications (including
UEFI OS boot loaders) in an order defined by
the global NVRAM variables.” 4

For those used to looking at the CMOS over the years, this is largely
the "rubber hits the road" change to the booting process with UEFI. The
configuration system is entirely different and it is not alway clear
what you are looking at when your not experienced with UEFI when trying
to install an operating system. UEFI can be configured. You can alter
your boot menu when you start your system and activate the boot manager.
You can add drives, and twist up firmware configurations, even over
clock the CPU. Because of the size of the EFI Partition, this
application can be a graphic user interface, or a cursors like
configuration menu. Linux comes with a tool to help work with your boot
manager called efibootmgr.9 It produces output such as this, when run
from user space:

[root-at-system directory]# efibootmgr -v
BootCurrent: 0002
Timeout: 3 seconds
BootOrder: 0003,0002,0000,0004
Boot0000* CD/DVD Drive BIOS(3,0,00)
Boot0001* Hard Drive HD(2,0,00)
Boot0002* Fedora HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(\EFI\fedora\grubx64.efi)
Boot0003* opensuse HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(\EFI\opensuse\grubx64.efi)
Boot0004* Hard Drive BIOS(2,0,00)P0: ST1500DM003-9YN16G .
[root-at-system directory]#

Here you can see the option: BootOrder which is to load first opensuse
(with its load path within the EFI partition specified), and then Fedora
and then the CD/DVD, and finally Hard Drive under BIOS(2,0,00)

Notice the EFI Paths described in the output of efibootmanager. They
can point at any device object that the firmware presents. This is not
just Hard Drives, but network devices, USB ports or devices not yet
invented. These paths are defined in the specification under
EFI_DEVICE_PATH_PROTOCOL. These protocols are very difficult to learn
and understand. They are defined in language programing, initially by
Intel and later by other vendors. An example is given by Intel in slide
13 and 14 in their presentation on UEFI located at
http://www.feishare.com/attachments/105_202%20UEFI-Drivers.pdf and where
it states:

Device Path Protocol - Example
GUID

#define EFI_DEVICE_

PATH_PROTOCOL_GUID \
{0x09576e91,0x6d3f,0x11d2,0x8e,0x39,0x00,0xa0,0xc9,0x69,0x72, 0x3b}

Protocol Interface Structure

typedef struct _EFI_DEVICE_PATH_PROTOCOL {
UINT8 Type;
UINT8 SubType;
UINT8 Length[2];
} EFI_DEVICE_PATH_PROTOCOL;

• The device path describes the location of the device
the handle is for
• A UEFI driver may access only a physical device for
which it provides functionality.

The slides go on to give an example of a SCSI Bus interface and a
discussion of the language implementation.


Phoenix company defines the fully paths for devices as follows. In this
exampe the path names are spelled out for the subset of devices that
Phoneix at least is supporting with this long and verbose specification for
device paths and structure within their firmware (10). I quote the exact
specification in order to underscore how complex path naming is which
underlines that UEFI does not, as it claims, remove complexity from the
booting process. It does organize the complexity to make it more
managable in some instances.

_____________________________________________________________________________
*GUID

#define EFI_DEVICE_PATH_PROTOCOL_GUID \
{0x09576e91,0x6d3f,0x11d2,0x8e,0x39,0x00,0xa0,0xc9,0x69,0x72,0x3b}

*Protocol Interface Structure

#include EFI_PROTOCOL_CONSUMER(DevicePath) // for protocol
#include "Efi\EfiDevicePath.h" // for #define & structures

extern EFI_GUID gEfiDevicePathProtocolGuid;

typedef struct _EFI_DEVICE_PATH_PROTOCOL {
UINT8 Type;
UINT8 SubType;
UINT8 Length[2];
} EFI_DEVICE_PATH_PROTOCOL;

Members
Member Description
Type The type of device path node.

#define HARDWARE_DEVICE_PATH 0x01
#define ACPI_DEVICE_PATH 0x02
#define MESSAGING_DEVICE_PATH 0x03
#define MEDIA_DEVICE_PATH 0x04
#define BBS_DEVICE_PATH 0x05
#define END_DEVICE_PATH_TYPE 0x7f

SubType The sub-type of the device path now. The meaning depends on Type. For HARDWARE_DEVICE_PATH:

#define HW_PCI_DP 0x01
#define HW_PCCARD_DP 0x02
#define HW_MEMMAP_DP 0x03
#define HW_VENDOR_DP 0x04
#define HW_CONTROLLER_DP 0x05

For ACPI_DEVICE_PATH:

#define ACPI_DP 0x01
#define ACPI_EXTENDED_DP 0x02
#define ACPI_ADR_DP 0x03

For MESSAGING_DEVICE_PATH:

#define MSG_ATAPI_DP 0x01
#define MSG_SCSI_DP 0x02
#define MSG_FIBRECHANNEL_DP 0x03
#define MSG_1394_DP 0x04
#define MSG_USB_DP 0x05
#define MSG_I2O_DP 0x06
#define MSG_INFINIBAND_DP 0x09
#define MSG_VENDOR_DP 0x0a
#define MSG_MAC_ADDR_DP 0x0b
#define MSG_IPv4_DP 0x0c
#define MSG_IPv6_DP 0x0d
#define MSG_UART_DP 0x0e
#define MSG_USB_CLASS_DP 0x0f
#define MSG_USB_WWID_DP 0x10
#define MSG_DEVICE_LOGICAL_UNIT_DP 0x11
#define MSG_SATA_DP 0x12
#define MSG_ISCSI_DP 0x13

For MEDIA_DEVICE_PATH:

#define MEDIA_HARDDRIVE_DP 0x01
#define MEDIA_CDROM_DP 0x02
#define MEDIA_VENDOR_DP 0x03
#define MEDIA_FILEPATH_DP 0x04
#define MEDIA_PROTOCOL_DP 0x05

For BBS_DEVICE_PATH:

#define BBS_BBS_DP 0x01

For END_DEVICE_PATH_TYPE:

#define END_ENTIRE_DEVICE_PATH_SUBTYPE 0xFF
#define END_INSTANCE_DEVICE_PATH_SUBTYPE 0x01

Length The entire length of this device path node, including this header, in bytes.
Description

The executing IEFI Image may use the device path to match its own device
drivers to the particular device. Note that the executing UEFI OS loader
and UEFI application images must access all physical devices via Boot
Services device handles until ExitBootServices() is successfully called.

A UEFI driver may access only a physical device for which it provides functionality.


Type SubType Structure
_______________________________________________________________________
HARDWARE_DEVICE_PATH HW_PCI_DP PCI_DEVICE_PATH
HW_PCCARD_DP PCCARD_DEVICE_PATH
HW_MEMMAP_DP MEMMAP_DEVICE_PATH
HW_VENDOR_DP VENDOR_DEVICE_PATH
HW_CONTROLLER_DP CONTROLLER_DEVICE_PATH
ACPI_DEVICE_PATH ACPI_DP ACPI_HID_DEVICE_PATH
ACPI_EXTENDED_DP
ACPI_EXTENDED_HID_DEVICE_PATH ACPI_ADR_DP
ACPI_ADR_DEVICE_PATH
MESSAGING_DEVICE_PATH MSG_ATAPI_DP ATAPI_DEVICE_PATH
MSG_SCSI_DP SCSI_DEVICE_PATH
MSG_FIBRECHANNEL_DP
FIBRECHANNEL_DEVICE_PATH
MSG_1394_DP F1393_DEVICE_PATH
MSG_USB_DP USB_DEVICE_PATH
MSG_USB_CLASS_DP USB_CLASS_DEVICE_PATH
MSG_USB_WWID_DP USB_WWID_DEVICE_PATH
MSG_DEVICE_LOGICAL_UNIT_DP
DEVICE_LOGICAL_UNIT_DEVICE_PATH
MSG_I2O_DEP I2O_DEVICE_PATH
MSG_MAC_ADDR_DP MAC_ADDR_DEVICE_PATH
MSG_IPv4_DP IPv4_DEVICE_PATH
MSG_IPv6_DP IPv6_DEVICE_PATH
MSG_INFINIBAND_DP INFINIBAND_DEVICE_PATH
MSG_UART_DP UART_DEVICE_PATH
MSG_VENDOR_DP VENDOR_DEVICE_PATH

MSG_VENDOR_DP, GUID =
DEVICE_PATH_MESSAGING_PC_ANSI ---

MSG_VENDOR_DP,
GUID = DEVICE_PATH_MESSAGING_PC_VT_100
---
MSG_VENDOR_DP, GUID =
DEVICE_PATH_MESSAGING_PC_VT_100_PLUS
---
MSG_VENDOR_DP, GUID =
DEVICE_PATH_MESSAGING_PC_UTF8
---
MSG_VENDOR_DP, GUID =
DEVICE_PATH_MESSAGING_FLOW_CONTROL
UART_FLOW_CONTROL_DEVICE_PATH

MSG_VENDOR_DP, GUID =
DEVICE_PATH_MESSAGING_SAS
SAS_DEVICE_PATH MSG_ISCSI_DP
ISCSI_DEVICE_PATH MSG_SATA_DP
SATA_DEVICE_PATH

MEDIA_DEVICE_PATH MEDIA_HARDDRIVE_DP
HARDDRIVE_DEVICE_PATH MEDIA_CDROM_DP CDROM_DEVICE_PATH
MEDIA_VENDOR_DP VENDOR_DEVICE_PATH
MEDIA_VENDOR_DP, GUID= UNKNOWN_DEVICE_GUID
UNKNOWN_DEVICE_VENDOR_DEVICE_PATH
MEDIA_FILEPATH_DP
FILEPATH_DEVICE_PATH MEDIA_PROTOCOL_DP
MEDIA_PROTOCOL_DEVICE_PATH
BBS_DEVICE_PATH BBS_BBS_DP BBS_BBS_DEVICE_PATH
_____________________________________________________________________________

In section 8.3 of the original Intel Specification, EFI Specification
version 1.10, dated December 1, 2002, six paths are defined as follows:

Device Path Nodes
There are six major types of Device Path nodes:

1) Hardware Device Path. This Device Path defines how a device is attached
to the resource domain of a system, where resource domain is simply the
shared memory, memory mapped I/O, and I/O space of the system.

2) ACPI Device Path. This Device Path is used to describe devices whose
enumeration is not described in an industry-standard fashion. These
devices must be described using ACPI AML in the ACPI name space; this
Device Path is a linkage to the ACPI name space.

3) Messaging Device Path. This Device Path is used to describe the
connection of devices outside the resource domain of the system. This
Device Path can describe physical messaging information (e.g., a SCSI ID)
or abstract information (e.g., networking protocol IP addresses).

4) Media Device Path. This Device Path is used to describe the portion of
a medium that is being abstracted by a boot service. For example, a Media
Device Path could define which partition on a hard drive was being used.

5) BIOS Boot Specification Device Path. This Device Path is used to
point to boot legacy operating systems; it is based on the BIOS Boot
Specification Version 1.01. Refer to the References appendix for details
on obtaining this specification.

6) End of Hardware Device Path. Depending on the Sub-Type, this Device
Path node is used to indicate the end of the Device Path instance or
Device Path structure.11

You can see this specification reflected in the Phoenix development
protocols. Overall, there is a very verbose and user unfreindly naming
convention for identifying bootable objects within the UEFI bootloader,
all of which can be quite frightful when a user is confronted with
deleting a driver that the firmware initially places on the boot menu.
Firmware writers need to be careful to include a return to default
configuration in order to save the end user from themselves.

Returning back to the output of our sample efibootmgr output, and after
reviewing some of the specifications of EFI_DEVIDE_PATH_PROTOCOL, we can
now disect some of this output with better edification:

[root-at-system directory]# efibootmgr -v
BootCurrent: 0002
Timeout: 3 seconds
BootOrder: 0003,0002,0000,0004
Boot0000* CD/DVD Drive BIOS(3,0,00)
Boot0001* Hard Drive HD(2,0,00)
Boot0002* Fedora
HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(\EFI\fedora\grubx64.efi)
Boot0003* opensuse
HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(\EFI\opensuse\grubx64.efi)
Boot0004* Hard Drive BIOS(2,0,00)P0: ST1500DM003-9YN16G .

Boot0000, and Boot0004 are evidently legacy bios boot entries. Boot0002
and Boot0003 are native UEFI entries which point to different secondary boot
loaders, both being on the same hard drive device and both executables
residing in the EFI active partition, one for fedora and one for
opensuse. Boot0001 is a UEFI default boot if all else fails. This is
similar to a bios boot but the UEFI boot loader looks on the specified
hard drive for a efi binary based on the system architecture, such as
\EFI\BOOT\BOOTx64.EFI (for a x86 64 bit arch).







_______________________________________________________________________________
1. http://www.tomshardware.com/reviews/intel-uefi-firmware,2486.html
2. https://en.wikipedia.org/wiki/BIOS
3. http://www.extremetech.com/computing/96985-demystifying-uefi-the-long-overdue-bios-replacement
Sebastian Anthony on September 22, 2011
4. https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/

5. Logical block addressing (LBA) is a common scheme used for specifying
the location of blocks of data stored on computer storage devices,
generally secondary storage systems such as hard disks.

LBA is a particularly simple linear addressing scheme; blocks are located
by an integer index, with the first block being LBA 0, the second LBA 1,
and so on

6. https://en.wikipedia.org/wiki/GUID_Partition_Table
7. http://www.rodsbooks.com/efi-programming/hello.html
8. https://software.intel.com/en-us/articles/uefi-shell/
9. http://linux.die.net/man/8/efibootmgr
10. http://wiki.phoenix.com/wiki/index.php/EFI_DEVICE_PATH_PROTOCOL
11. EFI Specification 1.10 - December 1, 2002:
http://www.intel.com/content/dam/doc/product-specification/efi-v1-10-specification.pdf




--k1lZvvs/B4yU6o8G--

  1. 2014-11-01 Elfen Magix <elfen_magix-at-yahoo.com> Subject: [NYLXS - HANGOUT] Linux & Raspberry PI Teaching Projects?
  2. 2014-11-01 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Linux & Raspberry PI Teaching Projects?
  3. 2014-11-01 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Linux & Raspberry PI Teaching Projects?
  4. 2014-11-02 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Tookster parrot is gone
  5. 2014-11-02 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] PNG Lib problems
  6. 2014-11-02 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] [ruben-at-mrbrklyn.com: Re: Architecture Homework - Review Questions]
  7. 2014-11-02 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] 2to4 decoder
  8. 2014-11-03 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Digital Electronics tutorial
  9. 2014-11-03 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Digital Electronics tutorial
  10. 2014-11-03 Ruben Safir <mrbrklyn-at-panix.com> Fwd: Re: [NYLXS - HANGOUT] [ruben-at-mrbrklyn.com: Re: Architecture
  11. 2014-11-03 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: HW Assignment #3
  12. 2014-11-05 Elfen Magix <elfen_magix-at-yahoo.com> Re: [NYLXS - HANGOUT] Linux & Raspberry PI Teaching Projects?
  13. 2014-11-05 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Linux & Raspberry PI Teaching Projects?
  14. 2014-11-06 mrbrklyn-at-panix.com Subject: [NYLXS - HANGOUT] [noreply+feedproxy-at-google.com: nixCraft Linux / UNIX Newsletter]
  15. 2014-11-06 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: Archetchure class - memory cache math et al
  16. 2014-11-08 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] httpd won't go away
  17. 2014-11-08 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: Re: [opensuse] PNG Lib problems
  18. 2014-11-08 Ruben Safir <mrbrklyn-at-panix.com> Fwd: [NYLXS - HANGOUT] httpd won't go away
  19. 2014-11-09 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: Re: [opensuse] httpd won't go away
  20. 2014-11-09 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Re: [opensuse] httpd won't go away
  21. 2014-11-09 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Postgres Lecture
  22. 2014-11-09 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Lectures at LIU with IEEE and The Computer Science Club
  23. 2014-11-09 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] [ruben-at-mrbrklyn.com: LIU Brooklyn Computer Science Program and
  24. 2014-11-09 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] [ruben-at-mrbrklyn.com: Re: Talk at LIU Brooklyn]
  25. 2014-11-09 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] [ruben-at-mrbrklyn.com: Re: Talk at LIU Brooklyn]
  26. 2014-11-10 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] [ruben-at-mrbrklyn.com: [info-at-meetup.com: Invitation: NYLUG Open hacker
  27. 2014-11-10 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] [ruben-at-mrbrklyn.com: [info-at-meetup.com: Thursday: Join us at
  28. 2014-11-10 mrbrklyn-at-panix.com Subject: [NYLXS - HANGOUT] [Perlweekly] #172 - And the Silver Camel Goes To...
  29. 2014-11-11 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: FYI: The Institute Online: 3-D Printing Opens Products to Counterfeiting
  30. 2014-11-11 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] [ruben-at-mrbrklyn.com: Guido]
  31. 2014-11-11 mrbrklyn-at-panix.com Subject: [NYLXS - HANGOUT] [christopher.league-at-liu.edu: LIU CS Club: iPhone Development
  32. 2014-11-12 mrbrklyn-at-panix.com Subject: [NYLXS - HANGOUT] DB Architeture Lecture tomorrow - C++ db design
  33. 2014-11-12 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] firefox crashing
  34. 2014-11-12 eminker-at-gmail.com Re: [NYLXS - HANGOUT] firefox crashing
  35. 2014-11-12 eminker-at-gmail.com Re: [NYLXS - HANGOUT] firefox crashing
  36. 2014-11-13 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] firefox crashing
  37. 2014-11-13 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] firefox crashing
  38. 2014-11-14 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] how is this research...UEFI
  39. 2014-11-16 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Postgres Lecture tomorrow
  40. 2014-11-16 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] LIU CS Club: iPhone Development Workshop THIS THURSDAY
  41. 2014-11-17 mrbrklyn-at-panix.com Subject: [NYLXS - HANGOUT] [announce-at-lists.isoc-ny.org: [isoc-ny] Internet Society Statement on
  42. 2014-11-17 mrbrklyn-at-panix.com Subject: [NYLXS - HANGOUT] UEFI report
  43. 2014-11-18 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] UEFI and Secure Boot
  44. 2014-11-19 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] oh Joy!
  45. 2014-11-21 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] New Private Browsing?
  46. 2014-11-23 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] [ruben-at-mrbrklyn.com: Re: Perl + DBD-Oracle, problems with encoding
  47. 2014-11-23 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] [ruben-at-mrbrklyn.com: [mr.criptos-at-gmail.com: Re: MySQL dying?]]
  48. 2014-11-23 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] [ruben-at-mrbrklyn.com: Re: Perl + DBD-Oracle, problems with encoding
  49. 2014-11-26 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] [mrbrklyn-at-panix.com: [LIU Comp Sci] Why Normalization Failed to
  50. 2014-11-26 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] [mrbrklyn-at-panix.com: [LIU Comp Sci] Why Data Models Shouldn't Drive
  51. 2014-11-26 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] [mrbrklyn-at-panix.com: [LIU Comp Sci] Problems with Normalization]
  52. 2014-11-27 einker <eminker-at-gmail.com> Subject: [NYLXS - HANGOUT] Happy Thanksgiving All!
  53. 2014-11-27 einker <eminker-at-gmail.com> Subject: [NYLXS - HANGOUT] Happy Thanksgiving All!
  54. 2014-11-27 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Happy Thanksgiving All!
  55. 2014-11-27 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Happy Thanksgiving All!
  56. 2014-11-27 eminker-at-gmail.com Re: [NYLXS - HANGOUT] Happy Thanksgiving All!
  57. 2014-11-27 eminker-at-gmail.com Re: [NYLXS - HANGOUT] Happy Thanksgiving All!
  58. 2014-11-28 Ruben Safir <mrbrklyn-at-panix.com> Re: [NYLXS - HANGOUT] Happy Thanksgiving All!
  59. 2014-11-28 einker <eminker-at-gmail.com> Re: [NYLXS - HANGOUT] Happy Thanksgiving All!
  60. 2014-11-29 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Fwd: [LIU Comp Sci] Memory Cache theory Architecture Class
  61. 2014-11-29 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] Introduction and Basics - Carnegie Mellon
  62. 2014-11-30 mrbrklyn-at-panix.com Subject: [NYLXS - HANGOUT] Invitation: What I learned as a programmer from founding a startup
  63. 2014-11-30 Ruben Safir <mrbrklyn-at-panix.com> Subject: [NYLXS - HANGOUT] purging systemd

NYLXS are Do'ers and the first step of Doing is Joining! Join NYLXS and make a difference in your community today!