Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <6e5763be-3e9c-0199-24ea-e4f5b226d990@oracle.com>
Date:   Tue, 22 Feb 2022 16:01:32 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.0
Subject: Re: [PATCH 1/2] x86/boot: Fix memremap of setup_indirect structures
Content-Language: en-US
To:     Borislav Petkov <bp@alien8.de>
Cc:     linux-kernel@vger.kernel.org, x86@kernel.org,
        daniel.kiper@oracle.com, dpsmith@apertussolutions.com,
        tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
        luto@amacapital.net, kanth.ghatraju@oracle.com,
        trenchboot-devel@googlegroups.com
References: <1643303056-22272-1-git-send-email-ross.philipson@oracle.com>
 <1643303056-22272-2-git-send-email-ross.philipson@oracle.com>
 <YgabtFd4Nkpgi+oW@zn.tnic> <2e584fc4-163a-0af4-abe0-9c14996918f2@oracle.com>
 <Ygvy8j9E7WPo6dx0@zn.tnic>
From:   Ross Philipson <ross.philipson@oracle.com>
In-Reply-To: <Ygvy8j9E7WPo6dx0@zn.tnic>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eEVPK3VZcEQ3bkVnZ01FRGxTRWFVRUxDallsMGVmQVpGU3lLQ3U0aWtKY3NE?=
 =?utf-8?B?THVnUTZyVFRmdmszc3pXbGtpby80bWV4YlF0bERBNHh5WTRFLzIwR21kUjB6?=
 =?utf-8?B?K1hKVWpZYk5RWERRYzU5RUtiREU5emZoVzRPUUJDNE1PdGdyNUUyNVpHYjJw?=
 =?utf-8?B?QVovN1F6dktrM0hCMTNoL3c4T0hEYkVYYzBmb2VTdXhMVXljS2wrbk1LZ2dz?=
 =?utf-8?B?K2JMcXBQTElLbVl0OW1yNStNT2poM0lpNDFVcGNQQ0pJOHFXSTltTXRCeEd3?=
 =?utf-8?B?b1BxNnA4eUlBZ05XOG1nZStCQXdISzkyT3Q0bkI2RDkveTVQcVVZVTBmTWhu?=
 =?utf-8?B?S3EwZkZ5dnhYeUQwak1nMThObzF6Q2FRdGpNVjRGSDZPMExPb1ZSTHpxdU9J?=
 =?utf-8?B?MjU3Q0pZMFg3VWdmbzVMTWVOZkFHOWJQMUJWS1Q5Qnd3Wm12cUY2Uk16c1ZG?=
 =?utf-8?B?UnQ1amZUV040SktTY2paQ3AzaXhBVHNzUzh6ZW9QVStCRzkyQk9ZcnJXMTJm?=
 =?utf-8?B?Kzd6VHRxdmNXU29aU01VRkJpQzNCQ3l5cnUrb0d4aThhWTBRVzVtVUY2cVM2?=
 =?utf-8?B?eFgwVzJKS1dEakw2ZHYrNFNQZjhLaG9NN1JWTXpHUVE0eW1aUzVpK3dyZVAy?=
 =?utf-8?B?dURzR1MvekJsZTRsSXJiS0sreklBaEFrWkNuTkFia010cEhLa0haMzhMaENj?=
 =?utf-8?B?NVJZalZnVmw2VjlycVFnUWFFSWhEY1JxUGs1clAwQXdPWGlFSzRxcXVoNmU5?=
 =?utf-8?B?aGZEbkhWSG51SnQ2RUhwUW02bzRkUTR2U3pDeFFtUFNCNlZ2SUFaM2Jrci9k?=
 =?utf-8?B?RDIwd2REZHVCVXE0V0pOM2xwYVByYnZYc1FPeDcyOWtIQ1liSVQzZHFybG10?=
 =?utf-8?B?RkZrdXQ4aVVmYnBpTHluV1oxS3RydmRLTzVIMFd0NCtOcHVxenFEUk05M3dM?=
 =?utf-8?B?cDFuWXFjK1pvTTJxOEpaVU1NbC9WNnV1c3pUR1BEeDlxOGxJcHdvVmJFOGs2?=
 =?utf-8?B?M3NhaWVVZVF1WjJEY215Q25ONkFET3g4dGp0Z3JrK0lUSkFDenFabTRPWHVm?=
 =?utf-8?B?ZXc0empadUZSQjdXVEMxN3NMNXJJZUE2a3J3clk2VUdLZFFuMkJzYVNaczZH?=
 =?utf-8?B?VFVaTXZ3KytEeXM5OVVtZlIvZDNzWnc5cjdiYTlSdWlwTHhMSXBIdENhV3lL?=
 =?utf-8?B?MEh6TVdqZVNkT2FvZUluMmdMREMydmpsSXhKR1JSRjA5SGx3WnFKL3JZYXBP?=
 =?utf-8?B?bmQ1TE5SNVZIOUlEY1pjamJPT3hlTVVBbkt0V3ZXNG12Qi9NUDBEeXdwNktK?=
 =?utf-8?B?b2RjU2dFQzQrYXRZQndGOGdFVHR3REYwS2U3SUlyeXoxak84Yi93YUdKZE1X?=
 =?utf-8?B?cVlHK1hxVkswOU9aUnh0a3F4V0Q0azFEenRUME93azNPOUk4N0xjSnc4aWZs?=
 =?utf-8?B?TnMwYXAwcTAxbzhjZHZvaVR6RnN3WkgvL2NYbHlWd1NPb2tPU3RtcCtZdmZx?=
 =?utf-8?B?R2lGSkFydlN2aUFwY3hOUlNHNGY0KzZpbldVb0FVbEdXL2gwUHhPdnV3L0lW?=
 =?utf-8?B?bjB1b21lSUpyOUVZLzBwdnpDN0xqS3dFaE5CekxEb1NsTXdydEhhNXJ3WlNV?=
 =?utf-8?B?ZW40Uk5ZWXpheWd5cVpEdGNrZ2ljZUx4U0VxOFVVbnJVWVdYWEU1T2orUkFC?=
 =?utf-8?B?aUVHaEcvNnZWVnlGUGZZL1RoTUk3MXpvQkxIaHJMeThDT1cvbEkydHVyb1p2?=
 =?utf-8?B?NWZoaUFCTTJlVkltQ2ErakpxVXNtbVBEZmJNbkVxUUJMdlRpVnRJbnc0M1ZT?=
 =?utf-8?B?aEIvcXZWRXVpM2MrbWgrVDZ2WWp1bEtoQlRjWVFOMDAwL1BGZm9XMlYrTHFh?=
 =?utf-8?B?NlNIT0Y3QU5qL1V2WUN5ZERIR0lubVgvNnh6OTkzeWE3VGt5aGtBTWpmeFFy?=
 =?utf-8?B?TW13bENUYkNsYU8zSHcvRVdQcUNnYnVTWW93cnZ6aEdjNEx6cU9UYjMzZENN?=
 =?utf-8?B?Q1daYUVpaFZZSkdmUWZaeVU0MVd6NC9jUmc5NjF6VUJWZjRSdGIyOWdFcmlU?=
 =?utf-8?B?Nkl4L3ZzdnlSdFdKUzUyTUthejlobks0M1ViZDVOWUV3TnplTU1nZlE3RHNn?=
 =?utf-8?B?cFdGcC9BeXBsNUk0ZCtmZGN1VC84R2pMSzkrUGhOTzdaUkZEK1dBZDVPTzNF?=
 =?utf-8?B?Uk9kOW16VTd0YXF1UDNCQm5rNUFEeHB6Si9SV3c0UjhTYWlxSnpEVksyZFJi?=
 =?utf-8?B?d3BVclRDR0U1eE00T3ZTNzZsaEh4emtKWUNBSGVQS1UyL0oza3NZVlA0Szdi?=
 =?utf-8?Q?PbO6FCrnkvh7X/DLmy?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 44c0b6a6-a91c-4ca9-f6df-08d9f646835f
