On Thu, Oct 20, 2011 at 6:16 PM, Yasha Karant <[log in to unmask]> wrote:
> Any idea how to get persons such as Victor Helsing to understand the issue
> here? -- this is NOT a rant.  If we ignore it, we shall all be in the soup.

It's a rant. By continuing to rant, you discourage people from paying
attention to such issues where and when they *are* relevant, such as
(hopefully) the material below.

A discussion of the UEFI technology and its direct effects on Linux or
Scientific Linux based hardware management might be useful.  What are
our favorite upstream vendor's plans? And ave you actually laid hands
on the technology or attempted to use it, to see the implications of
it. For example, it avoids the "63 block" DOS compatiliby chunk of
space at the beginning of your available disk space, avoiding the 4096
byte block alignment problem for both real and virtualized hardware on
more modern hard drives. And boot loaders have suffered from a great
deal of awkwardness in backwards compatiblity requirements, for
example with the 8 1023 cylinder limitation with earlier versions of
LILO and motherboards, and with various other complex schema to work
around legacy requirements. So a new, well defined boot loader
architecture can make eminent sense.

The problem is the lockdown features. It's completely understandable
that people who buy computers, and maintain them, do *not* want
arbitrary script kiddies or laptop thieves to be able to boot a live
CD or USB stick and read everything off their drive. My Windows and
other friends are *shocked* when I walk in with a live CD, including
ones very like Scientific Linux's, and help them recover lost data or
change relevant passwords. In general, if I can access your hardware,
I own your data.

The need for freedom and access to our own tools conflicts with this.
Being able to change a kernel or OS freely is vital to developers,
students, and people who need their tools modified for reasons
software vendors don't agree with. It's also *vital* for anonymity.
Too many systems record too much data. But this conflicts with desires
for security.

We've seen things like this play out with SELinux. The toolkit is
powerful, flexible, and so unpredictable and poorly integrated and
complex that most developers would actively *fire* me if I tried to
make them work with it. I'll be very curious to see if UEFI's vaunted
security features suffer from the same flaws in the long term. Support
for UEFI *is* built into recent releases of grub and various
virtualization technologies, so I don't anticipate it being too much
of a Linux issue unless the lock down features are enforced.