2016/01/21 2:33 "Alberto Salvia Novella" <es20490446e@gmail.com>:
>
> Joel Rees:
>
>> It supports neither your peculiar assertion that microcode is not
>> executable nor your equally peculiar assertion that microcode is not
>> and has not been a cause for concern.
>
>
> Polynomial (http://tinyurl.com/hdtpa7g):
You know, a url contains useful information in and of itself. I appreciate that urls get long and code points out of the basic plane make them hard to read and encoded server internal indexing really isn't interesting, but at least it would tell us in this case that what you are taking out of context is supposed to be from stackexchange.
> > Let's assume for a moment that you could overwrite microcode in a
> > useful way. How would you make it do anything useful?
The poster you are quoting part of does know somewhat about his topic, but these two sentences together should cause you to think carefully.
Useful is not useful?
Clearly he is thinking of more than one kind of usefulness.
> > Keep in mind
> > that each code simply shifts some values around in the internals of
> > the hardware, rather than a real operation.
If "simply shifting values around in the internals of the hardware" is not doing any "real" operation, how would the results of any "real operation" ever get out of the arithmetic or logic units?
Putting an address on the address bus in-and-of-itself neither reads nor writes data, but putting an address on the address bus is part of both reading and writing data.
"Modern" CPUs have plenty of spare register space, most of it undocumented. Register space can be used to record something of state, allowing instruction streams to be self-parsing.
How many elements of the stuff that enables malware do you want me to point out? Sure, you're not going to write a backdoor entirely in microcode, but you can use rogue updates to slip bits and pieces of microcode in to instructions that allow a backdoor to run and get around the walls.
And not all rogue updates come from 3rd parties.
Read the links Anders posted.
> Mark Shuttleworth (http://tinyurl.com/pk8zwmv):
> > Declarative firmware that describes hardware linkages and
> > dependencies but doesn’t include executable code is the best chance
> > we have of real bottom-up security.
In some ideal world, you could pre-define all the customizations an integrator or end-user could want in code that gets shipped in the kernel, and provide a declarative interface to select the tweaks an integrator or end-user wants.
From where I stand, it requires the kernel developers to know an awful lot more about what every possible thing an end user or integrator might want than is humanly possible.
--
Joel Rees