X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB3793.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Feb 2022 21:01:36.4696
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: U+6z1D+IFckUA2QW3sZFK/hGl+WBUwKsGV9nZIParnCQBH68Xt1xdet/g9030ooyM8rf1eRdzgjR19N7b2oYVbs+FmHwQ2kn/ymuzXg1gQA=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR10MB4499
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10266 signatures=677939
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 bulkscore=0 spamscore=0
 mlxscore=0 adultscore=0 mlxlogscore=991 suspectscore=0 malwarescore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000
 definitions=main-2202220129
X-Proofpoint-ORIG-GUID: BVzwVB6ohiTqdQPOiosA-p36jRPpG_v5
X-Proofpoint-GUID: BVzwVB6ohiTqdQPOiosA-p36jRPpG_v5
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,
        T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2/15/22 13:37, Borislav Petkov wrote:
> On Tue, Feb 15, 2022 at 06:34:43AM -0500, Ross Philipson wrote:
>> It can if you run out of slots in the fixed map.
> 
> Right. Or if any of the checks in __early_ioremap() fail. But those
> would at least warn.
> 
>> The only reason I did not check it for NULL was because it was not
>> checked elsewhere for NULL.
> 
> Elsewhere in the tree or elsewhere in this file or in the setup_indirect
> adding code?

In the ioremap.c module, the check for NULL is only missing in the
functions we updated but the lack of a check was already there before
these changes went in.

In the setup.c and e820.c modules, the check for NULL is missing in the
functions we updated but the lack of a check was already there before
these changes went in in those functions. The lack of early_memremap()
NULL checks can also be found in other functions in those modules.

> 
>> I guess there are two questions:
>>
>> 1. Should I also fix it elsewhere in the code I am touching?
> 
> Yes pls.
> 
>> 2. What should I do on an allocation failure? In a routine like this it
>> seems to be a critical early boot failure.
> 
> How so?
> 
> I'd expect in the case of e820__reserve_setup_data(), for example, to
> not call e820__range_update* and not have those indirect ranges present
> in the e820 map. What the user intended might not work but it'll at
> least boot instead of floating dead in the water.
> 
> And similar approach in the other places you're touching.

Yes I can see how to handle the failures. I will fix the code to do the
appropriate thing given what each of the functions is doing.

Fixing it in other functions and possibly elsewhere in the arch/x86 code
seems to be out of scope for this patch set. We could send separate
patches and hunt down other places this check is missing.

> 
> You could even issue a warning or so so that users at least know what's
> going on. I'd say...

Yea I can pr_warn when the issue occurs.

> 
>> I guess the original intention might have been to let it just blow up
>> since there is no recovery but that is just conjecture...
> 
> The original intention?

It was just idle speculation, just ignore this.

Thanks
Ross

> 
> Thx.
>